Bug 771786

Summary: hp-wmi: Bezel buttons not working.
Product: [Fedora] Fedora Reporter: Kyle <mr_hankeys8rd>
Component: kernelAssignee: Kernel Maintainer List <kernel-maint>
Status: CLOSED WONTFIX QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: medium Docs Contact:
Priority: unspecified    
Version: 16CC: favux.is, gansalmon, itamar, jfeeney, jforbes, jonathan, kernel-maint, madhu.chinakonda
Target Milestone: ---Keywords: Reopened
Target Release: ---   
Hardware: x86_64   
OS: Linux   
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2013-02-13 20:27:01 EST Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---
Description Flags
DSDT for the HP TX2500
proposed patching method to regain hotkeys in tablet mode.
Proposed patch none

Description Kyle 2012-01-04 18:37:40 EST
Created attachment 550777 [details]
DSDT for the HP TX2500

Description of problem: My tablet PC has 4 bezel buttons, of which only 2 work 50% of the time. There are two issues preventing full functionality. 

First, the two partially working buttons, which I will call DVD & Q, come through the keyboard event and are fully recognized. When they do not work is when I put the tablet into tablet mode, which is coincidentally the only time I need them. I have concluded that this is because the keyboard is disabled in tablet mode and have found a manual workaround for this by doing the following:

echo serio0 > /sys/bus/serio/drivers/atkbd/unbind

I would like to come up with a more integrated and automatic solution, which I believe is possible through hp-wmi. More on that later.

Second, the other two buttons, which I will call Gear & FF (flip-flop), I can not find on any event. I have hexdumped them all and get nothing. The DSDT indicates that they are PNP0C32 (Windows Hotstart) buttons. However, I have recompiled the kernel to include the Linux Quickstart driver that is in the staging tree, and it does not detect them. The quickstart driver does, however, recognize the DVD & Q buttons, but only when they are pressed from a sleep state. Looking at the Microsoft documentation, my DSDT, and the quickstart driver forum, it appears that the quickstart driver should not be capable of reading these buttons during runtime. So, the question becomes, how does windows do it. I believe the answer may be in the DSDT, Method _Q16, which references the wmi interface.
Comment 1 Kyle 2012-01-04 19:06:24 EST
Created attachment 550778 [details]
proposed patching method to regain hotkeys in tablet mode.

Looking at the first issue, what I would like to try to do is reset the serial port that the keyboard is on when tablet mode is entered. This is tricky because I am trying to call a reset command from a driver (hp-wmi) that is not associated with the keyboard. Unfortunately, I do not have a lot of experience with C code, so I am having trouble coming up with a way of getting the keyboard port, or device, so I can call a reset command.
Comment 2 Kyle 2012-01-18 23:54:55 EST
I've been trying to sort through all of the related code to see if there is anything I can use and so far all I've come up with are some vague guesses. For instance, I think serio_reconnect(struct serio); is what I want to run, but I need a struct serio. atkbd runs serio_get_drvdata(struct serio); but for that it looks like I need a const struct device within the serio structure. 

I know I want to reset the physical port isa0060/serio0, but I don't know if it is possible purely from within hp-wmi using functions that are already available. I imagine I could export something from atkbd, but I've not look down that path since I know the problem is with a handfull of hp laptops made by Quanta.
Comment 3 Dave Jones 2012-03-22 13:02:30 EDT
[mass update]
kernel-3.3.0-4.fc16 has been pushed to the Fedora 16 stable repository.
Please retest with this update.
Comment 4 Dave Jones 2012-03-22 13:05:43 EDT
[mass update]
kernel-3.3.0-4.fc16 has been pushed to the Fedora 16 stable repository.
Please retest with this update.
Comment 5 Dave Jones 2012-03-22 13:16:47 EDT
[mass update]
kernel-3.3.0-4.fc16 has been pushed to the Fedora 16 stable repository.
Please retest with this update.
Comment 6 Kyle 2012-05-02 14:26:39 EDT
I have retested with the latest kernel, no change. I have also dug much deeper into the issues and found out a great deal more. It seems I was misguided in my attempt to reset the keyboard in tablet mode because all four of the buttons are suppose to come through hp-wmi, and do with a DSDT hack. So, in reality, there is only one issue.

To sum up the scenario, hp-wmi waits for the BIOS to tell it that a button has been pressed. Then, hp-wmi responds with a query, "which one?". The problem is that hp-wmi never receives the event_id, which tells it to query for the button pressed.

I have hacked my DSDT, effectively reprogramming the wireless switch to act as the Hotkey pressed event_id. Now, when I push a hotkey, then slide the switch, the related hotkey scancode is read. If I had to guess, windows accomplishes this by polling, Booo.
Comment 7 Josh Boyer 2012-09-19 15:03:24 EDT
Matthew, any thoughts on Kyle's findings?
Comment 8 Matthew Garrett 2012-09-19 15:21:18 EDT
I'd need to look at the tables in more detail. I'd be slightly surprised if it resorted to polling, but there may be some enable magic we need to do. I've also seen some HPs that have reported keys via the ACPI quickstart interface, which we don't currently have a useful driver for.
Comment 9 Kyle 2012-09-21 11:42:18 EDT
I could believe some enable magic. I spent a lot of time with a schematic, trying to program the EC through the hp-wmi driver with ec_read/write. I failed in my attempts, but I did find that the internal button code is stored in an SMBus register, which I could read with ec_read(0xA2,tmp); 0xA2 is QBBB in the DSDT.

