linux-kernel - Re: Using EV_MSC or extending KEY

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <4d6ae6e7ee9b38f99e38d357dc755d64.squirrel@intranet.cs.nmsu.edu>
Date:	Fri, 18 Sep 2009 09:40:23 -0600
From:	"Rick L. Vinyard, Jr." <rvinyard@...nmsu.edu>
To:	"Dmitry Torokhov" <dmitry.torokhov@...il.com>
Cc:	"Henrique de Moraes Holschuh" <hmh@....eng.br>,
	"Trilok Soni" <soni.trilok@...il.com>,
	"Linux USB" <linux-usb@...r.kernel.org>,
	"LKML" <linux-kernel@...r.kernel.org>, linux-input@...r.kernel.org
Subject: Re: Using EV_MSC or extending KEY_*

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@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/