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.

Reply via email to