So ideally, SMBus should emit an event when it recieves the code, but that is an ACPIv2 provision and my bios is only ACPIv1. Also, the DSDT is not written for sending the event that way; i.e. The hotkey button event, below, is not coded under the SMBus, but under the EC. 

Method _Q16: (DVD/Music Button pressed)

Store (0x04, ^^^^WMID.WEID)
Store (Zero, ^^^^WMID.WEDT)
Notify (WMID, 0x80)

So, somehow, Method _Q16 needs to be enabled. With some help from the ACPI mailing list I found that GPE03 ticks when I push the wireless button, which is Method _Q15. It seems logical that something similar should happen for Method _Q16, asside from the fact that the wireless button is only one, where the hotekeys are four. I am still fuzzy on the link between GPE03 and _Q15 so I've not determined which, if any, pins are linked to _Q16.

Programming GPIO's was the next item on my troubleshooting list, but ec_write is no good for that as the GPIO config registers are in the 0xFCxx range, and ec_write is bound to 0xFFxx.

It seems trivial to change FF to FC, but kernel code is foreign water and I was finding no quick solution. Taking into consideration the time I had already diverted from other things I should be doing and the fact that I had the buttons working manually, I decided to halt my efforts.

If either of you have enough knowledge to suspect that I am on the verge of a solution and are willing to guide me through the rest I am more than willing to put my laptop back in troubleshooting mode.
Comment 10 Dave Jones 2012-10-23 11:29:11 EDT
# Mass update to all open bugs.

Kernel 3.6.2-1.fc16 has just been pushed to updates.
This update is a significant rebase from the previous version.

Please retest with this kernel, and let us know if your problem has been fixed.

In the event that you have upgraded to a newer release and the bug you reported
is still present, please change the version field to the newest release you have
encountered the issue with.  Before doing so, please ensure you are testing the
latest kernel update in that release and attach any new and relevant information
you may have gathered.

If you are not the original bug reporter and you still experience this bug,
please file a new report, as it is possible that you may be seeing a
different problem. 
(Please don't clone this bug, a fresh bug referencing this bug in the comment is sufficient).
Comment 11 Justin M. Forbes 2012-11-13 10:40:11 EST
With no response, we are closing this bug under the assumption that it is no longer an issue. If you still experience this bug, please feel free to reopen the bug report.
Comment 12 Kyle 2012-12-05 11:02:12 EST
I found the magic!		ec_write(0xe6,0x6e)

Of course, the kernel update did not fix this, but I wanted to go back and investigate everything a little more before replying. After realizing that gpe03 ticks for any hp-wmi action (e.g. lid close, brightness adjust...), I enabled ec.c debuging, and was able to see the data 0x15 when pressing the wireless switch, corresponding to method _Q15. Reassured that the ec configuration was the problem I did some digging and found a way to view the ec contents in windows. After that it was just a matter of time.

I want to propose a patch, but was thinking there should be some hardware detection. I imagine anything that uses the same DSDT/firmware would be a good test, but I'm not sure how one would do that yet. What do you think Matthew?
Comment 13 Kyle 2012-12-11 09:15:39 EST
Created attachment 661480 [details]
Proposed patch
Comment 14 Favux 2012-12-17 22:27:37 EST
Tested your proposed hp-wmi.c patch (attachment 661480 [details]) against the 3.2 kernel's hp-wmi.c in Ubuntu Precise (12.04) on a HP TX2000. I now see keycodes for the two lower right corner bezel buttons (laptop orientation) in xev for the first time.  Finally all 4 bezel buttons are present.

Rotate bezel button keycode: 161
Mobility Center bezel button keycode: 149

Congratulations Kyle.  We've been looking for this a long time, even before MisteR2 talked to Matthew Garrett about separating the laptop/tablet swivel hinge signal from the dock signal.  Would think this will apply to at least the HP TX2000, TX2500, and TX2z models.
Comment 15 Fedora End Of Life 2013-01-16 17:56:42 EST
This message is a reminder that Fedora 16 is nearing its end of life.
Approximately 4 (four) weeks from now Fedora will stop maintaining
and issuing updates for Fedora 16. It is Fedora's policy to close all
bug reports from releases that are no longer maintained. At that time
this bug will be closed as WONTFIX if it remains open with a Fedora 
'version' of '16'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version' 
to a later Fedora version prior to Fedora 16's end of life.

Bug Reporter: Thank you for reporting this issue and we are sorry that 
we may not be able to fix it before Fedora 16 is end of life. If you 
would still like to see this bug fixed and are able to reproduce it 
against a later version of Fedora, you are encouraged to click on 
"Clone This Bug" and open it against that version of Fedora.

Although we aim to fix as many bugs as possible during every release's 
lifetime, sometimes those efforts are overtaken by events. Often a 
more recent Fedora release includes newer upstream software that fixes 
bugs or makes them obsolete.

The process we are following is described here: 
Comment 16 Fedora End Of Life 2013-02-13 20:27:06 EST
Fedora 16 changed to end-of-life (EOL) status on 2013-02-12. Fedora 16 is 
no longer maintained, which means that it will not receive any further 
security or bug fix updates. As a result we are closing this bug.

If you can reproduce this bug against a currently maintained version of 
Fedora please feel free to reopen this bug against that version.

Thank you for reporting this bug and we are sorry it could not be fixed.