USB keyboard: missed/extra keystrokes

aragats

aragats

A month go I noticed missed characters when I type text/commands etc.
I decided to replace my cheap USB keyboard with something better.
I purchased a $50 "mechanical" keyboard, but nothing has changed – I still see missed characters. It looks like an anti-bouncing filter cuts certain keystrokes at some moments.

Would anybody advise what can cause that?
Thanks!
 
Way back in May 2013 (judging by the file date on my USB_README file) I had similar issues. The solution was to kill the uhidd daemon. I should note that I haven't needed to do this for some years.
 
I discovered that right after reboot my keyboard works great
After a while it starts failing. This time it types extra characters instead of missing like it was last time!
I never had such issues with FreeBSD 11.x. However, it looks to be a problem with this particular desktop PC with HP Z440 motherboard.
Any ideas?
 
tingo said:
Try a different keyboard?
Click to expand...
I already mentioned that I purchased this one namely because thought it's a keyboard issue.
Most likely it's a driver issue. Maybe I should rebuild the kernel to prove it by unloading/reloading the driver (which is built-in now).
 
Did you perhaps change the keyrate? You may want to play around with those settings to see if that improves things. Also check the BIOS setting for key repeat settings.

Code: 
     -r delay.repeat | speed
             Set keyboard delay (250, 500, 750, 1000) and repeat (34, 38, 42,
             46, 50, 55, 59, 63, 68, 76, 84, 92, 100, 110, 118, 126, 136, 152,
             168, 184, 200, 220, 236, 252, 272, 304, 336, 368, 400, 440, 472,
             504) rates, or if a speed argument is specified, it may be one of
             slow (1000.504), fast (250.34) or normal (500.126).
From kbdcontrol(1)
 
aragats said:
I already mentioned that I purchased this one namely because thought it's a keyboard issue.
Most likely it's a driver issue. Maybe I should rebuild the kernel to prove it by unloading/reloading the driver (which is built-in now).
Click to expand...
I missed that part, sorry.
Have you already tried different usb ports? Sometimes, it helps to change ports.
 
SirDice said:
Did you perhaps change the keyrate? You may want to play around with those settings to see if that improves things.
Click to expand...
I tried playing with the keyrate, but it doesn't help.
tingo said:
Have you already tried different usb ports? Sometimes, it helps to change ports.
Click to expand...
I have – using different USB controllers' ports, doesn't help much. It seems helping when I just switch to another port, but then continues the same way.
Only restarting the comuter help for certain amount of time.
 
I think the HP Z440 has a PS/2 connector, so you could try using the little green USB to PS/2 adaptors that HP supply, at least you would then know whether it was the keyboard or the USB on the motherboard. I very occasionally (once a year) get a sudden keyboard failure on an HP workstation, only solution is to power down and remove the power cord for a few minutes - must be some strange electrical fault.
 
tingo said:
Does the machine have the latest BIOS upgrade? If not, try to upgrade.
Click to expand...
I'll try one day, that's my main workstation, I cannot shut it down frequently.
RichardM said:
the HP Z440 has a PS/2 connector, so you could try using the little green USB to PS/2 adaptors
Click to expand...
That's right, but unfortunately modern keyboards do not support PS/2 protocol anymore, those little adapters are passive. I tried unsuccesfully. Moreover, that keyboard won't even power up if only 5V provided on the USB connector (without data lines connected).
 
I am experiencing exactly this same issue (missed and additonal characters output while typing, temporarily reduced in frequency by reboot). I can witness the erroneous keyboard events at the console with
Code: 
evemu-record /dev/input/event1

My keyboard is a Logitech G413 Carbon (USB). BIOS is up-to-date (running a stock Dell Optiplex 9020). FreeBSD 13.0-RELEASE-p3, GENERIC amd64.

The keyboard works as it should if plugged into a machine running Windows.

Has anyone reported a bug, or found a solution?

Some settings I've attempted (in additon to those attempted by OP) include:
Code: 
hw.usb.ukbd.pollrate=1000
Code: 
kern.evdev.rcpt_mask=6
Code: 
kern.evdev.rcpt_mask=12

Details:

Code: 
$ xinput list
⎡ Virtual core pointer                                    id=2    [master pointer  (3)]
⎜   ↳ Virtual core XTEST pointer                          id=4    [slave  pointer  (2)]
⎜   ↳ System mouse                                        id=6    [slave  pointer  (2)]
⎜   ↳ Logitech USB Receiver                               id=10    [slave  pointer  (2)]
⎣ Virtual core keyboard                                   id=3    [master keyboard (2)]
    ↳ Virtual core XTEST keyboard                         id=5    [slave  keyboard (3)]
    ↳ System keyboard multiplexer                         id=7    [slave  keyboard (3)]
    ↳ ACPI video extension                                id=8    [slave  keyboard (3)]
    ↳ Power Button                                        id=9    [slave  keyboard (3)]
    ↳ Logitech G413 Carbon Mechanical Gaming Keyboard    id=11    [slave  keyboard (3)]
    ↳ Logitech G413 Carbon Mechanical Gaming Keyboard    id=12    [slave  keyboard (3)]

Code: 
$ libinput list-devices
Device:           System keyboard multiplexer
Kernel:           /dev/input/event1
Group:            2
Seat:             seat0, default
Capabilities:     keyboard

Device:           Logitech G413 Carbon Mechanical Gaming Keyboard, class 0/0, rev 2.00/14.00, add
Kernel:           /dev/input/event5
Group:            6
Seat:             seat0, default
Capabilities:     keyboard

