hp-wmi is not notified to run hotkey query...

hp-wmi is not notified to run hotkey query...

[Kyle Evans]

Hello, I have an HP tx2500 with some bezel buttons that are not
working. HP tabletPC's are notorious for this. I have discovered why
they are not working (hp-wmi is not getting the notification to query
them) and I have managed to insert some code into the DSDT that will
cause hp-wmi to successfully read these keys when the lid is closed. I
have inserted this same code into every _Q?? method from 01-8F,
including those previously undefined, but no dice. I have also
extracted the DSDT from Windows Vista, decompiled it, compared it to
the one I extracted from Linux (several small differences), recompiled
it and ran it. That didn't get it done either.

So basically, this is a BIOS problem that Windows works around. I do
not know enough about the hardware/BIOS to determine whether or not
this is something that can still be fixed in the DSDT, or something
that would have to be fixed in the kernel. For a BIOS fix, I suspect
the Embedded Controller needs to be programmed in some way, along with
a modified dsdt. For a kernel fix, I suspect Windows either polls the
WMI query, programs the EC every boot, or gets the signal some other
way (e.g. PNP0C09).

A brief description of how these hotkeys operate:
The EmbeddedController, PNP0C09, houses the internal button register,
QBBB, that stores the internal key code. When hp-wmi, PNP0C14,
performs the query, QBBB is tested for the button pressed and the
appropriate scancode is wrote to the memory location that is
subsequently read.

I have what I believe to be an accurate MB schematic, which indicates
that the embedded controller is from ENE, chip KB3926, and I have
found data sheets for similar EC's. This is something that I work on
in my spare time, so I would be grateful if someone could share some
knowledge on the subject, or kindly point me to someone who might be
able to help.

Thanks,
Kyle

Re: hp-wmi is not notified to run hotkey query...

[joeyli]

Hi Kayle, 

於 二，2012-02-14 於 11:47 -0500，Kyle Evans 提到：
> Hello, I have an HP tx2500 with some bezel buttons that are not
> working. HP tabletPC's are notorious for this. I have discovered why
> they are not working (hp-wmi is not getting the notification to query
> them) and I have managed to insert some code into the DSDT that will
> cause hp-wmi to successfully read these keys when the lid is closed. I
> have inserted this same code into every _Q?? method from 01-8F,
> including those previously undefined, but no dice. I have also
> extracted the DSDT from Windows Vista, decompiled it, compared it to
> the one I extracted from Linux (several small differences), recompiled
> it and ran it. That didn't get it done either.
> 

You might need check those buttons emit Q event or WMI event.

watch -n 1 cat /sys/firmware/acpi/interrupts/gpe_all
watch -n 1 cat /sys/firmware/acpi/interrupts/gpe[0123][0123456789ABCDEF]

The value should increased when you press hotkey.
Then reference Corentin's article: http://lwn.net/Articles/391230/

Use wmidump to parse out wmi, find out the wmi event we might want to
listen, the flags should has ACPI_WMI_EVENT.

Then, the hard thing is we need try to poke and try to reverse engineer
to GUESS the input/output format from event.

Sorry for I didn't have good experience on reverse engineer.


If the EC emit Q event when press hotkey, you can enable acpi debug log:
acpi.debug_level=0x0000000F acpi.debug_layer=0xffffffff log_buf_len=5M

To monitor which method does it run when you press hotkey.


And, it's also possibility for EC direct emit scancode, you can use:
showkey command to grub it or look at dmesg should has some messages.

> So basically, this is a BIOS problem that Windows works around. I do
> not know enough about the hardware/BIOS to determine whether or not
> this is something that can still be fixed in the DSDT, or something
> that would have to be fixed in the kernel. For a BIOS fix, I suspect
> the Embedded Controller needs to be programmed in some way, along with
> a modified dsdt. For a kernel fix, I suspect Windows either polls the
> WMI query, programs the EC every boot, or gets the signal some other
> way (e.g. PNP0C09).
> 
> A brief description of how these hotkeys operate:
> The EmbeddedController, PNP0C09, houses the internal button register,
> QBBB, that stores the internal key code. When hp-wmi, PNP0C14,
> performs the query, QBBB is tested for the button pressed and the
> appropriate scancode is wrote to the memory location that is
> subsequently read.
> 
> I have what I believe to be an accurate MB schematic, which indicates
> that the embedded controller is from ENE, chip KB3926, and I have
> found data sheets for similar EC's. This is something that I work on
> in my spare time, so I would be grateful if someone could share some
> knowledge on the subject, or kindly point me to someone who might be
> able to help.
> 
> Thanks,
> Kyle

Thanks a lot!
Joey Lee

--
To unsubscribe from this list: send the line "unsubscribe linux-acpi" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: hp-wmi is not notified to run hotkey query...

[Kyle Evans]

Thank you Joey for sharing these debug methods.

> You might need check those buttons emit Q event or WMI event.
>
> watch -n 1 cat /sys/firmware/acpi/interrupts/gpe_all
> watch -n 1 cat /sys/firmware/acpi/interrupts/gpe[0123][0123456789ABCDEF]
>
> The value should increased when you press hotkey.
> Then reference Corentin's article: http://lwn.net/Articles/391230/
>
I found that nothing happens in gpe_all when I push a hotkey button. I
also found that GPE03 calls _Q15. _Q15 is the wireless switch method,
which I have reprogrammed to notify hp-wmi of a keypress. Where is it
defined that GPE03 runs method _Q15?

