>
>>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 |
mjg59@srcf.ucam.org
>>