Dell Studio 1555 eject key does not work ( small patch to fix included )

June 02nd, 2010 - 05:20 pm ET by Islam Amer | Report spam
Hello,

Pressing the eject key on my Dell Studio 1555 does not work and dmesg produces
this message :
dell-wmi: Unknown key 0 pressed

Adding a debugging printk in dell-wmi.c after line 222 like this :

printk(KERN_INFO "dell:wmi 0x%x , 0x%x ", buffer_entry[1], buffer_entry[2]);

dmesg now shows :

dell:wmi 0x0 , 0xe009
dell-wmi: Unknown key 0 pressed

So for some reason buffer_entry[1] is used although it is empty.

Falling back to buffer_entry[2] in case buffer_entry[1] is 0x0 makes
the button work.

I suspect it might be better to fix the "dell_new_hk_type" logic though

I had submitted this as
https://bugzilla.kernel.org/show_bug.cgi?id075 but repeating the
information and patch
here as per Andrew Morton's suggestion.


Thanks.

linux-sidux-2.6-2.6.34/drivers/platform/x86/dell-wmi.c.orig 2010-06-03
01:02:17.418824168 +0400
+++ linux-sidux-2.6-2.6.34/drivers/platform/x86/dell-wmi.c 2010-06-03
01:01:40.641833249 +0400
@@ -221,7 +221,7 @@ static void dell_wmi_notify(u32 value, v
return;
}

- if (dell_new_hk_type)
+ if (dell_new_hk_type || buffer_entry[1] == 0x0)
reported_key = (int)buffer_entry[2];
else
reported_key = (int)buffer_entry[1] & 0xffff;
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
email Follow the discussionReplies 16 repliesReplies Make a reply

Similar topics

Replies

#1 Matthew Garrett
June 02nd, 2010 - 05:40 pm ET | Report spam
Hi Rez,

Any thoughts on this?

On Thu, Jun 03, 2010 at 01:14:09AM +0400, Islam Amer wrote
Hello,

Pressing the eject key on my Dell Studio 1555 does not work and dmesg produces
this message :
dell-wmi: Unknown key 0 pressed

Adding a debugging printk in dell-wmi.c after line 222 like this :

printk(KERN_INFO "dell:wmi 0x%x , 0x%x ", buffer_entry[1], buffer_entry[2]);

dmesg now shows :

dell:wmi 0x0 , 0xe009
dell-wmi: Unknown key 0 pressed

So for some reason buffer_entry[1] is used although it is empty.

Falling back to buffer_entry[2] in case buffer_entry[1] is 0x0 makes
the button work.

I suspect it might be better to fix the "dell_new_hk_type" logic though

I had submitted this as
https://bugzilla.kernel.org/show_bug.cgi?id075 but repeating the
information and patch
here as per Andrew Morton's suggestion.


Thanks.

linux-sidux-2.6-2.6.34/drivers/platform/x86/dell-wmi.c.orig 2010-06-03
01:02:17.418824168 +0400
+++ linux-sidux-2.6-2.6.34/drivers/platform/x86/dell-wmi.c 2010-06-03
01:01:40.641833249 +0400
@@ -221,7 +221,7 @@ static void dell_wmi_notify(u32 value, v
return;
}

- if (dell_new_hk_type)
+ if (dell_new_hk_type || buffer_entry[1] == 0x0)
reported_key = (int)buffer_entry[2];
else
reported_key = (int)buffer_entry[1] & 0xffff;



Matthew Garrett |
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Replies Reply to this message
#2 Anonym
June 02nd, 2010 - 10:10 pm ET | Report spam
Hi Rez,

Any thoughts on this?





From the discussion below, it seems that this system does not implement the new
WMI scheme ( which is when dell_new_hk_type=true is set). So, at issue here is the
legacy code. Without knowing exactly why BIOS would behave differently in this particular case,
the fix seems arbitrary. Let me see if I can get hold of the BIOS developer(if possible) and provide feedback in this thread.

