Model01-Firmware
Model01-Firmware copied to clipboard
keyboardio
Weird behavior on linux 5.12?
The summary of my problem can be found in NixOS/nixpkgs#126423.
Something's changed about the way the Model 01 is detected, and it seems related to it not getting assigned the right layout on boot. See especially this comment which shows some changes in the output of xinput list.
Reproduced on NixOS, but I can try and test this behavior on Archlinux tomorrow morning, I'll report back with my findings. Hopefully the Model 01's firmware repo is the right place to report this? Please let me know.
I can also provide dmesg output or other if needed
If it helps, my current firmware is the one installed on the Model 01 by Chrysalis v0.8.4
Here's a dmesg output on a 5.10 kernel: (keyboard is plugged in since boot)
usb 1-6: New USB device found, idVendor=1209, idProduct=2301, bcdDevice= 1.00
usb 1-6: New USB device strings: Mfr=1, Product=2, SerialNumber=3
usb 1-6: Product: Model 01
usb 1-6: Manufacturer: Keyboardio
usb 1-6: SerialNumber: Ckbio01E
hid: raw HID events driver (C) Jiri Kosina
usbcore: registered new interface driver usbhid
usbhid: USB HID core driver
input: Keyboardio Model 01 as /devices/pci0000:00/0000:00:01.2/0000:01:00.0/usb1/1-6/1-6:1.2/0003:1209:2301.0001/input/input0
hid-generic 0003:1209:2301.0001: input,hidraw0: USB HID v1.01 Mouse [Keyboardio Model 01] on usb-0000:01:00.0-6/input2
input: Keyboardio Model 01 System Control as /devices/pci0000:00/0000:00:01.2/0000:01:00.0/usb1/1-6/1-6:1.3/0003:1209:2301.0002/input/input1
ata3: SATA link down (SStatus 0 SControl 300)
input: Keyboardio Model 01 Keyboard as /devices/pci0000:00/0000:00:01.2/0000:01:00.0/usb1/1-6/1-6:1.3/0003:1209:2301.0002/input/input2
input: Keyboardio Model 01 Consumer Control as /devices/pci0000:00/0000:00:01.2/0000:01:00.0/usb1/1-6/1-6:1.3/0003:1209:2301.0002/input/input3
input: Keyboardio Model 01 Mouse as /devices/pci0000:00/0000:00:01.2/0000:01:00.0/usb1/1-6/1-6:1.3/0003:1209:2301.0002/input/input4
hid-generic 0003:1209:2301.0002: input,hidraw1: USB HID v1.01 Keyboard [Keyboardio Model 01] on usb-0000:01:00.0-6/input3
input: Keyboardio Model 01 as /devices/pci0000:00/0000:00:01.2/0000:01:00.0/usb1/1-6/1-6:1.4/0003:1209:2301.0003/input/input5
hid-generic 0003:1209:2301.0003: input,hidraw2: USB HID v1.01 Keyboard [Keyboardio Model 01] on usb-0000:01:00.0-6/input4
and now on 5.12:
usb 1-6: New USB device found, idVendor=1209, idProduct=2301, bcdDevice= 1.00
usb 1-6: New USB device strings: Mfr=1, Product=2, SerialNumber=3
usb 1-6: Product: Model 01
usb 1-6: Manufacturer: Keyboardio
usb 1-6: SerialNumber: Ckbio01E
hid: raw HID events driver (C) Jiri Kosina
usbcore: registered new interface driver usbhid
usbhid: USB HID core driver
input: Keyboardio Model 01 as /devices/pci0000:00/0000:00:01.2/0000:01:00.0/usb1/1-6/1-6:1.2/0003:1209:2301.0001/input/input0
hid-generic 0003:1209:2301.0001: input,hidraw0: USB HID v1.01 Mouse [Keyboardio Model 01] on usb-0000:01:00.0-6/input2
input: Keyboardio Model 01 System Control as /devices/pci0000:00/0000:00:01.2/0000:01:00.0/usb1/1-6/1-6:1.3/0003:1209:2301.0002/input/input1
ata3: SATA link down (SStatus 0 SControl 300)
input: Keyboardio Model 01 Keyboard as /devices/pci0000:00/0000:00:01.2/0000:01:00.0/usb1/1-6/1-6:1.3/0003:1209:2301.0002/input/input2
input: Keyboardio Model 01 Mouse as /devices/pci0000:00/0000:00:01.2/0000:01:00.0/usb1/1-6/1-6:1.3/0003:1209:2301.0002/input/input3
hid-generic 0003:1209:2301.0002: input,hidraw1: USB HID v1.01 Keyboard [Keyboardio Model 01] on usb-0000:01:00.0-6/input3
input: Keyboardio Model 01 as /devices/pci0000:00/0000:00:01.2/0000:01:00.0/usb1/1-6/1-6:1.4/0003:1209:2301.0003/input/input4
hid-generic 0003:1209:2301.0003: input,hidraw2: USB HID v1.01 Keyboard [Keyboardio Model 01] on usb-0000:01:00.0-6/input4
So the line about Keyboardio Model 01 Consumer Control is indeed missing in the 5.12 output
How easy is it for you to try a 5.11 kernel? There's a lot that's changed between 5.10 and 5.12. But this sounds like it's potentially a kernel regression.
@algernon thoughts?
5.11 has no problems, xinput list is the same as on 5.10, so I'd imagine it's 5.12 that is the culprit :/
https://lore.kernel.org/lkml/[email protected]/
This seems to be related. There were changes in 5.12 that affected the HID subsystem, which might've broken things. Certainly looks like a kernel-related issue. I'll try to dig a bit deeper, but don't have the resources to bisect the kernel, so if looking at logs and diffs doesn't help, I guess we'll have to e-mail lkml.
Okay so installing / enabling libinput (though I don't think libinput has anything to do with keyboards, only mice / touchpads?) on 5.12 fixes the original problem for me; that is, given the following configuration in /etc/X11/xorg.conf.d/00-keyboard.conf, I'm getting the right keyboard layout applied from the get-go.
Section "InputClass"
Identifier "Keyboard catchall"
MatchIsKeyboard "on"
Option "XkbModel" "pc104"
Option "XkbLayout" "fr"
Option "XkbOptions" "terminate:ctrl_alt_bksp"
Option "XkbVariant" "us"
EndSection
I don't see how that makes any sense, but as far as I'm concerned the problem I had is solved, so feel free to close this issue if you'd like :)
However if the disappearance of Keyboardio Model 01 Keyboard Consumer Control from the xinput list is unexpected, then yeah I think there's some regression somewhere that you guys might want to know about. (I have no idea what this Keyboardio Model 01 Keyboard Consumer Control is, nor how important it is, feel free to enlighten me!)
Indeed, though my problem is solved when also enabling libinput on 5.12, xinput list looks like that:
⎡ Virtual core pointer id=2 [master pointer (3)]
⎜ ↳ Virtual core XTEST pointer id=4 [slave pointer (2)]
⎜ ↳ Keyboardio Model 01 id=8 [slave pointer (2)]
⎜ ↳ Keyboardio Model 01 Keyboard id=10 [slave pointer (2)]
⎜ ↳ Keyboardio Model 01 Mouse id=11 [slave pointer (2)]
⎜ ↳ MX Master Mouse id=16 [slave pointer (2)]
⎣ Virtual core keyboard id=3 [master keyboard (2)]
↳ Virtual core XTEST keyboard id=5 [slave keyboard (3)]
↳ Power Button id=6 [slave keyboard (3)]
↳ Power Button id=7 [slave keyboard (3)]
↳ Keyboardio Model 01 System Control id=9 [slave keyboard (3)]
↳ Keyboardio Model 01 id=12 [slave keyboard (3)]
↳ ASRock LED Controller id=13 [slave keyboard (3)]
↳ Keyboardio Model 01 Keyboard id=14 [slave keyboard (3)]
↳ MX Master Keyboard id=15 [slave keyboard (3)]
Copy pasting from the other thread, on 5.10 it's consistently looking like this:
⎡ Virtual core pointer id=2 [master pointer (3)]
⎜ ↳ Virtual core XTEST pointer id=4 [slave pointer (2)]
⎜ ↳ Keyboardio Model 01 id=8 [slave pointer (2)]
⎜ ↳ Keyboardio Model 01 Consumer Control id=11 [slave pointer (2)]
⎜ ↳ Keyboardio Model 01 Mouse id=12 [slave pointer (2)]
⎣ Virtual core keyboard id=3 [master keyboard (2)]
↳ Virtual core XTEST keyboard id=5 [slave keyboard (3)]
↳ Power Button id=6 [slave keyboard (3)]
↳ Power Button id=7 [slave keyboard (3)]
↳ Keyboardio Model 01 System Control id=9 [slave keyboard (3)]
↳ Keyboardio Model 01 Keyboard id=10 [slave keyboard (3)]
↳ Keyboardio Model 01 id=13 [slave keyboard (3)]
↳ ASRock LED Controller id=14 [slave keyboard (3)]
and on 5.12 without libinput enabled:
⎡ Virtual core pointer id=2 [master pointer (3)]
⎜ ↳ Virtual core XTEST pointer id=4 [slave pointer (2)]
⎜ ↳ Keyboardio Model 01 id=8 [slave pointer (2)]
⎜ ↳ Keyboardio Model 01 Keyboard id=10 [slave pointer (2)]
⎜ ↳ Keyboardio Model 01 Mouse id=11 [slave pointer (2)]
⎣ Virtual core keyboard id=3 [master keyboard (2)]
↳ Virtual core XTEST keyboard id=5 [slave keyboard (3)]
↳ Power Button id=6 [slave keyboard (3)]
↳ Power Button id=7 [slave keyboard (3)]
↳ Keyboardio Model 01 System Control id=9 [slave keyboard (3)]
↳ Keyboardio Model 01 id=12 [slave keyboard (3)]
↳ ASRock LED Controller id=13 [slave keyboard (3)]
So looks like the Keyboardio Model 01 Keyboard device makes a comeback in the Virtual core keyboard section when enabling libinput?.
PS: thanks for the quick answers and for the awesome keyboard / firmware, I'm looking forward to ordering a Model 100 as soon as it's available for pre order! :heart:
It appears 5.12 received a lot of HID updates, so plenty of stuff to plow through.
I'm not even sure the kernel changes are wrong; they might be perfectly correct but the change in behavior could just be triggering some weird timing problem in the way keyboard layouts are set in Xorg? This is all way out of my league, I'm just thinking out loud here :sweat_smile:
However if the disappearance of
Keyboardio Model 01 Keyboard Consumer Controlfrom thexinput listis unexpected, then yeah I think there's some regression somewhere that you guys might want to know about. (I have no idea what thisKeyboardio Model 01 Keyboard Consumer Controlis, nor how important it is, feel free to enlighten me!)
Consumer Control is pretty much the media keys, like Play/Pause, volume control, that kind of stuff. It's not necessarily a bug that it doesn't show up, but it might be. Can you perhaps test if media keys work?
Indeed, though my problem is solved when also enabling
libinputon 5.12,xinput listlooks like that:⎡ Virtual core pointer id=2 [master pointer (3)] ⎜ ↳ Virtual core XTEST pointer id=4 [slave pointer (2)] ⎜ ↳ Keyboardio Model 01 id=8 [slave pointer (2)] ⎜ ↳ Keyboardio Model 01 Keyboard id=10 [slave pointer (2)] ⎜ ↳ Keyboardio Model 01 Mouse id=11 [slave pointer (2)] ⎜ ↳ MX Master Mouse id=16 [slave pointer (2)]
There's no system control here, either, which to me, suggests that both Consumer and System Control were merged into "Keyboard", but a quick test of media keys could easily verify that suspicion. :)
Can you perhaps test if media keys work?
They do seem to work fine on 5.12 (tested both with/without the strange libinput "fix"), at least I've tested XF86AudioPlay, XF86AudioPrev, XF86AudioNext, XF86AudioLowerVolume, XF86AudioRaiseVolume and XF86AudioMute.