Opened 19 years ago
Closed 16 years ago
#155 closed bug (fixed)
keyboard doesn't always work
Reported by: | marcusoverhagen | Owned by: | korli |
---|---|---|---|
Priority: | critical | Milestone: | R1 |
Component: | - General | Version: | |
Keywords: | Cc: | diver, jonas.kirilla, siarzhuk | |
Blocked By: | Blocking: | ||
Platform: | All |
Description (last modified by )
The keyboard driver is not always opened by the input_server.
The ps2 bus manager does a devfs_publish_device "input/keyboard/at/0" with result B_OK, but input_server does ignore the device sometimes, and then the driver open hook is not called, and it doesn't work.
I added enough debug output to the normal (as in: not compiled as DEBUG=1) ps2 driver to make this visible, search for "keyboard_open" and "mouse_open".
Attachments (2)
Change History (28)
comment:1 by , 19 years ago
comment:2 by , 19 years ago
Might be a race condition between input_server scanning the add-on directories, and node monitoring them. I haven't checked how it's implemented, but it should first start node monitoring, and then scan the directory (ignoring duplicates).
comment:3 by , 19 years ago
/dev/input/keyboard is scanned one time at keyboard addon load. only /dev/input/ keyboard/usb is monitored. I suppose this can be changed.
comment:4 by , 19 years ago
The ps2 keyboard driver works different in haiku than in BeOS R5. It will publish devices after hotplug or shortly after the initial scanning of the /dev/input directory. This should for example fix the loss of key repeat settings when you unplug and replug the keyboard. Although the driver is not 100% finished, input_server really needs to node monitor all directories.
comment:5 by , 19 years ago
We should do the same for mouse, then. Also the mouse input add-on currently monitors only /dev/input/mouse/usb. Changing mouse and keyboard addons to monitor the parent directory should be a matter of seconds.
comment:6 by , 19 years ago
Scanning the parent directory doesn't help (much), as new entries in the sub directories could be published and removed at any time.
comment:7 by , 19 years ago
Status: | new → closed |
---|
comment:8 by , 19 years ago
Resolution: | → fixed |
---|
comment:9 by , 19 years ago
Added monitoring on input/keyboard/at in revision 16468. Hope this helps ...
comment:11 by , 19 years ago
Resolution: | fixed |
---|
comment:12 by , 19 years ago
Status: | closed → reopened |
---|
comment:13 by , 19 years ago
Cc: | added |
---|
comment:14 by , 18 years ago
Platform: | → All |
---|
Haiku revision 20387.
Testing 4 input devices:
- PS2 keyboard -- Microsoft Natural MultiMedia Keyboard 1.0A
- PS2 mouse -- Logitech, Wired, optical, scrolling works.
- USB keyboard -- Mac G3 Blue&White original USB keyboard.
- USB mouse -- Microsoft Wireless Optical Mouse Blue, scrolling works.
All four plugged in - All four work.
Only the PS2 keyboard plugged in -- No keyboard. Only the USB keyboard, plugged in at boot -- USB keyboard works PS2 keyboard + USB keyboard -- Only the USB keyboard works
The PS2 keyboard works if the PS2 mouse is plugged in. The USB keyboard works if plugged in at boot.
PS2 keyboard + PS2 mouse -> both mouse and keyboard work
The PS2 mouse appears to be working under any and all circumstances. The USB mouse works if plugged in at boot. The PS2 and USB mice work okay together.
USB mouse sometimes produces spurious mouse button presses and always at least one on startup. A block gets selected in Terminal the first time I move the USB mouse.
Neither USB Mouse nor USB Keyboard seem to be found when hotplugging. PS2 hotplugging (FWIW) doesn't appear to be working.
I think I've seen the PS2 keyboard start working when hotplugging a USB keyboard or mouse. At least if you end up in KDL, where the PS2 keyboard works. <:)
(PANIC: vm_page_fault: unhandled page fault in kernel space at 0xdeadbef3, ip 0x8032e810)
comment:15 by , 18 years ago
Cc: | added |
---|---|
Description: | modified (diff) |
comment:16 by , 18 years ago
Hello jonas.kirilla,
it is really a bad idea to add comments that describe a similar but different problem, especially to a bug report that you didn't file yourserv.
This bug report is *only* about input server not always opening a published device, not about "spurious mouse button presses" or anything else.
A ps2 keyboard related bug #1175 was fixed in hrev20828. Please test it. If you still have problems, open a *new* bug report, and you'll get help.
Please don't add any futher comments to this bug report, they will be ignored.
comment:17 by , 18 years ago
Hi korli,
I implemented a debugger command that allows to force a republishing of a ps2 device, and verified with a modified NodeMonitorTest that monitoring the directory /dev/input/mouse/ps really works.
So there must be a bug in input server that I can't find. Input server always seems to ignore those devices. Please have a look. Screenshot follows.
by , 18 years ago
Attachment: | haiku_ps2_mouse_node_monitor_test.png added |
---|
comment:18 by , 18 years ago
Cc: | added |
---|
comment:19 by , 18 years ago
Marcus, thanks for looking into this. The situation should be improved in revision 20918.
I tested successfully on QEmu the republishing of the ps2 mouse and the ps2 keyboard. Hope this helps. /dev/input/keyboard/usb and /dev/input/mouse/usb are not monitored if there is no device at boot up.
comment:20 by , 18 years ago
The situation got much worse. The Keyboard is no longer opened at all, touchpad works. Hot plugging an additional external ps2 mouse is deteczted by the driver, buzt input server ignors it.
Despite numerous efforts, I didn't manage to capture any input server debug output. Please help.
by , 18 years ago
comment:21 by , 18 years ago
Marcus, I could reproduce the problem with the snooze(). It should be fixed in revision 20984.
comment:22 by , 18 years ago
Korli, the situation has improved with your latest change :-)
Devices are detected properly on system start. Even the a hotplug is detected, and the device opened.
There is still one remaining problem, devices that are removed (unplugged) aren't reopened by input_server when it's republished.
comment:23 by , 18 years ago
With hrev20984, there is a pause on boot up before the PS/2 keyboard works, but it works now, every boot! Excellent work, Korli and Marcus! Thank you so much!
comment:26 by , 16 years ago
Resolution: | → fixed |
---|---|
Status: | reopened → closed |
Should be fixed by Axel's latest changes on input_server. There are still problems tracked in other bugs anyway.
Same here under vmware. Sometimes when haiku boots up, keyboard doesn't work. I think it's related. Tested with rev16392.