Added key codes generated by screen rotation on the Latitude XT. 0xe046 is sent when changing to tablet mode, and 0xe047 when it returns to desktop mode.
Signed-off-by: Rafi Rubin <[email protected]>
---
drivers/platform/x86/dell-wmi.c | 2 ++
1 files changed, 2 insertions(+), 0 deletions(-)
diff --git a/drivers/platform/x86/dell-wmi.c b/drivers/platform/x86/dell-wmi.c
index 2fab941..b76ef49 100644
--- a/drivers/platform/x86/dell-wmi.c
+++ b/drivers/platform/x86/dell-wmi.c
@@ -50,6 +50,8 @@ enum { KE_KEY, KE_SW, KE_END };
static struct key_entry dell_wmi_keymap[] = {
{KE_KEY, 0xe045, KEY_PROG1},
+ {KE_KEY, 0xe046, KEY_PROG2},
+ {KE_KEY, 0xe047, KEY_PROG3},
{KE_END, 0}
};
--
1.6.2.1
Rafi Rubin schreef:
> Added key codes generated by screen rotation on the Latitude XT. 0xe046 is sent when changing to tablet mode, and 0xe047 when it returns to desktop mode.
>
> Signed-off-by: Rafi Rubin <[email protected]>
> ---
> drivers/platform/x86/dell-wmi.c | 2 ++
> 1 files changed, 2 insertions(+), 0 deletions(-)
>
> diff --git a/drivers/platform/x86/dell-wmi.c b/drivers/platform/x86/dell-wmi.c
> index 2fab941..b76ef49 100644
> --- a/drivers/platform/x86/dell-wmi.c
> +++ b/drivers/platform/x86/dell-wmi.c
> @@ -50,6 +50,8 @@ enum { KE_KEY, KE_SW, KE_END };
>
> static struct key_entry dell_wmi_keymap[] = {
> {KE_KEY, 0xe045, KEY_PROG1},
> + {KE_KEY, 0xe046, KEY_PROG2},
> + {KE_KEY, 0xe047, KEY_PROG3},
> {KE_END, 0}
Hello,
PROG2 and PROG3? That's so mundane! Fair enough, I've checked in
linux/input.h and couldn't find exactly fitting code keys
(SWITCHVIDEOMODE, VIDEO_NEXT, VIDEO_PREV are not exactly about
rotation). At least, it would be worth adding a comment after each line
about which key does what, so that it's not necessary to read the
changelog to know!
Eric
Commenting rotation events, in lieu of appropriate self commenting key names in input.h.
Signed-off-by: Rafi Rubin <[email protected]>
---
drivers/platform/x86/dell-wmi.c | 4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/platform/x86/dell-wmi.c b/drivers/platform/x86/dell-wmi.c
index b76ef49..2d4f718 100644
--- a/drivers/platform/x86/dell-wmi.c
+++ b/drivers/platform/x86/dell-wmi.c
@@ -50,8 +50,8 @@ enum { KE_KEY, KE_SW, KE_END };
static struct key_entry dell_wmi_keymap[] = {
{KE_KEY, 0xe045, KEY_PROG1},
- {KE_KEY, 0xe046, KEY_PROG2},
- {KE_KEY, 0xe047, KEY_PROG3},
+ {KE_KEY, 0xe046, KEY_PROG2}, /* Going to tablet mode */
+ {KE_KEY, 0xe047, KEY_PROG3}, /* Coming from tablet mode */
{KE_END, 0}
};
--
1.6.2.1
`
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.
--
Matthew Garrett | [email protected]
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
?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