https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=288968
Jordan Gordeev <jgopensou...@proton.me> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |jgopensou...@proton.me,
| |w...@freebsd.org
--- Comment #9 from Jordan Gordeev <jgopensou...@proton.me> ---
When hw.usb.usbhid.enable=1 the hkbd(4) driver attaches to USB keyboards
instead of the ukbd(4) driver. What happens in Parallels VMs and apparently in
other virtualized environments is that hkbd(4) successfully attaches to a
keyboard but connecting the keyboard to the keyboard multiplexer fails. Key
input is handled perfectly by hkbd(4) and the keyboard can probably be made to
work in X11 but on the video console any typing by the user is ignored (with
GENERIC kernel and default settings).
The exact sequence of function calls is this:
hkbd_attach()
kbd_register()
kbdmux_ioctl(KBADDKBD)
hkbd_ioctl(KDSKBSTATE)
hkbd_ioctl_locked(KDSKBSTATE)
hkbd_ioctl_locked(KDSETLED)
hkbd_set_leds()
hid_write()
hid_write() returns an error (EIO), which is propagated back to
kbdmux_ioctl(KBADDKBD). Because of the error the attempt to add the keyboard to
the keyboard multiplexer is abandoned.
You don't need Parallels to reproduce this. It's enough to modify
hkbd_set_leds() to always return an error.
The ukbd(4) driver ignores errors from setting the indicator LEDs. As the
primary function of a keyboard is user input and the indicator LEDs are a
secondary concern, it makes sense to ignore errors related to the LEDs when
adding a keyboard to the keyboard multiplexer.
I'm adding wulf@ to the CC list as he wrote the hkbd(4) driver and possesses
relevant expertise.
--
You are receiving this mail because:
You are the assignee for the bug.
