On Thu, 17 Sep 2009, Dmitry Torokhov wrote: > On Thu, Sep 17, 2009 at 02:57:07PM -0300, Henrique de Moraes Holschuh wrote: > > On Wed, 16 Sep 2009, Rick L. Vinyard, Jr. wrote: > > > The M* keys are intended to provide a quick way to switch between key > > > mappings, with each mode having their own user-defined mappings. > > > > What I'd do in this case would be this: > > > > 1. Initially have the M* level-shift keys assigned KEY_RESERVED > > > > 2. Have a big enough keymap to map all keys in all M*-level shift states > > possible. > > > > Eg: > > START OF KEYMAP > > M* keys > > 1st set of G* keys > > 2nd set of G* keys > > 3rd set of G* keys... > > ... > > last set of G* keys > > END OF KEYMAP > > > > 3. Have the driver special-process M* level-shift keys *as long as they are > > still set to KEY_RESERVED* to select which part of the keymap is used to > > translate the other keys. Note that this likely means pressing a M* key > > would be transparent to userspace in this case, i.e. no events would be > > issued when a M* key is doing a level shift. > > > > So, you'd be able to set all mappings you want in the driver, and the M* > > keys would do what they're expected to do without any userland help at all, > > but you'd still be able to program the M* keys to be normal keys if you > > want. > > > > Of course, this assumes you don't do chording on multiple M* keys to end up > > with a huge number of keymaps :p > > Actually I think that the device should just emit KEY_PROG1..KEY_PROG4 > for the M keys and have userspace daemon load alternate keymaps on the > fly in resaponse to KEY_PROGx. The device is just a set of completely > generic buttons... User will have to tell the kernel what to map them > to. It would work, but it is a big trip through userspace. If quickly pressing M#+G# is a common use pattern (and it will be, for gaming), i.e. you often want to access quickly a function on one level then another on a different level, asking userspace to upload a new keymap to switch levels at every M# press is going to be way too racy. If it is to be used like that, I'd advocate either doing the entire map-switching thing in kernel space, or doing the entire mapping in userspace. In the later case, you don't issue KEY_* in the kernel driver, you just issue MSC_SCAN events, and the userspace driver should open the input device in exclusive mode, do its magic, and use uinput to generate translated events (KEY_*, and even BTN_*, etc). I understand the current version allows for an all-userspace enhanced driver if one sets the entire keymap to KEY_RESERVED, since it will issue MSC_SCAN events for all keys (if it doesn't, I suggest doing so). That might indeed be the best option if one doesn't want a more complex kernel driver. And one could still use the device in degraded mode by not loading the userspace driver, and uploading a regular keymap to it. -- "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
