On Mon, Feb 23, 2015, at 08:41, Bastien Nocera wrote: > > You could opt to change some of those keypresses dinamically into > > driver-specific > > ACPI events, by setting the keymap entry to KEY_RESERVED. The driver > > will > > issue HKEY events in that case. That will be an viable alternative for > > some of the new > > keys. > > I don't understand what you mean here. I mean please set anything that you don't have a keycode for in the new keymaps to either KEY_RESERVED (will issue an HKEY ACPI event) or KEY_UNKNOWN (will issue an input EV_KEY event for KEY_UNKNOWN grouped with an EV_MSC EV MSC_SCAN event that allows userspace to know which key was pressed/released even if it has no specific keycode). > > The beauty of it is that keymaps are configurable in run-time, so > > userspace can > > just set any key entries it wants to change to something else, and ACPI > > events will be > > suppressed if the entry is not set to KEY_RESERVED anymore. > > Keymaps are already configurable at run-time, that's how udev changes > keymaps. Or did you mean something else? I mean if anyone wants to change something that is KEY_RESERVED or KEY_UNKNOWN they can configure the driver to do so at runtime through the input device interface, i.e. get udev to do it. Nothing new, there. > > We need to be careful with tpacpi_input_send_key_masked(). If any of the > > codepaths > > could call it from the adaptative keyboard handling code, > > But we're not calling it from there, are we? Probably not, but it would be a good idea to double-check. -- "One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie." -- The Silicon Valley Tarot Henrique Holschuh -- 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
