Bug#963002: udev: Keyboard mis-detected as Apple
Am 18.06.20 um 00:04 schrieb Vroomfondel: > Is this something that's likely work-aroundable with udev rules or > tweaks to the hwdb or does the specific USB ID mean only a hardware fix > will work? I'm still reading up on how all those files fit together with > the module loading. If you want to create custom mappings, then create a hwdb file in /etc/udev/hwdb.d See the relevant man pages related to hwdb and https://wiki.archlinux.org/index.php/Map_scancodes_to_keycodes signature.asc Description: OpenPGP digital signature
Bug#963002: udev: Keyboard mis-detected as Apple
On 2020-06-17 21:52, Michael Biebl wrote: Control: tags -1 + moreinfo Hi Salutations! Am 17.06.20 um 14:08 schrieb Vroomfondel: Package: udev Version: 241-7~deb10u4 Severity: normal Dear Maintainer, * What led up to the situation? New Varmilo keyboard * What was the outcome of this action? Fn keys not working correctly * What outcome did you expect instead? Fn key to work out of the box (as it does with my other Varmilo KB) * Futher elaboration: I've run in to an odd problem recently with a new keyboard, a Varmilo VA88M (essentially the UK-ISO version of the VA87M); a fairly bog-standard tenkeyless keyboard. On first use everything seemed to work OK, but it eventualy transpired that the Fkeys weren't working as expected. F1 through F6 didn't work at all and F7 through F12 acted as media keys as if the Fn key was being pressed. Holding down the Fn key and pressing Fkeys they worked as expected, so the default behaviour of the keyboard was as if the Fn key was being held down all the time. Plugging in to a mate's windows machine, the same behaviour didn't occur. On inspecting lsusb, it seemed that the keyboard was perhaps being erroneously detected as an Apple keyboard. lsusb output: Bus 001 Device 007: ID 05ac:024f Apple, Inc. Tbh, that sounds like a hardware issue, and not like a software issue. Why does Varmilo VA88M use the same vendor id as Apple? That sounds fishy. No idea on that, but I've just checked with the windows machine there and it reports the same VID and PID there too (I just assume Windows' handling for this keyboard/Mac keyboards is different). Have you tried contacting the hardware vendor? Yes, I've fired off a separate query to the hardware vendor, waiting back on a response. There's a recent reddit post here with what sounds like the same issue but I can't load the page past the initial comment for some reason. https://www.reddit.com/r/Varmilo/comments/g4sabk/fn_lock_on_va87m/ In the meantime, or in the event of there not being a viable fix, are there any "cleaner" ways to work around the issue? From having a cursory glance through the comments in the /lib/udev/hwdb files it seems like custom overrides can be set there and submitted upstream if deemed useful. Is this something that's likely work-aroundable with udev rules or tweaks to the hwdb or does the specific USB ID mean only a hardware fix will work? I'm still reading up on how all those files fit together with the module loading.
Bug#963002: udev: Keyboard mis-detected as Apple
Control: tags -1 + moreinfo Hi Am 17.06.20 um 14:08 schrieb Vroomfondel: > Package: udev > Version: 241-7~deb10u4 > Severity: normal > > Dear Maintainer, > > * What led up to the situation? > New Varmilo keyboard > > * What was the outcome of this action? > Fn keys not working correctly > > * What outcome did you expect instead? > Fn key to work out of the box (as it does with my other Varmilo > KB) > > * Futher elaboration: > I've run in to an odd problem recently with a new keyboard, a Varmilo VA88M > (essentially the UK-ISO version of the VA87M); a fairly bog-standard > tenkeyless keyboard. > > On first use everything seemed to work OK, but it eventualy transpired that > the Fkeys weren't working as expected. F1 through F6 didn't work at all and > F7 through F12 acted as media keys as if the Fn key was being pressed. > Holding down the Fn key and pressing Fkeys they worked as expected, so the > default behaviour of the keyboard was as if the Fn key was being held down > all the time. Plugging in to a mate's windows machine, the same behaviour > didn't occur. > > On inspecting lsusb, it seemed that the keyboard was perhaps being > erroneously detected as an Apple keyboard. lsusb output: > Bus 001 Device 007: ID 05ac:024f Apple, Inc. > Tbh, that sounds like a hardware issue, and not like a software issue. Why does Varmilo VA88M use the same vendor id as Apple? That sounds fishy. Have you tried contacting the hardware vendor? signature.asc Description: OpenPGP digital signature
Bug#963002: udev: Keyboard mis-detected as Apple
Package: udev Version: 241-7~deb10u4 Severity: normal Dear Maintainer, * What led up to the situation? New Varmilo keyboard * What was the outcome of this action? Fn keys not working correctly * What outcome did you expect instead? Fn key to work out of the box (as it does with my other Varmilo KB) * Futher elaboration: I've run in to an odd problem recently with a new keyboard, a Varmilo VA88M (essentially the UK-ISO version of the VA87M); a fairly bog-standard tenkeyless keyboard. On first use everything seemed to work OK, but it eventualy transpired that the Fkeys weren't working as expected. F1 through F6 didn't work at all and F7 through F12 acted as media keys as if the Fn key was being pressed. Holding down the Fn key and pressing Fkeys they worked as expected, so the default behaviour of the keyboard was as if the Fn key was being held down all the time. Plugging in to a mate's windows machine, the same behaviour didn't occur. On inspecting lsusb, it seemed that the keyboard was perhaps being erroneously detected as an Apple keyboard. lsusb output: Bus 001 Device 007: ID 05ac:024f Apple, Inc. Corresponding udevinfo output confirming the VID and PID (but name is correctly identified as a Varmilo): udevadm info --path /devices/pci:00/:00:14.0/usb1/1-4/1-4:1.0/0003:05AC:024F.000D/input/input20 P: //devices/pci:00/:00:14.0/usb1/1-4/1-4:1.0/0003:05AC:024F.000D/input/input20 L: 0 E: DEVPATH=//devices/pci:00/:00:14.0/usb1/1-4/1-4:1.0/0003:05AC:024F.000D/input/input20 E: PRODUCT=3/5ac/24f/110 E: NAME="AONE Varmilo Keyboard" E: PHYS="usb-:00:14.0-4/input0" E: UNIQ="" E: PROP=0 E: EV=120013 E: KEY=1 0 0 0 1007b1007 ff9f207ac14057ff ffbeffdfffef fffe E: MSC=10 E: LED=1f E: MODALIAS=input:b0003v05ACp024Fe0110-e0,1,4,11,14,k71,72,73,74,75,77,78,79,7A,7B,7C,7D,7E,7F,80,81,82,83,84,85,86,87,88,89,8A,8C,8E,96,98,9E,9F,A1,A3,A4,A5,A6,AD,B0,B1,B2,B3,B4,B7,B8,B9,BA,BB,BC,BD,BE,BF,C0,C1,C2,CC,E0,E1,E3,E4,E5,E6,F0,1D0,ram4,l0,1,2,3,4,sfw E: SUBSYSTEM=input E: USEC_INITIALIZED=389851205999 E: ID_INPUT=1 E: ID_INPUT_KEY=1 E: ID_INPUT_KEYBOARD=1 E: ID_VENDOR=AONE E: ID_VENDOR_ENC=AONE E: ID_VENDOR_ID=05ac E: ID_MODEL=Varmilo_Keyboard E: ID_MODEL_ENC=Varmilo\x20Keyboard E: ID_MODEL_ID=024f E: ID_REVISION=0100 E: ID_SERIAL=AONE_Varmilo_Keyboard E: ID_TYPE=hid E: ID_BUS=usb E: ID_USB_INTERFACES=:030101:03: E: ID_USB_INTERFACE_NUM=00 E: ID_USB_DRIVER=usbhid E: ID_PATH=pci-:00:14.0-usb-0:4:1.0 E: ID_PATH_TAG=pci-_00_14_0-usb-0_4_1_0 E: ID_FOR_SEAT=input-pci-_00_14_0-usb-0_4_1_0 E: TAGS=:seat: As far as I can tell, this keyboard should be being claimed by plain usbhid but is instead being claimed by hid_apple instead. At first I thought blacklisting the hid_apple module would force it to be claimed by regular usbhid but that just stopped the keyboard from working at all. Looking in to the modinfo of hid_apple I can see there's an option named fnmode that governs the default behaviour of the Fn key which sounded exactly like the issue I was experiencing. parm: fnmode:Mode of fn key on Apple keyboards (0 = disabled, [1] = fkeyslast, 2 = fkeysfirst) (uint) Sure enough, creating a module override for hid_apple setting this to 2 worked around the issue and then the Fkeys worked as expected: options hid_apple fnmode=2 However this workaround is less then ideal (since if anyone did plug in a real apple keyboard this behaviour would be enforced for anything using hid_apple) so I was wondering if there was a way of fixing this "properly". I've never done any messing about of this sort before (first real issue I've ever had with linux device detection TBH) but after a wee dig around I found the following file which seems to suggest that all 05ac devices are always read as Apple keyboard devices: grep -nB1 Apple /lib/udev/hwdb.d/20-usb-vendor-model.hwdb 22796-usb:v05AC* 22797: ID_VENDOR_FROM_DATABASE=Apple, Inc. Ditto for the linux UDB ID repo: https://usb-ids.gowdy.us/read/UD/05ac/024f I realise this is probably fairly esoteric and I'm not sure why the KB seemingly has the same IDs as apple kit but is there a better workaround that can be done for keyboards based on e.g. the name? A quick mess around with udev rules didn't reveal any obvious ways of forcing any particular module. I have another Varmilo keyboard, a VA69M also with similar Fn key functionality that doesn't present this problem (but it doesn't present itself as an Apple keyboard either, it shows as a Holtek). -- Package-specific info: -- System Information: Debian Release: 10.4