Islam Amer

Can you attach dmidecode output from the system here?

Thanks..





On Thu, Jun 03, 2010 at 01:14:09AM +0400, Islam Amer wrote
Hello,

Pressing the eject key on my Dell Studio 1555 does not work


and dmesg
produces this message :
dell-wmi: Unknown key 0 pressed

Adding a debugging printk in dell-wmi.c after line 222 like this :

printk(KERN_INFO "dell:wmi 0x%x , 0x%x ", buffer_entry[1],
buffer_entry[2]);

dmesg now shows :

dell:wmi 0x0 , 0xe009
dell-wmi: Unknown key 0 pressed

So for some reason buffer_entry[1] is used although it is empty.

Falling back to buffer_entry[2] in case buffer_entry[1] is 0x0 makes
the button work.

I suspect it might be better to fix the "dell_new_hk_type" logic
though

I had submitted this as
https://bugzilla.kernel.org/show_bug.cgi?id075 but repeating the
information and patch here as per Andrew Morton's suggestion.


Thanks.




linux-sidux-2.6-2.6.34/drivers/platform/x86/dell-wmi.c.orig
2010-06-03
01:02:17.418824168 +0400
+++ linux-sidux-2.6-2.6.34/drivers/platform/x86/dell-wmi.c


2010-06-03
01:01:40.641833249 +0400
@@ -221,7 +221,7 @@ static void dell_wmi_notify(u32 value, v
return;
}

- if (dell_new_hk_type)
+ if (dell_new_hk_type || buffer_entry[1] == 0x0)
reported_key = (int)buffer_entry[2];
else
reported_key = (int)buffer_entry[1] & 0xffff;



Matthew Garrett |


To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Replies Reply to this message
#3 Islam Amer
June 08th, 2010 - 07:00 am ET | Report spam
Dear Rezwanul,

I have been using this fix for quite some time without any visible ill
effects on the other keys or the system in general.
Of course it would be necessary to get feedback from other dell users.

Thanks.

On Thu, Jun 3, 2010 at 11:16 PM, Islam Amer wrote:
Hello,

I suspected the same about dell_new_hk_type, but I am confused that
the rest of the fn keys work just fine out of the box. The only button
that didn't work was the eject key.

Attached is the dmidecode output.

Thanks

On Thu, Jun 3, 2010 at 5:57 AM,   wrote:

Hi Rez,

Any thoughts on this?





 From the discussion below, it seems that this system does not implement the new
WMI scheme ( which is when dell_new_hk_type=true is set). So, at issue here is the
legacy code. Without knowing exactly why BIOS would behave differently in this particular case,
the fix seems arbitrary. Let me see if I can get hold of the BIOS developer(if possible) and provide feedback in this thread.

Islam Amer

  Can you attach dmidecode output from the system here?

Thanks..
  --rez





On Thu, Jun 03, 2010 at 01:14:09AM +0400, Islam Amer wrote
Hello,

Pressing the eject key on my Dell Studio 1555 does not work


and dmesg
produces this message :
dell-wmi: Unknown key 0 pressed

Adding a debugging printk in dell-wmi.c after line 222 like this :

printk(KERN_INFO "dell:wmi 0x%x , 0x%x ", buffer_entry[1],
buffer_entry[2]);

dmesg now shows :

dell:wmi 0x0 , 0xe009
dell-wmi: Unknown key 0 pressed

So for some reason buffer_entry[1] is used although it is empty.

Falling back to buffer_entry[2] in case buffer_entry[1] is 0x0 makes
the button work.

I suspect it might be better to fix the "dell_new_hk_type" logic
though

I had submitted this as
https://bugzilla.kernel.org/show_bug.cgi?id075 but repeating the
information and patch here as per Andrew Morton's suggestion.


Thanks.




