All of lore.kernel.org
 help / color / mirror / Atom feed
* [PATCH] dell-wmi Switch support and Tablet switch definition
@ 2009-06-19 11:15 Rafi Rubin
  2009-06-19 14:02 ` Matthew Garrett
  0 siblings, 1 reply; 6+ messages in thread
From: Rafi Rubin @ 2009-06-19 11:15 UTC (permalink / raw)
  To: linux-acpi; +Cc: Rafi Rubin

Added a bit of missing code needed to handle switch events.

Added the definitions for the hinge rotation as seen on the
Latitude XT tablet.

Signed-off-by: Rafi Rubin <rafi@seas.upenn.edu>
---
 drivers/platform/x86/dell-wmi.c |   21 +++++++++++++++++----
 1 files changed, 17 insertions(+), 4 deletions(-)

diff --git a/drivers/platform/x86/dell-wmi.c b/drivers/platform/x86/dell-wmi.c
index 0f900cc..c0da4d2 100644
--- a/drivers/platform/x86/dell-wmi.c
+++ b/drivers/platform/x86/dell-wmi.c
@@ -44,6 +44,7 @@ struct key_entry {
 	char type;		/* See KE_* below */
 	u16 code;
 	u16 keycode;
+   u8  state;
 };
 
 enum { KE_KEY, KE_SW, KE_IGNORE, KE_END };
@@ -58,6 +59,10 @@ static struct key_entry dell_wmi_keymap[] = {
 	{KE_KEY, 0xe045, KEY_PROG1},
 	{KE_KEY, 0xe009, KEY_EJECTCD},
 
+	/* Definitions for the hinge switch */
+	{KE_SW , 0xe046, SW_TABLET_MODE,1},
+	{KE_SW , 0xe047, SW_TABLET_MODE,0},
+
 	/* These also contain the brightness level at offset 6 */
 	{KE_KEY, 0xe006, KEY_BRIGHTNESSUP},
 	{KE_KEY, 0xe005, KEY_BRIGHTNESSDOWN},
@@ -172,10 +177,18 @@ static void dell_wmi_notify(u32 value, void *context)
 		 */
 		key = dell_wmi_get_entry_by_scancode(buffer[1] & 0xFFFF);
 		if (key) {
-			input_report_key(dell_wmi_input_dev, key->keycode, 1);
-			input_sync(dell_wmi_input_dev);
-			input_report_key(dell_wmi_input_dev, key->keycode, 0);
-			input_sync(dell_wmi_input_dev);
+         switch (key->type) {
+         case KE_KEY:
+				input_report_key(dell_wmi_input_dev, key->keycode, 1);
+				input_sync(dell_wmi_input_dev);
+				input_report_key(dell_wmi_input_dev, key->keycode, 0);
+				input_sync(dell_wmi_input_dev);
+            break;
+         case KE_SW:
+            input_report_switch(dell_wmi_input_dev, key->keycode, key->state);
+            input_sync(dell_wmi_input_dev);
+            break;
+         }
 		} else if (buffer[1] & 0xFFFF)
 			printk(KERN_INFO "dell-wmi: Unknown key %x pressed\n",
 			       buffer[1] & 0xFFFF);
-- 
1.6.0


^ permalink raw reply related	[flat|nested] 6+ messages in thread

* Re: [PATCH] dell-wmi Switch support and Tablet switch definition
  2009-06-19 11:15 [PATCH] dell-wmi Switch support and Tablet switch definition Rafi Rubin
@ 2009-06-19 14:02 ` Matthew Garrett
  2009-06-19 19:28   ` Rafi Rubin
  0 siblings, 1 reply; 6+ messages in thread
From: Matthew Garrett @ 2009-06-19 14:02 UTC (permalink / raw)
  To: Rafi Rubin; +Cc: linux-acpi

On Fri, Jun 19, 2009 at 07:15:12AM -0400, Rafi Rubin wrote:
> Added a bit of missing code needed to handle switch events.
> 
> Added the definitions for the hinge rotation as seen on the
> Latitude XT tablet.

Having thought about this a bit more, I think there's a pretty 
fundamental problem right now - we don't know whether we're in tablet 
mode or not when we boot, so can't set the initial state. Software that 
depends on that may be rather confused as a result...

-- 
Matthew Garrett | mjg59@srcf.ucam.org

^ permalink raw reply	[flat|nested] 6+ messages in thread

* Re: [PATCH] dell-wmi Switch support and Tablet switch definition
  2009-06-19 14:02 ` Matthew Garrett
@ 2009-06-19 19:28   ` Rafi Rubin
  2009-06-19 19:40     ` Matthew Garrett
  0 siblings, 1 reply; 6+ messages in thread
From: Rafi Rubin @ 2009-06-19 19:28 UTC (permalink / raw)
  To: Matthew Garrett; +Cc: linux-acpi

Matthew Garrett wrote:
> On Fri, Jun 19, 2009 at 07:15:12AM -0400, Rafi Rubin wrote:
>> Added a bit of missing code needed to handle switch events.
>>
>> Added the definitions for the hinge rotation as seen on the
>> Latitude XT tablet.
> 
> Having thought about this a bit more, I think there's a pretty 
> fundamental problem right now - we don't know whether we're in tablet 
> mode or not when we boot, so can't set the initial state. Software that 
> depends on that may be rather confused as a result...

