Some keys are not sent

[adorableCapibara]

Hi,
I'm experiencing a weird problem with the remapper (single pico version). I've got a couple keyboards: on one keyboard everything works as expected, on the second one some keys (eg W, R, T, Enter, Backspace,....) are not sent to the operating system, even when no mapping is defined at all. I've tried the old tricks: reload the configuration, unplug replug and so on, with no luck.
The weird thing is that looking into the monitor page (in the web tool) the keys are actually sent by the keyboard. Is there any more advanced debugging I could do to understand what's going on?
Cheers

PS: Thank you so much for this fantastic project, this single pico version using PIO is exactly what I was trying to do, but never managed to

[itsnoteasy]

It could be a switch bounce issue? have you tried swapping out the switches to see if anything changes.

[adorableCapibara]

I'm not very familiar with switch bounce, I suppose it refers to the input floating between 1 and 0. I cannot swap the switches but I've messed a bit with the debounce settings, to no use. If it was a bounce issue I suppose I should see some randomness, but it is super consistent: all the keys are visible in the monitor page but some of them just don't seem to reach the operating system (even with no mapping defined and with pass through on all layers)

[itsnoteasy]

That's fair. Do you have the model of the malfunctioning keyboard. it may be something with a problematic usb implementation, for instance vusb is known to cause issues dropping keystrokes.

[adorableCapibara]

It's a AUKEY KM-G12 but could be some sort of rebranding. Looking it up in device manager I got the vendor and product identifiers, don't konw if this could be of any help => HID\VID_04D9&PID_A1CD&REV_0200&MI_00

[itsnoteasy]

Ah i had an rgb keyb like that one time. it was truly haunted, would start typing on its own. as a matter of interest, try turn off the rgb lighting, iirc it was fn+0, you will likely know the correct keycode, and then try error testing hid-remapper again. if the keyboard is at fault then it's hardly fair to complain here.

[adorableCapibara]

The keyboard works fine when connected directly to the computer, and even when connected to the remapper the keys are sent as expected (looking at the monitor page), that's why I think the issue lies somewhere in the remapper.
Tried on another computer, same behaviour. I've tried also to turn off the lighting as suggested but nothing changed.
Btw I'm really not complaining: I absolutely love this project and I'm grateful for it..... I was just wondering what could be the issue here and where to start if I wanted to investigate it further

[jfedor2]

So just to be clear, some keys show up in the monitor tab and at the same time (the same keystrokes) are not sent to the PC? But with a different keyboard connected to the same setup/configuration, all keys work?

