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

[ message continues ]

Hi Rez,

Any thoughts on this?

-- 
Matthew Garrett | mjg59@srcf.ucam.org
--

[ message continues ]

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

[ message continues ]

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

[ message continues ]

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.

--

[ message continues ]

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

[ message continues ]

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

[ message continues ]

That's the default on any kernel that has this support in dell-wmi. Rez, 
could you let me know if the proposed patch breaks the spec in ways that 
are likely to cause problems?

-- 
Matthew Garrett | mjg59@srcf.ucam.org
--

[ message continues ]

Hello all,

My bios version is A08 , I see that A11 was recently released but the
changelog doesn't say much.

Which is better, upgrade and hope the problem goes away, or wait until
we have a fix that is agreed upon ?

Thanks.

--

[ message continues ]

Islam Amer

   Please try the new BIOS A11 and eliminate any potential BIOS issues. The BIOS team confirmed that
   they weren't able to reproduce the issue with Ubuntu 10.04 and A11.

Thanks..
   --rez




Rezwanul Kabir
Dell Linux Development

[ message continues ]

Rezwanul,

I've updated my bios to A11 and installed a new unmodified kernel. The
issue still persists that the eject key produces "dell-wmi: Unknown
key 0 pressed" in the dmesg output and it doesn't work.

It is possible that Ubuntu is including patches to fix stuff. The
latest patch for the Lucid kernel at
http://archive.ubuntu.com/ubuntu/pool/main/l/linux/linux_2.6.32-22.36.diff.gz
does include patches that touch wmi and dell-wmi code, but I can't
find a specific change that would fix this issue.

I might try to selectively apply patches from it and see if it gets fixed.

Thanks.


--

[ message continues ]

Islam Amer,

You could try a vanilla stable kernel from 
http://kernel.ubuntu.com/~kernel-ppa/mainline/v2.6.32.15.5-lucid/ to see 
if we've borked the dell-wmi code.

rtg



-- 
Tim Gardner tim.gardner@canonical.com
--

[ message continues ]

Tim I am running debian,

I think it's the other way round, the mainline kernel is borked (
regarding dell-wmi and eject key ) while the lucid patched kernel
works ( as reported by dell team ).

I guess I could download a Lucid livecd and see if the eject key works
there ( event only as it won't eject the lived while it is running :)
)

--

[ message continues ]

Dear Tim,

I tried the mainline kernel 2.6.32-0206321505-generic as you suggested
and the eject key doesn't work but it also doesn't produce the error
message in dmesg.

I then tried the 2.6.32-22.36-generic from
http://packages.ubuntu.com/lucid/linux-image-2.6.32-22-generic and I
found the eject key working fine.

So there is something in the ubuntu patchset that fixes this issue.

--

[ message continues ]

The only difference between 2.6.32.15 and Ubuntu Lucid wrt dell-wmi.c is 
this:

43,46d42
< /* Temporary workaround until the WMI sysfs interface goes in.
<    Borrowed from acer-wmi */
< MODULE_ALIAS("dmi:*:*Dell*:*:");
<

I wonder about input event filtering? There are substantial differences 
in drivers/input/input.c.

rtg



-- 
Tim Gardner tim.gardner@canonical.com
--

[ message continues ]

What would you like me to do now? I want to help :)

Thanks.

--

[ message continues ]

Hi Matthew/Islam

   I don't know how Ubuntu 10.04 fixed the issue, but from my communications with the BIOS team, I think 
 Islam's patch would be acceptable. "buffer_entry[1] == 0x0" would indicate HotKey events on these platforms.

Thanks..
   --rez

 

Rezwanul Kabir
Dell Linux Development

[ message continues ]

Ok, thanks, I'll queue that up.

-- 
Matthew Garrett | mjg59@srcf.ucam.org
--

[ message continues ]

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

[ message continues ]

Thanks for sending this fix in, Islam. Adding stable@ to the Cc.

Greg, could you apply this to the stable tree as well? Should apply a
few releases back. We applied it to .34 and .35 in Fedora, at least.

The upstream commit id was d5164dbf1f651d1e955b158fb70a9c844cc91cd1.

regards, Kyle


--

[ message continues ]

Now queued up in the .35-stable tree.

thanks,

greg k-h
--

[ message continues ]