All of lore.kernel.org
 help / color / mirror / Atom feed
From: Islam Amer <pharon@gmail.com>
To: Rezwanul_Kabir@dell.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 13:57:57 +0300	[thread overview]
Message-ID: <AANLkTin0qht1XR2rUgIXMEeJNU_gb3IZWqSBJb7NXD8K@mail.gmail.com> (raw)
In-Reply-To: <AANLkTimIl6UL0HQT1wxRgXuj_m0O3CwMHQIa1xNE1Ax9@mail.gmail.com>

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

WARNING: multiple messages have this Message-ID (diff)
From: Islam Amer <pharon@gmail.com>
To: Rezwanul_Kabir@dell.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 13:57:57 +0300	[thread overview]
Message-ID: <AANLkTin0qht1XR2rUgIXMEeJNU_gb3IZWqSBJb7NXD8K@mail.gmail.com> (raw)
In-Reply-To: <AANLkTimIl6UL0HQT1wxRgXuj_m0O3CwMHQIa1xNE1Ax9@mail.gmail.com>

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
>>>
>
--
To unsubscribe from this list: send the line "unsubscribe platform-driver-x86" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

  reply	other threads:[~2010-06-08 10:58 UTC|newest]

Thread overview: 34+ 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:14 ` Islam Amer
2010-06-02 21:34 ` Matthew Garrett
2010-06-03  1:57   ` Rezwanul_Kabir
2010-06-03  1:57     ` Rezwanul_Kabir
2010-06-03 20:16     ` Islam Amer
2010-06-03 20:16       ` Islam Amer
2010-06-08 10:57       ` Islam Amer [this message]
2010-06-08 10:57         ` Islam Amer
2010-06-08 16:33         ` Rezwanul_Kabir
2010-06-08 16:33           ` Rezwanul_Kabir
2010-06-10 18:36         ` Rezwanul_Kabir
2010-06-10 18:36           ` Rezwanul_Kabir
2010-06-10 18:40           ` Matthew Garrett
2010-06-10 23:51             ` Islam Amer
2010-06-10 23:51               ` Islam Amer
2010-06-11  0:15               ` Rezwanul_Kabir
2010-06-11  0:15                 ` Rezwanul_Kabir
2010-06-11 13:28                 ` Islam Amer
2010-06-11 13:28                   ` Islam Amer
2010-06-11 14:08                   ` Tim Gardner
2010-06-11 14:23                     ` Islam Amer
2010-06-11 14:23                       ` Islam Amer
2010-06-11 18:02                       ` 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-12  1:26                             ` Islam Amer
2010-06-15 17:23                             ` Rezwanul_Kabir
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=AANLkTin0qht1XR2rUgIXMEeJNU_gb3IZWqSBJb7NXD8K@mail.gmail.com \
    --to=pharon@gmail.com \
    --cc=Rezwanul_Kabir@dell.com \
    --cc=akpm@linux-foundation.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mjg59@srcf.ucam.org \
    --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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.