Re: Using EV_MSC or extending KEY_*

[Rick L. Vinyard, Jr.]

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

Emitting a keycode certainly does simplify things, but that will preclude
the user from programming the G-keys to KEY_PROG1..KEY_PROG4.

Are there any specific use cases where a user would want to program a
G-key to KEY_PROG1..KEY_PROG4?

---

Rick


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/