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 \n", 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?id=16075 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;
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 \n", 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?id=16075 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 | [email protected]
>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 \n", 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?id=16075 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 | [email protected]
>-
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, <[email protected]> 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 \n", 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?id=16075 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 | [email protected]
>>
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 <[email protected]> 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, ?<[email protected]> 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 \n", 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?id=16075 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 | [email protected]
>>>
>
Hi Islam Amer
I have asked feedback from the BIOS team and will update this thread as soon as I get it.
Thanks..
--rez
Rezwanul Kabir
Dell Linux Development
512-725-0766
>-----Original Message-----
>From: Islam Amer [mailto:[email protected]]
>Sent: Tuesday, June 08, 2010 5:58 AM
>To: Kabir, Rezwanul
>Cc: [email protected]; [email protected];
>[email protected]; [email protected]
>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 <[email protected]> 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, ?<[email protected]> 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 \n", 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?id=16075 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 | [email protected]
>>>>
>>
>-
Hi Islam,
Before I apply this, can I ask you to send it along with a
"Signed-off-by:" line as described in Documentation/SubmittingPatches ?
Once that's done I'll put it in my tree.
Thanks,
--
Matthew Garrett | [email protected]