Re: View / test *-ttf fonts
Another way is to use xfontsel -scaled The -scaled option allows you to choose the sizes for scaled fonts, which usually list their sizes as 0. > On May 25, 2024, at 3:05 PM, Todd Gruhn wrote: > > It did not impress me. > > It shows me that I can see all the characters. > > I can't see what a font looks like, are different sizes. > > Now do I see / test this? > > On Sat, May 25, 2024 at 8:22 PM Thomas D. Dean wrote: >> >> On 5/25/24 07:22, Todd Gruhn wrote: >>> Is there a way to view the *-ttf fonts? >>> So I know what it will look like ... >> >> xfd >> >> Tom Dean >>
Re: RPi 4b Wifi Device
> On Apr 20, 2024, at 1:01 AM, Thomas D. Dean wrote:
>
> On 4/19/24 18:35, Michael van Elst wrote:
>> tomd...@wavecable.com ("Thomas D. Dean") writes:
>>> How do I setup wpa_supplicant?
>> That depends on what you want to do.
>> Here are some examples:
>> https://wiki.netbsd.org/tutorials/how_to_use_wpa_supplicant/
>
> I saw that.
> dhcp is working over the wired connection.
>
> I thought I had everything configured for wifi. It just does not work.
>
> I have a cable modem <-> wifi/wired router. I have several machines
> connected. Linux and windoze, now. One RPi with NetBSD 10. Used to have some
> FreeBSD machines, but, they have been replaced.
>
> # etc/rc.d/wpa_supplicant reload
> Selected interface 'bwfm0'
> 21:58:35.931: OK
>
> # wpa_cli status
> Selected interface 'bwfm0'
> 21:58:44.815: bssid=60:38:e0:db:a9:7a
> freq=0
> ssid=tddhome
> id=0
> mode=station
> pairwise_cipher=TKIP
> group_cipher=TKIP
> key_mgmt=WPA-PSK
> wpa_state=GROUP_HANDSHAKE
> ip_address=169.254.135.120
> address=e4:5f:01:da:eb:46
>
> # ifconfig bwfm0
> bwfm0: flags=0x8843 mtu 1500
> ssid "" nwkey 65536:"","","",""
> powersave off
> address: e4:5f:01:da:eb:46
> media: IEEE802.11 autoselect (DS1 mode 11g)
> status: no network
> inet6 fe80::d7c0:41b9:46a5:a5ff%bwfm0/64 flags 0x8 scopeid 0x3
> inet 169.254.135.120/16 broadcast 169.254.255.255 flags 0x4
>
>
>
> I don't understand where the inet 169.254.135.120 comes from. The router pool
> is 192.168.1.xxx.
That's an APIPA address from block 169.254.0.0/16. dhcpcd gives the interface
an address from that block when it can't properly obtain one via DHCP, unless
instructed not to.
>
> Tom Dean
Re: Listing X11 grabs with XF86LogGrabInfo
> On Mar 25, 2024, at 6:35 PM, RVP wrote: > > On Mon, 25 Mar 2024, Rob Whitlock wrote: > >> Is there some trick to enabling this functionality >> > > Yes. Try again after applying this patch (and restarting X). > > ``` > --- usr/X11R7/lib/X11/XKeysymDB.orig 2024-03-18 22:47:19.0 + > +++ usr/X11R7/lib/X11/XKeysymDB 2024-03-25 21:36:39.970222356 + > @@ -370,6 +370,9 @@ > XF86_ClearGrab:1008FE21 > XF86_Next_VMode :1008FE22 > XF86_Prev_VMode :1008FE23 > +XF86LogWindowTree:1008FE24 > +XF86LogGrabInfo :1008FE25 > + > > usldead_acute :10A8 > usldead_grave :10A9 > ``` > > You could also just supply the key-sequence for this directly: > > ``` > $ xdotool key Ctrl+Alt+F11 > ``` This did not work. It just printed "Failed to switch from vt05 to vt11: Invalid argument" in /var/log/Xorg.0.log. >> or should I file a problem report? >> > > Yes, with: > > ``` > diff -urN a/xsrc/external/mit/libX11/dist/src/XKeysymDB > b/xsrc/external/mit/libX11/dist/src/XKeysymDB > --- a/xsrc/external/mit/libX11/dist/src/XKeysymDB 2010-11-28 > 07:34:33.0 + > +++ b/xsrc/external/mit/libX11/dist/src/XKeysymDB 2024-03-25 > 21:36:39.970222356 + > @@ -370,6 +370,9 @@ > XF86_ClearGrab:1008FE21 > XF86_Next_VMode :1008FE22 > XF86_Prev_VMode :1008FE23 > +XF86LogWindowTree:1008FE24 > +XF86LogGrabInfo :1008FE25 > + > > usldead_acute :10A8 > usldead_grave :10A9 > ``` PR submitted: https://gnats.netbsd.org/58153 > Don't ask me why all the other keysyms just above have the extra > `_'. Going by the dates on that XKeysymDB file, it's rather old, > and things may have changed since then. I also can't find that file > in the tarballs in: https://www.x.org/releases/individual/lib/, but, > I didn't search very hard--you should ask on the tech-x11 ML. > > -RVP
Listing X11 grabs with XF86LogGrabInfo
Hello,
The Internet suggests performing
xdotool key XF86LogGrabInfo
in order to list grabs that are currently running on the server, however it
outputs
(symbol) No such key name 'XF86LogGrabInfo'. Ignoring it.
(symbol) No such key name 'XF86LogGrabInfo'. Ignoring it.
and does not print anything to the log file. I ran it through a debugger and it
seems like it's failing because XStringToKeysym is returning NoSymbol when
passed "XF86LogGrabInfo", as illustrated by the following code:
0 thinkpad$ cat m.c
#include
#include
#include
int main() {
Display *dpy = XOpenDisplay(NULL);
if (dpy == NULL) {
fprintf(stderr, "XOpenDisplay failed.\n");
exit (1);
}
KeySym ksym = XStringToKeysym("XF86LogGrabInfo");
printf("Keysym: %lu\n", (unsigned long)ksym);
XCloseDisplay(dpy);
}
0 thinkpad$ cat Makefile
a.out: m.c
cc -I/usr/X11R7/include -L/usr/X11R7/lib m.c -lX11 -Wl,-R/usr/X11R7/lib
0 thinkpad$ make
cc -I/usr/X11R7/include -L/usr/X11R7/lib m.c -lX11 -Wl,-R/usr/X11R7/lib
0 thinkpad$ ./a.out
Keysym: 0
0 thinkpad$
Considering that many other people used xdotool in this manner successfully, I
suspect that either NetBSD has a bug here or there is some trick to make this
work. As suggested in
https://who-t.blogspot.com/2012/01/xkb-breaking-grabs-cve-2012-0064.html I ran
setxkbmap -option grab:break_actions
and also
setxkbmap -option grab:debug
and although these settings were reflected in the output of setxkbmap -query,
they did not solve the problem.
Is there some trick to enabling this functionality or should I file a problem
report?
Thanks!
