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. -- Dmitry -- 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
