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.