> Use wmidump to parse out wmi, find out the wmi event we might want to
> listen, the flags should has ACPI_WMI_EVENT.
>
> Then, the hard thing is we need try to poke and try to reverse engineer
> to GUESS the input/output format from event.
I did not run wmidump because first, it was not installed, and second,
because I have determined that the wmi component works.

> If the EC emit Q event when press hotkey, you can enable acpi debug log:
> acpi.debug_level=0x0000000F acpi.debug_layer=0xffffffff log_buf_len=5M
>
> To monitor which method does it run when you press hotkey.
The EC not emitting a Q event is indeed my problem. It should run
method _Q16, which is defined to notify wmi of a keypress.

> And, it's also possibility for EC direct emit scancode, you can use:
> showkey command to grub it or look at dmesg should has some messages.
The way the DSDT is written, this is not the case. However, this may
be something to look at since the EC is the one that reads the button
via SMBus. I can read the internal code via ec_read(0xA2,tmp), a.k.a
QBBB.


Here is my current thinking, something in the EC should trigger method
_Q16. Ideally, SMBus should do it when it receives the button code.
Unfortunately, that function looks like it started with ACPIspec-2
section 5.6.2.2.2. Although the manufacturer's website indicates the
EC, ENE KB3926 supports ACPI v2, my dsdt.dsl only indicates ACPI v1.
Another possibility, although probably not, is that the buttons also
trigger a GPIO when one is pressed and that the correct GPIO pin needs
to be programmed correctly. My final thought is to do polling in the
EC instead of in the kernel by programming one of the GP Timers to
check for a button press and emit a wmi event in such a case.

The problem I face now is that the GPIO pin configuration is at
0xFCxx, and the GPT configuration is at 0xFExx, neither of which can
be accessed with ec_read/write, as it is confined to 0xFFxx. Maybe
there is another function that I do not find?

Thanks,
Kyle

Re: hp-wmi is not notified to run hotkey query...

[joeyli]

Sorry for I am late reply...

於 四，2012-02-23 於 12:03 -0500，Kyle Evans 提到：
> Thank you Joey for sharing these debug methods.
> 
> > You might need check those buttons emit Q event or WMI event.
> >
> > watch -n 1 cat /sys/firmware/acpi/interrupts/gpe_all
> > watch -n 1 cat /sys/firmware/acpi/interrupts/gpe[0123][0123456789ABCDEF]
> >
> > The value should increased when you press hotkey.
> > Then reference Corentin's article: http://lwn.net/Articles/391230/
> >
> I found that nothing happens in gpe_all when I push a hotkey button. I
> also found that GPE03 calls _Q15. _Q15 is the wireless switch method,
> which I have reprogrammed to notify hp-wmi of a keypress. Where is it
> defined that GPE03 runs method _Q15?
> 

Normally, you can check the _GPE number EC device in DSDT:

        Device (EC0)
        {
            Name (_HID, EisaId ("PNP0C09"))
            Name (_UID, One)
		...
            Name (_GPE, 0x03)	<--- here, assume EC link to 0x03

Per my understand, EC firmware will set the value '15' to a EC register then
emit a SCI event through 0x03. The acpi/ec.c will handle the event and
query the '15' value from EC by query command.
After got '15', acpi/ec.c will find out the handler for _Q15 then execute it.

So, EC firmware should set the value '15' to register then wait acpi/ec.c to
query it.

> > Use wmidump to parse out wmi, find out the wmi event we might want to
> > listen, the flags should has ACPI_WMI_EVENT.
> >
> > Then, the hard thing is we need try to poke and try to reverse engineer
> > to GUESS the input/output format from event.
> I did not run wmidump because first, it was not installed, and second,
> because I have determined that the wmi component works.
> 
> > If the EC emit Q event when press hotkey, you can enable acpi debug log:
> > acpi.debug_level=0x0000000F acpi.debug_layer=0xffffffff log_buf_len=5M
> >
> > To monitor which method does it run when you press hotkey.
> The EC not emitting a Q event is indeed my problem. It should run
> method _Q16, which is defined to notify wmi of a keypress.
> 

Yes, that strange because the value of gpe_all (or gpe03?) didn't
increase when press function key.
That means EC didn't emit SCI when key press.

> > And, it's also possibility for EC direct emit scancode, you can use:
> > showkey command to grub it or look at dmesg should has some messages.
> The way the DSDT is written, this is not the case. However, this may
> be something to look at since the EC is the one that reads the button
> via SMBus. I can read the internal code via ec_read(0xA2,tmp), a.k.a
> QBBB.
> 
> 
> Here is my current thinking, something in the EC should trigger method

Yes!

> _Q16. Ideally, SMBus should do it when it receives the button code.
> Unfortunately, that function looks like it started with ACPIspec-2
> section 5.6.2.2.2. Although the manufacturer's website indicates the
> EC, ENE KB3926 supports ACPI v2, my dsdt.dsl only indicates ACPI v1.
> Another possibility, although probably not, is that the buttons also
> trigger a GPIO when one is pressed and that the correct GPIO pin needs
> to be programmed correctly. My final thought is to do polling in the
> EC instead of in the kernel by programming one of the GP Timers to
> check for a button press and emit a wmi event in such a case.
> 
> The problem I face now is that the GPIO pin configuration is at
> 0xFCxx, and the GPT configuration is at 0xFExx, neither of which can
> be accessed with ec_read/write, as it is confined to 0xFFxx. Maybe
> there is another function that I do not find?
> 

Sorry for I have no idea.


Thanks a lot!
Joey Lee

--
To unsubscribe from this list: send the line "unsubscribe linux-acpi" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html