Re: [gnumach] /dev/cons/kbd rejects kbd_drv.so set-event-mode ioctl with EBADF; please implement KDSKBMODE or expose /dev/input/event*

Hi Samuel,

Thank you, you are right; the original report was filed against
the wrong layer. NexusSfan's reply on this thread (msg00132)
independently confirms it on the same image (hurd
1:0.9.git20251029-7+b1): with the hurd console running, Xorg
loads kbd_drv.so cleanly against /dev/cons/kbd as /hurd/chrdev
101 33751128.  So the gnumach KDSKBMODE ask in this thread is
not the right ask, and I will withdraw it once the rest below
is clear.

The reason I am not just closing the thread today is that I
went and tried to reproduce NexusSfan's working state on a
fresh canonical hurd-amd64 image, following the path the
Debian install doc spells out, and the documented invocation
runs without an error but does not populate /dev/cons. So
either I am missing an obvious prerequisite on top of what
the doc says, or the doc is slightly behind the current image;
I would rather ask than guess.

Exact sequence on a fresh boot, no edits, package versions all
match the canonical install:

  showtrans /dev/cons          -> exit 1 (no passive translator)
  ls -l /dev/cons              -> -rw------- 1 root root 0
                                   /dev/cons
  showtrans /dev/cons/kbd      -> showtrans: /dev/cons/kbd:
                                   Not a directory

  # exact command from
  # https://www.debian.org/ports/hurd/hurd-install
  nohup console -d vga -d pc_mouse --repeat=mouse \
                -d pc_kbd --repeat=kbd \
                -d generic_speaker -c /dev/vcs \
                > /tmp/hurd-console.log 2>&1 &
  sleep 4
  jobs                          -> [1]+ Running console ...
  ps -A | grep console          -> root 67 ... console -d vga ...
  cat /tmp/hurd-console.log     -> (empty, console wrote nothing)

  # re-check
  showtrans /dev/cons          -> exit 1 (still no translator)
  ls -l /dev/cons              -> still -rw------- 1 root root 0
  showtrans /dev/cons/kbd      -> still "Not a directory"

console lives as pid 67 with no diagnostic, but /dev/cons stays
a 0-byte regular file; the chrdev nodes never appear.
Reproduces across two fresh ephemeral boots.  The default state
of /etc/default/hurd-console is ENABLE="false", so the boot-time
path is intentionally off; this is just the manual path the
install doc instructs.

What I suspect (but want to confirm before filing anything as a
doc patch):

  1. Is there a prerequisite step the install doc omits on this
     image, e.g. `cd /dev && ./MAKEDEV vcs tty1 ... tty6` (which
     the older hurd/console.html page mentions) or a `settrans
     /dev/vcs /hurd/console` between "stop the mach console" and
     "run console -d vga ..."? If yes, I am happy to send a
     small clarification patch to debian-installer-hurd so the
     next person does not retrace this.
  2. NexusSfan's working setup has /dev/cons/kbd as chrdev 101
     33751128; the original 0.9 baseline (hurd 1:0.9.git20230520-7)
     had the same node as chrdev 156 33685736. Is the major-number
     change deliberate (different driver path on the newer
     hurd-console build), or coincidental? Asking because the
     original EBADF report was filed against the older major; if
     the newer driver is a rewrite that path may not apply at all
     even as a future ask.
  3. Independently of the above, would a change of the default
     /etc/default/hurd-console ENABLE from "false" to "true" be
     welcome? Happy to file separately if so. I raise it
     because the install doc's "Starting X" section assumes hurd
     console is running, and on the current default that
     assumption is silently false (startx fails at open(2) on
     /dev/kbd long before reaching any keyboard ioctl). If
     ENABLE=false is the intentional default for a reason I do
     not see, I will drop it.

For completeness, the no-hurd-console startx trace on the same
image:

  Xorg.1.log:
    [   47.959] (==) |-->Input Device "Generic Keyboard"
    [   48.144] (II) Loading
      /usr/lib/xorg/modules/input/kbd_drv.so
    [   48.147] (II) Module kbd: vendor="X.Org Foundation"
                     compiled for 1.21.1.21, module version = 2.1.0
    (server exits; log truncates at module load)

  startx stderr:
    Cannot open keyboard (Not a directory)
    xinit: giving up
    xinit: unable to connect to X server: Bad file descriptor

i.e. on the newer image kbd_drv.so dies at open(2) on /dev/kbd
because /dev/cons is a regular file, before ever reaching the
KDSKBMODE ioctl that the original report was about.

Once I know which of the three above is the answer, I will
withdraw the gnumach ask on this thread and (if relevant) send
the doc patch separately.

Thanks,
Borja Tarraso
[email protected]

El dom, 31 may 2026 a las 12:17, Samuel Thibault
(<[email protected]>) escribió:
>
> Hello,
>
> Borja Tarraso, le sam. 30 mai 2026 23:20:03 +0300, a ecrit:
> > On Debian GNU/Hurd 0.9 (gnumach 1.8+git20230410-1,
> > hurd 1:0.9.git20230520-7), Xorg's kbd_drv.so cannot bring up the
> > console keyboard because the gnumach console translator at
> > /dev/cons/kbd (/hurd/chrdev 156 33685736) returns EBADF for the
> > Linux-style set-event-mode ioctl that kbd_drv.so issues.
>
> Are you sure you have read
>
> https://www.debian.org/ports/hurd/hurd-install
>
> ?
>
> Notably, the fact that you need to be running the hurd console to be
> able to start Xorg? Xorg indeed cannot use the raw mach console, it
> needs the hurd console runnng.
>
> Samuel