Re: [PATCH] Additional keys for dell-wmi

[Rafi Rubin <rafi@seas.upenn.edu>]

Éric Piel wrote:
> Matthew Garrett schreef:
>> On Wed, Apr 08, 2009 at 05:16:04PM -0400, Rafi Rubin wrote:
>>
>>>  static struct key_entry dell_wmi_keymap[] = {
>>>  	{KE_KEY, 0xe045, KEY_PROG1},
>>> +	{KE_KEY, 0xe046, KEY_PROG2},
>>> +	{KE_KEY, 0xe047, KEY_PROG3},
>> Would this make more sense as a switch? That way userspace can know what 
>> state the screen is in.
>>
> Indeed, that seems more logical. And in addition, there is a switch
> called SW_TABLET_MODE, which would fit perfectly.
> I guess at initialisation you can consider it is in standard mode, and
> actually sort out the real state on the first event received.
> 
> Eric

Yeah, I noticed SW_TABLET_MODE after Matthew suggested using the switch and have been trying to
figure out how to use it?  Forgive my ignorance here, I've never knowingly used an ev switch, any
suggestions about how to monitor and check the state?  I don't see anything come out of the input
event node.

Anyway, even if we use a switch, is there any particular reason not to send a key stroke down to the
event device as well?  In my case I already had window manager based hotkeys setup to handle the
"rotate screen" button (that is actually a button).  And by sending the events as key strokes, its
very easy to catch and handle, and the action just goes to the active console, which I consider
desirable.

I tend to prefer mechanism that don't require extra convolutions and daemons to handle things like
this.  For example I've helped setup a thinkpad where the prevailing solution was to catch the hinge
rotation with acpid which pushes a message through dbus which is captured by a daemon the user runs
as part of their X session.  Needless to say that's a bit more of a pain and a bit more sensitive to
change in the winds.

Rafi