linux-sidux-2.6-2.6.34/drivers/platform/x86/dell-wmi.c.orig
2010-06-03
01:02:17.418824168 +0400
+++ linux-sidux-2.6-2.6.34/drivers/platform/x86/dell-wmi.c


2010-06-03
01:01:40.641833249 +0400
@@ -221,7 +221,7 @@ static void dell_wmi_notify(u32 value, v
                     return;
             }

-            if (dell_new_hk_type)
+            if (dell_new_hk_type || buffer_entry[1] == 0x0)
                     reported_key = (int)buffer_entry[2];
             else
                     reported_key = (int)buffer_entry[1] & 0xffff;



Matthew Garrett |








To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Replies Reply to this message
#4 Anonym
June 08th, 2010 - 12:40 pm ET | Report spam
Hi Islam Amer

I have asked feedback from the BIOS team and will update this thread as soon as I get it.
Thanks..



Rezwanul Kabir
Dell Linux Development
512-725-0766


From: Islam Amer [mailto:]
Sent: Tuesday, June 08, 2010 5:58 AM
To: Kabir, Rezwanul
Cc: ; ;
;
Subject: Re: Dell Studio 1555 eject key does not work ( small
patch to fix included )

Dear Rezwanul,

I have been using this fix for quite some time without any
visible ill effects on the other keys or the system in general.
Of course it would be necessary to get feedback from other dell users.

Thanks.

On Thu, Jun 3, 2010 at 11:16 PM, Islam Amer wrote:
Hello,

I suspected the same about dell_new_hk_type, but I am confused that
the rest of the fn keys work just fine out of the box. The


only button
that didn't work was the eject key.

Attached is the dmidecode output.

Thanks

On Thu, Jun 3, 2010 at 5:57 AM,   wrote:

Hi Rez,

Any thoughts on this?





 From the discussion below, it seems that this system does not
implement the new WMI scheme ( which is when




dell_new_hk_type=true is
set). So, at issue here is the legacy code. Without knowing exactly
why BIOS would behave differently in this particular case,




the fix seems arbitrary. Let me see if I can get hold of the
BIOS developer(if possible) and provide feedback in this thread.

Islam Amer

  Can you attach dmidecode output from the system here?

Thanks..
  --rez





On Thu, Jun 03, 2010 at 01:14:09AM +0400, Islam Amer wrote
Hello,

Pressing the eject key on my Dell Studio 1555 does not work


and dmesg
produces this message :
dell-wmi: Unknown key 0 pressed

Adding a debugging printk in dell-wmi.c after line 222 like this :

printk(KERN_INFO "dell:wmi 0x%x , 0x%x ", buffer_entry[1],
buffer_entry[2]);

dmesg now shows :

dell:wmi 0x0 , 0xe009
dell-wmi: Unknown key 0 pressed

So for some reason buffer_entry[1] is used although it is empty.

Falling back to buffer_entry[2] in case buffer_entry[1] is 0x0
makes the button work.

I suspect it might be better to fix the "dell_new_hk_type" logic
though

I had submitted this as
https://bugzilla.kernel.org/show_bug.cgi?id075 but








repeating the
information and patch here as per Andrew Morton's suggestion.


Thanks.




linux-sidux-2.6-2.6.34/drivers/platform/x86/dell-wmi.c.orig
2010-06-03
01:02:17.418824168 +0400
+++ linux-sidux-2.6-2.6.34/drivers/platform/x86/dell-wmi.c


2010-06-03
01:01:40.641833249 +0400
@@ -221,7 +221,7 @@ static void dell_wmi_notify(u32 value, v
                     return;
             }

-            if (dell_new_hk_type)
+            if (dell_new_hk_type || buffer_entry[1] == 0x0)
                     reported_key = (int)buffer_entry[2];
             else
                     reported_key = (int)buffer_entry[1] & 0xffff;



Matthew Garrett |










