"Stuck keys" issue in Keychron keyboard

[harshad]

I have been trying to use a Keychron K2 keyboard: ​​https://www.keychron.com/products/keychron-k2-hot-swappable-wireless-mechanical-keyboard on haiku. I use it in the wired mode, has a USB C connection. Whenever I start typing, the key gets 'stuck' i.e. keeps repeating and the system becomes unresponsive. Only way to fix it is by removing the cord.

Is there something I could try to get it working? One thing I have observed is under the Input applet, whenever I connect a normal keyboard, it adds only one Usb Keyboard entry. But when I connect the Keychron, 2-3 entries get added.

The listusb output is as below:

26ce:01a2 /dev/bus/usb/0/11 "ASRock" "LED Controller" ver. 0000
8087:0aa7 /dev/bus/usb/0/12 "Intel Corp." "" ver. 0001
05ac:024f /dev/bus/usb/0/6 "Apple, Inc." "Keychron K2" ver. 0104
046d:c245 /dev/bus/usb/0/7 "Logitech, Inc." "G400 Optical Mouse" ver. 6900
0000:0000 /dev/bus/usb/0/hub "HAIKU Inc." "XHCI RootHub" ver. 0300
0000:0000 /dev/bus/usb/1/hub "HAIKU Inc." "XHCI RootHub" ver. 0300
046d:c31d /dev/bus/usb/2/0 "Logitech, Inc." "Media Keyboard K200" ver. 6601
0000:0000 /dev/bus/usb/2/hub "HAIKU Inc." "XHCI RootHub" ver. 0300

the syslog and syslog.old files are attached

Here's what I found at the end of syslog:

KERN: usb hub 2: port 6: new device connected
USER 'KS': Notify of added/removed/started/stopped device
Last message repeated 2 times
KERN: usb_hid: keyboard device unhandled control 0x00002710
KERN: Last message repeated 2 times.
KERN: usb xhci 0: transfer error on slot 7 endpoint 3: USB transaction
KERN: usb_hid: error waiting for report: Device check-sum error
KERN: usb xhci 0: transfer error on slot 7 endpoint 5: USB transaction
KERN: usb hub 2: port 6: device removed
KERN: usb xhci 0: cancel queued transfers (1) for pipe 0xffffffff9a07d788 (1)
KERN: usb error xhci 0: cancel queued transfers: halted endpoint. reset!KERN: usb xhci 0: cancel queued transfers (0) for pipe 0xffffffff9a07d788 (1)
KERN: usb xhci 0: cancel queued transfers (0) for pipe 0xffffffff99f48c80 (0)
KERN: usb xhci 0: cancel queued transfers (0) for pipe 0xffffffff9a07d788 (1)
USER 'KS': Notify of added/removed/started/stopped device
KERN: usb xhci 0: cancel queued transfers (1) for pipe 0xffffffff99cf0658 (2)
KERN: usb error xhci 0: unsuccessful command 15, error Parameter (17)
KERN: usb error xhci 0: cancel queued transfers: could not stop endpoint: I/O error!
KERN: usb error xhci 0: unsuccessful command 15, error Parameter (17)
KERN: usb error xhci 0: unsuccessful command 12, error Context state (19)

[waddlesplash]

Please upgrade to a nightly build and retest.

[harshad]

Okay, so I tried installing two nightly builds- hrev56416 and hrev56413. Unfortunately couldn't install either as booting from the USB failed with this error: ​https://ibb.co/86WQ8Lr

[korli]

If the graphics card is a radeon hd, you can try fail-safe graphics in the boot loader.

[bipolar]

Replying to harshad:

In case booting with the fail-safe graphics driver (as korli suggests) works...

You may consider forcing its use on every boot. For that, create a file named packages under /boot/system/settings with the following content:

Package haiku {
	BlockedEntries {
		add-ons/kernel/drivers/bin/radeon_hd
	}
}

[harshad]

