Hi NexusSfan,
Thanks for the quick reply.
> Are you sure it is at /dev/cons/kbd and not /dev/kbd?
Both names reach the same translator. /dev/kbd is a Hurd-shaped
symlink to /dev/cons/kbd, and /dev/cons/kbd is the chrdev.
On the canonical Debian GNU/Hurd 0.9 image my original report was
against (hurd 1:0.9.git20230520-7, gnumach 1.8+git20230410-1):
showtrans /dev/kbd -> /hurd/symlink cons/kbd
showtrans /dev/cons/kbd -> /hurd/chrdev 156 33685736
showtrans /dev/mouse -> /hurd/symlink cons/mouse
showtrans /dev/cons/mouse -> /hurd/chrdev 156 33685736
kbd_drv.so's default device is /dev/kbd (the upstream X.org
default for the "kbd" input driver, no override in my xorg.conf).
The open path resolves through the symlink to /dev/cons/kbd, the
chrdev rejects the KDSKBMODE-shaped ioctl with EBADF, and the
line that surfaces in Xorg.0.log is "Cannot set event mode on
keyboard (Bad file descriptor)" from kbd_drv.so. So the path
in the message is /dev/cons/kbd because that is where the
chrdev (and the failure) lives, but the path kbd_drv.so actually
called open(2) on is /dev/kbd.
I also re-probed on a more recent Hurd image
(hurd 1:0.9.git20251029-7+b1, gnumach 1.8+git20260224, xserver
2:21.1.21-1) and the surface has shifted in an even less helpful
direction:
ls -l /dev/kbd
lrw-r--r-- 1 root root 8 ... /dev/kbd -> cons/kbd
ls -l /dev/cons
-rw------- 1 root root 0 ... /dev/cons
ls /dev/cons/kbd
ls: cannot access '/dev/cons/kbd': Not a directory
/dev/cons is no longer a directory at all on this newer image; it
is a 0-byte regular file. So /dev/kbd -> cons/kbd is now a
dangling symlink and kbd_drv.so will fail even earlier (open path,
not ioctl). /dev/console is still a /hurd/term, but the kbd-shaped
chrdev under /dev/cons is gone.
> Works on my machine ;)
This is the part I would really like to understand. Could you
share:
- which gnumach / hurd / xserver-xorg-core versions you are on
(dpkg -l gnumach* hurd xserver-xorg-core | tail -10);
- what your /etc/X11/xorg.conf or /etc/X11/xorg.conf.d/*.conf
looks like for the InputDevice / InputClass blocks;
- what `ls -l /dev/kbd /dev/cons/kbd` and
`showtrans /dev/kbd /dev/cons/kbd` print on your image;
- the kbd-relevant lines from your Xorg.0.log (the "Using input
driver 'kbd'" block and the next 20 lines, so I can see which
device path kbd_drv.so picked and whether the ioctl succeeded).
If your X works because the KDSKBMODE handler is in your gnumach
but not in canonical's, that pins the fix on the gnumach side and
makes it a concrete merge target. If instead you are using a
different input driver, or AutoAddDevices "off" with a manual
layout that skips kbd_drv entirely, that is a usable workaround
worth documenting on this thread so other people stuck on the same
wall can adopt it.
Thanks,
Borja Tarraso
[email protected]
