Support FnLk transparently in kernel?
Opened this issue · 1 comments
In a previous version of the patch, you attempted to handle FnLk directly in the driver, instead of in /sys. Why was this changed? It seems like the perfect thing to handle directly in the driver and not expose to userspace at all.
Arguably the kernel shouldn't know about Fn State, just like it doesn't know about Caps state, etc. But yes, it would be practically neater.
The Bluetooth keyboard is quite happy sending reports back to the keyboard within an interrupt context, so switching FnLk states worked easily within the kernel when just supporting the Bluetooth version. The USB version cannot do this, since code in an interrupt context cannot sleep, so the original code got removed.
Using a work queue or something would be the way to work around this, but it was a significant amount of extra code to write in comparison to a tiny userspace handler. And (somewhat selfishly) I have no intention to use FnLk as a FnLk key anyway (I use it as KEY_SCREENLOCK), so didn't do it.