On Mon, 2018-03-05 at 10:31 +0100, Nestor Lopez Casado wrote: > Hello Florent, Hi Nestor, > In my view, this driver may not be a good idea. The default behaviour > of K290 is 'send multimedia keycodes' with the user given the choice > to change that behaviour via vendor commands. Putting a driver that > will unconditionally change that behaviour without the user's consent > might bother other users that prefer the multimedia keycodes by > default. Actually, the default behavior of the proposed driver is currently to let the K290 send multimedia keycodes by default (as if using the generic HID driver). And this behavior can be changed by using the fn_mode parameter. We may also add a third behavior consisting in not doing anything, and letting a user space application managing the keyboard, which could possibly be the default behavior. > Besides, I'd argue that instead of a kernel module this would be best > achieved from a user space application. Something in the lines of > Solaar (github pwr/solaar) or libratbag (there's an issue open to > support keyboards) or even a specific application built for the > purpose. Anyways, please collect the input from Benjamin and Jiri as > they as they best placed to advise than myself. Indeed, this driver is based on a working user space application available there https://github.com/milgner/k290-fnkeyctl . However, I feel a bit awkward to have to install a dedicated package, or compile & install an application to have proper support of a keyboard. I feel like it would be more beautiful to have it supported directly by a module, like most devices. Regards, Florent -- To unsubscribe from this list: send the line "unsubscribe linux-input" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