Thanks, was able to boot with the fail-safe graphics option. I upgraded my current installation to the current nightly build (hrev56416) using the instructions on this page ​https://www.haiku-os.org/guides/daily-tasks/updating-system

However the keyboard issue persists in this build as well. Some more observations:

1. It seems that the system takes some time to register a keystroke on the keyboard. I need to hit the key 3-4 times in quick succession - and then it starts to print the letter over and over. If I use Backspace, the same thing happens - it keeps backspacing indefinitely.
2. while it is repeating the key over and over, if I hit another key, it does not rgister. If I keep hit it 3-4 times, then the new key registers and starts repeating.
3. If I hit Esc 3-4 times, then the printing stops, however the system becomes unresponsive. if I plug out the keyboard, it starts working fine again. Pasting the end of syslog below, if it helps.

I want to help troubleshoot this issue - how else can I go about it? I am not familiar with hardware issues (or programming for that matter), so if it's going to be beyond my ken, give it to me straight :) But I want to try and fix this.

syslog

KERN: slab memory manager: created area 0xffffffffab801000 (15542)
KERN: usb hub 2: port 6: new device connected
USER 'KS': Notify of added/removed/started/stopped device
Last message repeated 2 times
KERN: usb_hid: keyboard device unhandled control 0x00002710
KERN: Last message repeated 2 times.
KERN: usb xhci 0: transfer error on slot 5 endpoint 3: USB transaction
KERN: usb_hid: error waiting for report: Device check-sum error
KERN: usb xhci 0: transfer error on slot 5 endpoint 5: USB transaction
KERN: usb hub 2: port 6: device removed
KERN: usb error xhci 0: cancel queued transfers: halted endpoint, reset!
KERN: usb xhci 0: cancel queued transfers (0) for pipe 0xffffffff9a3c3680 (0)
KERN: usb xhci 0: cancel queued transfers (0) for pipe 0xffffffff9a398e18 (1)
USER 'KS': Notify of added/removed/started/stopped device
KERN: usb xhci 0: cancel queued transfers (1) for pipe 0xffffffff9a1c70a8 (2)
KERN: usb error xhci 0: cancel queued transfers: halted endpoint, reset!
KERN: usb xhci 0: cancel queued transfers (0) for pipe 0xffffffff9a3c3680 (0)}}}
 

[harshad]

Yes it worked. Thanks for this - I will stick to the nightly builds for now and add the entries you have suggested to boot up.

Replying to bipolar:

Replying to harshad:

In case booting with the fail-safe graphics driver (as korli suggests) works...

You may consider forcing its use on every boot. For that, create a file named packages under /boot/system/settings with the following content:

Package haiku {
	BlockedEntries {
		add-ons/kernel/drivers/bin/radeon_hd
	}
}

[pulkomandy]

In /tmp you can find HID report descriptors for your keyboard, please attach them to this ticket as well. You will find the USB vendor and device Id in the filenames to identify the correct files (something like 046d:c31d according to your listusb output).

We can use these to identify if the keyboard is doing anything we don't expect in the way it reports its keypresses.

[harshad]

Attached both the files I found. These were in/boot/system/cache/tmp

[korli]

Please also report in a new ticket the radeon_hd problem with a clean syslog.

[harshad]

Reported at #17939

Replying to korli:

Please also report in a new ticket the radeon_hd problem with a clean syslog.

[waddlesplash]

#17699 and #14919 seem potentially relevant.

[waddlesplash]

Please retest after hrev56570.

[Carl_Miller]

I was having the same issue with my ONN (Walmart store brand) mechanical keyboard, which was only remedied by switching to another keyboard when running beta3; I was having a similar issue with my USB microphone causing lag spikes. Neither issue occurs in beta4 TC0; USB IDs follow.

3938:1205 /dev/bus/usb/0/9 "KMF" "Onn Mechanical Gaming Keyboard" ver. 0112

0d8c:0030 /dev/bus/usb/0/12 "C-Media Electronics, Inc." "JLab GO Talk" ver. 0201