Device:           Logitech G413 Carbon Mechanical Gaming Keyboard, class 0/0, rev 2.00/14.00, add
Kernel:           /dev/input/event6
Group:            7
Seat:             seat0, default
Capabilities:     keyboard
 
JBR Are you experiencing this only in GUI applications or also in "the raw shell"? I have experienced similar issues which turned out to be a localization thing where certain keystrokes required another keystroke to show up the symbol I wanted to type. I'm not sure if this is PEBKAC or intentional. I just selected the proper keyboard layout and things worked smoothly afterwards. However, this was not even on FreeBSD.
 
  • Thanks
Reactions: JBR
jbodenmann Thanks for the tip about localization, though I'm not sure what I would change...
Code: 
$ locale
LANG=en_US.UTF-8
LC_CTYPE="en_US.UTF-8"
LC_COLLATE=C
LC_TIME="en_US.UTF-8"
LC_NUMERIC="en_US.UTF-8"
LC_MONETARY="en_US.UTF-8"
LC_MESSAGES="en_US.UTF-8"
LC_ALL=

And
Code: 
# /etc/rc.conf
keymap="us"

I'm experiencing missed and additional characters in both VT (the terminal before startx) and X.

Perhaps it would have something to do with iconv()? E.g.
Code: 
# /boot/loader.conf
libiconv_load="YES"
libmchain_load="YES"
Code: 
# /etc/rc.conf
kiconv_preload="YES"
kiconv_local_charsets="UTF-8"
kiconv_foreign_charsets="UTF-8"
 
I don't think it's related to localization.
As I mentioned in the OP, it happened after certain updates (most likely). First I thought it's a hardware issue, but after replacing the keyboard and even switching to PS/2 nothing has changed.
Unfortunately I cannot tell how it got fixed then, since I replaced my motherboard (for a different reason), and made a clean installation of a fresher FreeBSD. So far haven't seen this issue (currently running FreeBSD 13.0-RELEASE).
There is another issue I see in the same box (and always have seen). Not sure whether it's related to the OP problem. When it boots up, the keyboard behaves strangely at the login prompt: it types uppercase letters, but after hitting Enter it starts typing lowercase.
 
JBR said:
Thanks for the tip about localization, though I'm not sure what I would change...
Click to expand...
I think jbodenmann is referring to a US keymap variant that you can set with /usr/local/bin/setxkbmap -layout us -variant intl. Once activated, pressing the single quote may give nothing, then pressing character a will give an á. Likewise, double quote followed by an e will give ë. It's called US International, sauerkraut version. But I think aragats may be right, this looks somewhat different.
 
Tieks said:
I think jbodenmann is referring to a US keymap variant that you can set with /usr/local/bin/setxkbmap -layout us -variant intl. Once activated, pressing the single quote may give nothing, then pressing character a will give an á. Likewise, double quote followed by an e will give ë. It's called US International, sauerkraut version. But I think aragats may be right, this looks somewhat different.
Click to expand...
Ah yes, that was exactly it. Ever since then I just set us:intl on every machine I use.

But yes, I fully agree that what you guys are seeing seems vastly different. Spooky stories actually - nothing for the overly paranoid! :D
 
aragats I have to agree that updating caused this. The 13.0-RELEASE was working perfectly on this machine until this suddenly began, and the only relevant change I could possibly have made was a pkg upgrade. I'm not experiencing the unwanted uppercase, however.

Tieks Yes, I'm sure I would have noticed accented characters if XkbOptions were the cause. And that doesn't account for this happening at the TTY. In my case the extraneous characters are exactly those I intended to type, just multiplied.

jbodenmann This is "ghost in the machine" kind of stuff for sure.

My initial thinking was that this had to do with all the libinput and evdev changes happening around X, until I discovered it was happening outside of X. Unfortunately, I don't know of what other knobs I can turn (whether in sysctl.conf, rc.conf, or /boot/loader.conf) than those two I have already (i.e. pollrate and rcpt_mask).

I have another Dell Optiplex 9020 that I can install something on... I suppose it would be interesting to see if another FreeBSD install on a different machine with same hardware will produce the same problem.
 
I've discovered that this issue (missed and additional characters output while typing), as I've been experiencing it, can be solved for working in the console (but not X) by installing and enabling sysutils/uhidd, and blacklisting the USB kernel modules that would otherwise compete with it:
Code: 
# /etc/rc.conf
devmatch_blacklist="uhid.ko ums.ko usbhid.ko"
uhidd_flags="-kmohsu"
uhidd_enable="YES"

This fixes the problem. But it also prevents X from receiving any input whatsoever. sysutils/uhidd is apparently meant to work only in the console. (See Thread 6253 for detail.)

My assumption is that the kernel's USB modules can't handle my Logitech G413 keyboard (another relevant bug is PR 254974). However, I've not yet tested with a PS/2 keyboard, so that remains to be done.
 
Over the course of the past week I've tested to see if this problem exists with both a PS\2 keyboard from the 90's and another brand of relatively new USB keyboard (a Rapoo E9070). Relying on only the default USB kernel modules installed with the GENERIC kernel, both of these keyboards worked without missing characters or outputting additional characters, in X and the console. Consequently it would seem this problem is particular to either Logitech keyboards, just the Logitech G413 (which is still on the market at time of writing), or the Logitech G14 that I was using.

I had another (new) Logitech G14 on-hand, so I am now using it to see if the problem persists. If not, I'll assume that the problem was with the keyboard itself.
 
You must log in or register to reply here.
Back
Top