linux-kernel - RE: Dell Studio 1555 eject key does not work ( small patch to fix included )

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <57DF5FDC2DC0634FA2A310BC5B81A68D01DFD57663@AUSX7MCPC108.AMER.DELL.COM>
Date:	Thu, 10 Jun 2010 13:36:56 -0500
From:	<Rezwanul_Kabir@...l.com>
To:	<pharon@...il.com>
CC:	<mjg59@...f.ucam.org>, <linux-kernel@...r.kernel.org>,
	<platform-driver-x86@...r.kernel.org>, <akpm@...ux-foundation.org>
Subject: RE: Dell Studio 1555 eject key does not work ( small patch to fix
 	included )

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..
   --rez



Rezwanul Kabir
Dell Linux Development
512-725-0766
 

>-----Original Message-----
>From: Kabir, Rezwanul 
>Sent: Tuesday, June 08, 2010 11:34 AM
>To: 'Islam Amer'
>Cc: mjg59@...f.ucam.org; linux-kernel@...r.kernel.org; 
>platform-driver-x86@...r.kernel.org; akpm@...ux-foundation.org
>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..
>       --rez
>
>
>
>Rezwanul Kabir
>Dell Linux Development
>512-725-0766
> 
>
>>-----Original Message-----
>>From: Islam Amer [mailto:pharon@...il.com]
>>Sent: Tuesday, June 08, 2010 5:58 AM
>>To: Kabir, Rezwanul
>>Cc: mjg59@...f.ucam.org; linux-kernel@...r.kernel.org; 
>>platform-driver-x86@...r.kernel.org; akpm@...ux-foundation.org
>>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 <pharon@...il.com> 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,  <Rezwanul_Kabir@...l.com> 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 | mjg59@...f.ucam.org
>>>>>
>>>
>>
>--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/