To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Replies Reply to this message
#5 Anonym
June 10th, 2010 - 02:40 pm ET | Report spam
Hi Islam Amer

I got report that "Ubuntu 10.04 + BIOS A11" was tested and the "Eject CD" key is working
as expected. Sorry, I couldn't find any Studio 1555 to test myself and cannot provide you
with more details.

Also, you may try acpi_osi="Windows 2009" kernel parameter and see if there is any difference.

Thanks..



Rezwanul Kabir
Dell Linux Development
512-725-0766


From: Kabir, Rezwanul
Sent: Tuesday, June 08, 2010 11:34 AM
To: 'Islam Amer'
Cc: ; ;
;
Subject: RE: Dell Studio 1555 eject key does not work ( small
patch to fix included )

Hi Islam Amer

I have asked feedback from the BIOS team and will update
this thread as soon as I get it.
Thanks..



Rezwanul Kabir
Dell Linux Development
512-725-0766


From: Islam Amer [mailto:]
Sent: Tuesday, June 08, 2010 5:58 AM
To: Kabir, Rezwanul
Cc: ; ;
;
Subject: Re: Dell Studio 1555 eject key does not work ( small


patch to
fix included )

Dear Rezwanul,

I have been using this fix for quite some time without any


visible ill
effects on the other keys or the system in general.
Of course it would be necessary to get feedback from other dell users.

Thanks.

On Thu, Jun 3, 2010 at 11:16 PM, Islam Amer wrote:
Hello,

I suspected the same about dell_new_hk_type, but I am confused that
the rest of the fn keys work just fine out of the box. The


only button
that didn't work was the eject key.

Attached is the dmidecode output.

Thanks

On Thu, Jun 3, 2010 at 5:57 AM,   wrote:

Hi Rez,

Any thoughts on this?





 From the discussion below, it seems that this system does not
implement the new WMI scheme ( which is when




dell_new_hk_type=true is
set). So, at issue here is the legacy code. Without






knowing exactly
why BIOS would behave differently in this particular case,




the fix seems arbitrary. Let me see if I can get hold of the BIOS
developer(if possible) and provide feedback in this thread.

Islam Amer

  Can you attach dmidecode output from the system here?

Thanks..
  --rez





On Thu, Jun 03, 2010 at 01:14:09AM +0400, Islam Amer wrote
Hello,

Pressing the eject key on my Dell Studio 1555 does not work


and dmesg
produces this message :
dell-wmi: Unknown key 0 pressed

Adding a debugging printk in dell-wmi.c after line 222










like this :

printk(KERN_INFO "dell:wmi 0x%x , 0x%x ", buffer_entry[1],
buffer_entry[2]);

dmesg now shows :

dell:wmi 0x0 , 0xe009
dell-wmi: Unknown key 0 pressed

So for some reason buffer_entry[1] is used although it is empty.

Falling back to buffer_entry[2] in case buffer_entry[1] is 0x0
makes the button work.

I suspect it might be better to fix the "dell_new_hk_type" logic
though

I had submitted this as
https://bugzilla.kernel.org/show_bug.cgi?id075 but








repeating the
information and patch here as per Andrew Morton's suggestion.


Thanks.




linux-sidux-2.6-2.6.34/drivers/platform/x86/dell-wmi.c.orig
2010-06-03
01:02:17.418824168 +0400
+++ linux-sidux-2.6-2.6.34/drivers/platform/x86/dell-wmi.c


2010-06-03
01:01:40.641833249 +0400
@@ -221,7 +221,7 @@ static void dell_wmi_notify(u32 value, v
                     return;
             }

-            if (dell_new_hk_type)
+            if (dell_new_hk_type || buffer_entry[1] == 0x0)
                     reported_key = (int)buffer_entry[2];
             else
                     reported_key = (int)buffer_entry[1]










& 0xffff;



Matthew Garrett |













To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Replies Reply to this message
Help Create a new topicNext page Replies Make a reply
Search Make your own search