Are you pressing one key at a time? I'm asking because there's a known 6KRO-related issue (#70).

[adorableCapibara]

Yes, exactly. I have this issue only with this keyboard: the same configuration with another keyboard works flawlessy.
With this keyboard some keys (always the same keys) light up in the monitor tab but are not sent to the PC, even when no mapping is defined, even pressing one key at a time.

[Kytthethief]

First off, thank you so very much for this project! This has made my Razer Tartarus Pro usable after learning how much I hate their software!

I am, however, having this exact same issue with the Left Shift. It shows up in the Monitor tab, but regardless of mapping or being unmapped, it does not function. When plugged directly into Windows without the HID Remapper device, the shift button functions just fine.

My situation sounds much the same, and yes, even when only pressing the one key, it still doesn't work. I am, however, using the Adafruit Feather RP2040 with USB Type A Host linked in the readme. This is the only key I have this issue with. Even the mouse wheel works!

On a hunch, I tried taking the address that comes up in Monitor and editing the entry in the Inspector in the Select Input window, and directly added its address. This did not solve the issue. In fact, it just showed up as "Left Shift" again.

On another hunch, I also tried unplugging from my Win11 Desktop and plugging it into my Win10 laptop. Exact same behaviour. I'm pretty flummoxed!

[jfedor2]

Can you try dumping the keyboard's report descriptor with Wireshark? Start the capture, plug the keyboard in, maybe press the keys that are giving us trouble a few times?

[Kytthethief]

So I did three tests.

The first is the keyboard without HID remapper.

The second is with. The key does not activate when pressed.

The third is interesting. I started over again and this time, opened the configuration page in Chromium. The key activated... only when the Monitor page was active on the tab. It did not matter if it was the active window or not, but Wireshark showed activity with this keypress ONLY with the monitor tab activated. Only this key was pressed.

dumpraw.txt
dump2040.txt
dumprawHIDMonitor.txt

[jfedor2]

That's normal, that's how the monitor works - it sends data over USB so that it can show up in the browser interface (on a separate channel). So that's what you're seeing.

Can you post the .pcap file (or .pcapng) for the first dump (the one where the keyboard is connected directly to the PC)?

[Kytthethief]

I believe I did this correctly. Here you go!
Direct.zip

[jfedor2]

Ah, I think I can see what's going on.

The keyboard has a report descriptor that has two ways of encoding the modifier keys (shift, control, alt, etc.):

0x05, 0x01,        // Usage Page (Generic Desktop Ctrls)
0x09, 0x06,        // Usage (Keyboard)
0xA1, 0x01,        // Collection (Application)
0x85, 0x01,        //   Report ID (1)
0x05, 0x07,        //   Usage Page (Kbrd/Keypad)
0x19, 0xE0,        //   Usage Minimum (0xE0)
0x29, 0xE7,        //   Usage Maximum (0xE7)
0x15, 0x00,        //   Logical Minimum (0)
0x25, 0x01,        //   Logical Maximum (1)
0x75, 0x01,        //   Report Size (1)
0x95, 0x08,        //   Report Count (8)
0x81, 0x02,        //   Input (Data,Var,Abs,No Wrap,Linear,Preferred State,No Null Position)
0x19, 0x00,        //   Usage Minimum (0x00)
0x2A, 0xFF, 0x00,  //   Usage Maximum (0xFF)
0x15, 0x00,        //   Logical Minimum (0)
0x26, 0xFF, 0x00,  //   Logical Maximum (255)
0x75, 0x08,        //   Report Size (8)
0x95, 0x16,        //   Report Count (22)
0x81, 0x00,        //   Input (Data,Array,Abs,No Wrap,Linear,Preferred State,No Null Position)
0xC0,              // End Collection

The first byte encodes the the modifiers on individual bits and then there are 22 bytes that encode all the other keys (as an array, meaning that it lists the codes for all the keys that are currently pressed), but can also encode the modifiers (the range includes their codes).

When you press Left Shift, what the keyboard actually does (we can see it in the capture) is it sends all zeros in the first byte and then lists the code for Left Shift (0xE1) in the following bytes. Strictly speaking it's reporting conflicting information: it says that the key is pressed in one place and that it is released in another. Presumably the manufacturer never saw it as a problem because Windows interprets this as the key being pressed. HID Remapper interprets it as the key not being pressed (I think it's actually not deterministic). With the added confusion of it showing up in the monitor.

I need to think if there's some generic way of handling this. Worst case scenario we can probably add a quirk (special handling) for this keyboard.

[Kytthethief]

Ah! I see! Perhaps that has something to do with the fact that this keyboard uses optical switches to make them "pressure sensitive" via how much light is blocked via the optical switches. Or the fact that this keyboard can also read as an Xbox controller if you use Razer's control software to switch it into that mode.

I simply use it as a keyboard for the form factor which seemed to work only as a keyboard without additional software. It's very odd that all the other keys don't seem to have this same behaviour.

All the same, I'm glad I could help find one possible cause of @adorableCapibara's issue. I hope it's the same one. :)

Very much looking forward to the fix! It'd be nice to have that key back again.

[jfedor2]

The latest release contains a fix that should make the Razer Tartarus Pro shift key work.

@adorableCapibara If you're up for some troubleshooting, can you try dumping the report descriptor of your keyboard with Wireshark to see if it's the same issue? Or just test the latest release if you can.

[Kytthethief]

Working on the Razer Tartarus Pro, confirmed, at least! Thank you so much! Wonderful to have that key working. :)

[adorableCapibara]

Hi, tested the version r2024-01-10 and it is working fine also on my keyboard. Thank you so much!!

[adorableCapibara]

Issue is solved in version r2024-01-10