Opened 10 years ago

Closed 8 years ago

Last modified 8 years ago

#3077 closed bug (fixed)

Missed keystrokes and repeating keys on USB Keyboard

Reported by: tigerdog Owned by: mmlr
Priority: normal Milestone: R1
Component: Drivers/USB Version: R1/pre-alpha1
Keywords: Cc:
Blocked By: Blocking:
Has a Patch: no Platform: All

Description

I have a Logitech S510 wireless KB/Mouse combo on a composite receiver, connected to an OHCI USB port. These work fine in Win2K and Xubuntu. They also work fine under R5, BONE and Zeta as long as PS2 emulation is enabled in system BIOS.

Under Haiku, the system misses keystrokes if I type more than two characters per second; it also sometimes repeats the last typed key. This happens regardless of whether PS2 emulation is enabled on mobo BIOS and also happens whether PS2 KB is connected or not.

This was discussed in ticket $#1044. I thought the problem had cleared when composite support was enabled, but it did not and I'm only now reporting this bug.

Attachments (3)

usb_hid_debug.diff (807 bytes) - added by mmlr 10 years ago.
usb_hid.zip (11.2 KB) - added by mmlr 10 years ago.
syslog.zip (5.4 KB) - added by tigerdog 10 years ago.

Download all attachments as: .zip

Change History (24)

comment:1 Changed 10 years ago by tigerdog

FYI, this problem still exists under version 29127.

comment:2 Changed 10 years ago by mmlr

Status: newassigned

Can you try applying the attached patch and get me the debug output of some cases when this happens?

Changed 10 years ago by mmlr

Attachment: usb_hid_debug.diff added

comment:3 Changed 10 years ago by tigerdog

Unfortunately, I do not have the ability to build at the moment; I also don't have serial debug hooked up. If you can send me a built version of the driver, I'll see if I can scrounge up a debug cable.

I would really love to help fix this - it's one of the main reasons I can't use Haiku at the moment.

Changed 10 years ago by mmlr

Attachment: usb_hid.zip added

comment:4 Changed 10 years ago by mmlr

Attached. You don't need a serial cable, you can grab the output from the syslog as well.

comment:5 Changed 10 years ago by tigerdog

Thanks. The problem happens constantly, any time I type quickly. Slow typing (half my usual speed) is usually OK. I loaded the patched driver, rebooted Haiku, then started typing at the terminal prompt. The usual problems resulted.

I then dragged /boot/var/log/syslog onto my desktop to stop adding to it. That's what I've attached here.

Changed 10 years ago by tigerdog

Attachment: syslog.zip added

comment:6 Changed 10 years ago by mmlr

Sadly the output looks perfectly fine to me. Does the key repeat still happen or has that part been resolved at least? Since we are not even polling, it's not really possible to loose events because of an insufficient interval. The transfers are interrupt like, so they should react only on keypress and get all of them. The only thing I could imagine is that your keyboard simply doesn't have a good boot protocol implementation. Since other systems will use the keyboard in full HID mode they won't notice that. That the keyboard works in R5 is just because it uses it over BIOS emulation. It never uses it directly as a HID device, so this is not a reference.

comment:7 Changed 10 years ago by tigerdog

Key repeat still happens. I thought about BIOS emulation being an issue, so I disabled emulation in the BIOS setup. I know it was disabled because I was not able to select the boot OS on my GRUB menu. Yet the response was just the same. All other OSs (Xubunutu 8.10, Zeta, WinXP) work fine with BIOS emulation off or on. R5 and BONE require emulation ON but work OK in that mode. Only Haiku has issues. Is there any other test you can suggest?

comment:8 in reply to:  7 ; Changed 10 years ago by umccullough

Replying to tigerdog:

R5 and BONE require emulation ON but work OK in that mode. Only Haiku has issues. Is there any other test you can suggest?

That would be due to Haiku's USB stack "taking control" of the USB devices from the BIOS when it initializes... unlike BeOS.

Therefore it shouldn't require legacy emulation like BeOS.

Likewise, other modern OSes that fully support USB should be doing the same as Haiku... but obviously without the bug you're seeing ;)

comment:9 in reply to:  8 Changed 10 years ago by tigerdog

Replying to umccullough:

