From: <Rezwanul_Kabir@Dell.com>
To: <pharon@gmail.com>
Cc: <mjg59@srcf.ucam.org>, <linux-kernel@vger.kernel.org>,
<platform-driver-x86@vger.kernel.org>,
<akpm@linux-foundation.org>
Subject: RE: Dell Studio 1555 eject key does not work ( small patch to fix included )
Date: Tue, 8 Jun 2010 11:33:39 -0500 [thread overview]
Message-ID: <57DF5FDC2DC0634FA2A310BC5B81A68D01DF54BF73@AUSX7MCPC108.AMER.DELL.COM> (raw)
In-Reply-To: <AANLkTin0qht1XR2rUgIXMEeJNU_gb3IZWqSBJb7NXD8K@mail.gmail.com>
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@gmail.com]
>Sent: Tuesday, June 08, 2010 5:58 AM
>To: Kabir, Rezwanul
>Cc: mjg59@srcf.ucam.org; linux-kernel@vger.kernel.org;
>platform-driver-x86@vger.kernel.org; akpm@linux-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@gmail.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@dell.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@srcf.ucam.org
>>>>
>>
>
next prev parent reply other threads:[~2010-06-08 16:37 UTC|newest]
Thread overview: 21+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-06-02 21:14 Dell Studio 1555 eject key does not work ( small patch to fix included ) Islam Amer
2010-06-02 21:34 ` Matthew Garrett
2010-06-03 1:57 ` Rezwanul_Kabir
2010-06-03 20:16 ` Islam Amer
2010-06-08 10:57 ` Islam Amer
2010-06-08 16:33 ` Rezwanul_Kabir [this message]
2010-06-10 18:36 ` Rezwanul_Kabir
2010-06-10 18:40 ` Matthew Garrett
2010-06-10 23:51 ` Islam Amer
2010-06-11 0:15 ` Rezwanul_Kabir
2010-06-11 13:28 ` Islam Amer
2010-06-11 14:08 ` Tim Gardner
2010-06-11 14:23 ` Islam Amer
2010-06-11 18:02 ` Islam Amer
2010-06-11 18:35 ` Tim Gardner
2010-06-12 1:26 ` Islam Amer
2010-06-15 17:23 ` Rezwanul_Kabir
2010-06-15 17:28 ` Matthew Garrett
2010-06-24 15:09 ` Matthew Garrett
2010-09-06 19:12 ` Kyle McMartin
2010-09-23 18:43 ` [stable] " Greg KH
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=57DF5FDC2DC0634FA2A310BC5B81A68D01DF54BF73@AUSX7MCPC108.AMER.DELL.COM \
--to=rezwanul_kabir@dell.com \
--cc=akpm@linux-foundation.org \
--cc=linux-kernel@vger.kernel.org \
--cc=mjg59@srcf.ucam.org \
--cc=pharon@gmail.com \
--cc=platform-driver-x86@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).