Opened 2 years ago
Last modified 2 years ago
#17560 assigned bug
on-screen paging stops working after control of USB hubs is taken over from the BIOS
| Reported by: | pulkomandy | Owned by: | nobody |
|---|---|---|---|
| Priority: | normal | Milestone: | Unscheduled |
| Component: | Drivers/Input | Version: | R1/beta3 |
| Keywords: | Cc: | ||
| Blocked By: | Blocking: | ||
| Platform: | All |
Description
Boot Haiku with on-screen debug enabled. Use keyboard to page through the output.
After "succesfully took ownership of the host controller" logs from USB (xhci or ehci), my keyboard stops working and I can't page through the output.
In the log there is a bunch of "new device connected" logs and then the disk partition scan starts. There is nothing about loading the USB HID driver at that point. Is the system locked waitinf for me to press a key because of that?
Change History (1)
comment:1 by , 2 years ago
| Component: | Drivers/USB/XHCI → Drivers/Input |
|---|---|
| Owner: | changed from to |
| Status: | new → assigned |
Note:
See TracTickets
for help on using tickets.
Yes.
This is not an XHCI/EHCI problem but a boot/input drivers problem. The USB stack is initialized very early on as part of the "boot" drivers group so we can have usb_disk available when searching for boot partitions. The onscreen-paging, on the other hand, is handled through the same mechanism KDL output is, and in order to support USB keyboards, relies on the USB-HID and usb_keyboard KDL add-on, both of which are initialized much later on, to work.
So, in order to make this work seamlessly, we'd probably have to load the USB input drivers much earlier, or at least the usb_keyboard KDL module (which may need some changes as I think it relies on usb_hid having already set some things up?)
Alternatively, we could try to detect something here and try to switch to "timeouts" mode for onscreen paging, which automatically moves to the next page after some amount of time.