That would be due to Haiku's USB stack "taking control" of the USB devices from the BIOS when it initializes... unlike BeOS.

Which makes sense and proves BIOS emulation actually is getting invoked when enabled and not invoked when disabled in the BIOS. I think GRUB also confirms this. So the question is, why do all the other OSs take control correctly but Haiku not?

comment:10 Changed 10 years ago by anevilyak

BeOS hrev5 doesn't actually try to take control of it, it just uses it directly in via the BIOS. The other OSes in your list are using the full USB HID spec, which your keyboard seems to support properly. To make a long story short, in USB there are two different protocol specs for input devices. One is very primitive (what mmlr referred to as the "boot" protocol), and only supports simple keyboards and two button mice. This is what Haiku currently supports for keyboards. The other is the full HID spec, which is more like 150 pages, works quite differently, but if properly implemented supports any and every USB input device known to man (joysticks, 10 button programmable mice, you name it). Most other OSes will be speaking the latter, and as such might not see a problem if your keyboard doesn't correctly speak boot.

comment:11 Changed 10 years ago by tigerdog

thank you for the explanation, good Sir Yak. A most erudite and polite way of telling me I'm hosed for the time being... :) I'll try this with another couple of USB KBs I have access to and see if the problem continues or is keyboard-specific.

For the record, unit having trouble is part of a Logitech S510 wireless desktop set. Model # of keyboard (on bottom) is Y-RAK73.

comment:12 Changed 10 years ago by mmlr

Can you please retry with a revision >= hrev29154. It's possible that your keyboard enters the phantom state earlier than it should (as mine apparently does as well when typing really fast) and the missing phantom state handling would cause at least the repeated key issue. Not sure about the missed keys though, it's possible that this simply won't be solvable without going full HID.

comment:13 Changed 10 years ago by tigerdog

Testing now with 29155. Definitely a step in the right direction. No more repeating keys, but still occasionally dropping characters when typing quickly; even this seems somewat better. Thanks for all the effort. I will test with other keyboards and let you know what I find.

comment:14 Changed 9 years ago by mmlr

Full HID support has been implemented by now, so does this problem still exist?

comment:15 Changed 8 years ago by luroh

tigerdog, got any feedback on this one?

comment:16 Changed 8 years ago by anevilyak

FWIW, this occurs on my Kinesis as well, albeit also on OHCI which seems to be the source of the problem. mmlr and I tried debugging it once without much luck though.

comment:17 Changed 8 years ago by tigerdog

As of the last time I tried (a few weeks ago) this problem still happens. I will update the ticket next time I download and try a nightly.

comment:18 Changed 8 years ago by tigerdog

gentlemen, congratulations! I loaded the latest Haiku nightly (39918) and the keyboard and mouse work perfectly! This is the same hardware I've used previously (logitech S510 cordless keyboard and mouse with common USB receiver). My apologies for such a long delay in responding. New job, new responsibilities and I have been completely away from Haiku for almost a year. Many thanks for persevering! This bug seems to be squashed. Let's hope Yak has the same experience.

comment:19 Changed 8 years ago by mmlr

Resolution: fixed
Status: in-progressclosed

Most likely this was an issue caused by the uninitialized interval value. Possibly the poll interval was just large enough that the keyboard entered the phantom state during normal typing causing the missed keys (and key releases for that matter, causing the repeates). If this assumption is correct it was fixed by hrev39904.

comment:20 Changed 8 years ago by anevilyak

Over here I still see a problem with missing keystrokes and eventually device failure, but only immediate after boot. After unplug/replugging, it never happens again until a reboot. Assuming this winds up being Kinesis-specific (waiting for mmadia to confirm), will open a separate ticket for that particular device/controller combo.

comment:21 in reply to:  20 Changed 8 years ago by mmadia

Replying to anevilyak:

Over here I still see a problem with missing keystrokes and eventually device failure, but only immediate after boot. After unplug/replugging, it never happens again until a reboot. Assuming this winds up being Kinesis-specific (waiting for mmadia to confirm), will open a separate ticket for that particular device/controller combo.

The kinesis works as expected on my nForce 430 board now. #4067 is the ticket, where my issue was tracked.

Note: See TracTickets for help on using tickets.