I agree polling the tablet state would be a good thing.  But that does not mean we should not
support the signals until we are ready to support polling.

If you are suggesting that we should not use an EV_SW because we will eventually poll the hardware
instead of keeping the state in software, then I have no problem with sending keys or other events.

However if you still think keeping the state in software and using EV_SW is a good idea, this code
is independent of the probe code.  And I think the value of having this support is well worth the
potential harm.  After all, it thinks its in non-tablet mode until the signal comes in that its
switching to tablet.  How is this any worse than always thinking its in non-tablet mode?

Rafi

^ permalink raw reply	[flat|nested] 6+ messages in thread

* Re: [PATCH] dell-wmi Switch support and Tablet switch definition
  2009-06-19 19:28   ` Rafi Rubin
@ 2009-06-19 19:40     ` Matthew Garrett
  2009-06-19 20:31       ` Rafi Rubin
  0 siblings, 1 reply; 6+ messages in thread
From: Matthew Garrett @ 2009-06-19 19:40 UTC (permalink / raw)
  To: Rafi Rubin; +Cc: linux-acpi

On Fri, Jun 19, 2009 at 03:28:48PM -0400, Rafi Rubin wrote:

> I agree polling the tablet state would be a good thing.  But that does not mean we should not
> support the signals until we are ready to support polling.
> 
> If you are suggesting that we should not use an EV_SW because we will eventually poll the hardware
> instead of keeping the state in software, then I have no problem with sending keys or other events.

No, my point is that there's little benefit in providing EV_SW if the 
initial value is going to be wrong. Software simply can't depend on it. 
The code's absolutely fine, but there's a risk that it'll break 
otherwise working desktops until we know how to set the initial value.

-- 
Matthew Garrett | mjg59@srcf.ucam.org

^ permalink raw reply	[flat|nested] 6+ messages in thread

* Re: [PATCH] dell-wmi Switch support and Tablet switch definition
  2009-06-19 19:40     ` Matthew Garrett
@ 2009-06-19 20:31       ` Rafi Rubin
  2009-06-19 20:34         ` Matthew Garrett
  0 siblings, 1 reply; 6+ messages in thread
From: Rafi Rubin @ 2009-06-19 20:31 UTC (permalink / raw)
  To: Matthew Garrett; +Cc: linux-acpi

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Matthew Garrett wrote:
> On Fri, Jun 19, 2009 at 03:28:48PM -0400, Rafi Rubin wrote:
> 
>> I agree polling the tablet state would be a good thing.  But that does not mean we should not
>> support the signals until we are ready to support polling.
>>
>> If you are suggesting that we should not use an EV_SW because we will eventually poll the hardware
>> instead of keeping the state in software, then I have no problem with sending keys or other events.
> 
> No, my point is that there's little benefit in providing EV_SW if the 
> initial value is going to be wrong. Software simply can't depend on it. 
> The code's absolutely fine, but there's a risk that it'll break 
> otherwise working desktops until we know how to set the initial value.


The signal is not a toggle.  Its an explicit "going to tablet" and "coming from tablet".  And the
initial value is "non-tablet" mode, which is what must be assumed without this support.

So the only new case where a wrong assumption may be made is if the screen is flipped out of tablet
mode during suspend or hibernate.  But we _don't_ have the potential of a toggle being inverted and
it rotating the screen to something silly every time you flip it.

I think the benefits of the partial support far outweight the potential hazards.


That being said, if you have any clue how to probe the state, I would be very happy to help you.
And I'd agree that signals can wait.


-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iEYEARECAAYFAko79b8ACgkQwuRiAT9o60+VowCg5zvB16xzUz6w7cqP6twu4xKv
9o0AoJuG3v9qkiB8SXVpk/D9nud2A8FM
=h/y8
-----END PGP SIGNATURE-----

^ permalink raw reply	[flat|nested] 6+ messages in thread

* Re: [PATCH] dell-wmi Switch support and Tablet switch definition
  2009-06-19 20:31       ` Rafi Rubin
@ 2009-06-19 20:34         ` Matthew Garrett
  0 siblings, 0 replies; 6+ messages in thread
From: Matthew Garrett @ 2009-06-19 20:34 UTC (permalink / raw)
  To: Rafi Rubin; +Cc: linux-acpi

On Fri, Jun 19, 2009 at 04:31:59PM -0400, Rafi Rubin wrote:

> The signal is not a toggle.  Its an explicit "going to tablet" and "coming from tablet".  And the
> initial value is "non-tablet" mode, which is what must be assumed without this support.

No, it's not - it has state. That's a feature of switches.

-- 
Matthew Garrett | mjg59@srcf.ucam.org

^ permalink raw reply	[flat|nested] 6+ messages in thread

end of thread, other threads:[~2009-06-19 20:34 UTC | newest]

Thread overview: 6+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2009-06-19 11:15 [PATCH] dell-wmi Switch support and Tablet switch definition Rafi Rubin
2009-06-19 14:02 ` Matthew Garrett
2009-06-19 19:28   ` Rafi Rubin
2009-06-19 19:40     ` Matthew Garrett
2009-06-19 20:31       ` Rafi Rubin
2009-06-19 20:34         ` Matthew Garrett

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.