Dell Vostro V131 hotkeys revisited

Dell Vostro V131 hotkeys revisited

[Michał Kępień]

Hi all,

I'm trying to get all of the Dell Vostro V131 special hotkeys working.
This issue has been previously raised [1] by Peter Meiser, but it wasn't
solved. I decided to share my findings on this subject, hoping that
someone will have an idea how to proceed.

TL;DR: it looks like pressing these hotkeys should be reported by the
firmware using WMI, but the DSDT doesn't contain a code path which
notifies the ACPI WMI object upon a hotkey event.

Vostro V131 has 3 special hotkeys. Hotkey #1 is simply translated to
Super+X, so it's not an issue. Hotkey #2 generates keycode 0xEE (it also
raises a GPE - see below) and can reportedly be coerced to behave [2],
which leaves us with hotkey #3. While the Dell event GUID is present in
the ACPI WMI object, the dell-wmi driver does not report any events when
hotkey #3 is pressed - only the ACPI interrupt counter increases as GPE
0x17 is raised. Diving into the DSDT [3], you'll find that the _L17
method only calls another method (NEVT), where some value is retrieved
(using yet another method, ECG1) and acted upon accordingly. Using ACPI
method customization, I discovered that ECG1 returns 0x2000 for hotkey
#2 and 0x1000 for hotkey #3. But if you look at the code of the NEVT
method, it turns out these values don't cause any code path to be
executed (while I would expect them to cause the WMIA method to be
called as it notifies the ACPI WMI object).

I decompiled the MOF buffer (WQMO) using wmimofck.exe, but no magic
initialization method popped up. While in Windows, I copied a sample
VBScript from MSDN for receiving event notifications via WMI, set proper
namespace ("root\wmi") and notification query ("SELECT * FROM
BIOSEvent") and it worked. This is why I believe the WMI route is the
correct one.

However, even when I customized the NEVT method to call WMIA for values
0x1000 and 0x2000, the dell-wmi driver reported all zeros for the event
data retrieved using _WED.

Using acpi_os_name didn't change anything. Neither did updating the BIOS
to the latest version, A04.

So I wrote a kernel module which installs a custom GPE 0x17 handler,
which in turn calls the ECG1 method to retrieve the event code and
generates input events. While this works, GPE 0x17 is also used for
power and lid events (among others), so loading the module cripples
other ACPI-based features, rendering it useless.

If anyone has an idea where to go from here to solve this issue in an
elegant manner, I'm all ears.

[1] http://www.spinics.net/lists/platform-driver-x86/msg03232.html
[2] http://www.spinics.net/lists/platform-driver-x86/msg04555.html
[3] https://launchpadlibrarian.net/146038073/DSDT.dsl

-- 
Best regards,
Michał Kępień

Re: Dell Vostro V131 hotkeys revisited

[Pali Rohár]

Hi!

On Tuesday 23 June 2015 13:26:21 Michał Kępień wrote:
> Hi all,
> 
> I'm trying to get all of the Dell Vostro V131 special hotkeys working.
> This issue has been previously raised [1] by Peter Meiser, but it wasn't
> solved. I decided to share my findings on this subject, hoping that
> someone will have an idea how to proceed.
> 
> TL;DR: it looks like pressing these hotkeys should be reported by the
> firmware using WMI, but the DSDT doesn't contain a code path which
> notifies the ACPI WMI object upon a hotkey event.
> 
> Vostro V131 has 3 special hotkeys. Hotkey #1 is simply translated to
> Super+X, so it's not an issue. Hotkey #2 generates keycode 0xEE (it also
> raises a GPE - see below) and can reportedly be coerced to behave [2],
> which leaves us with hotkey #3. While the Dell event GUID is present in
> the ACPI WMI object, the dell-wmi driver does not report any events when
> hotkey #3 is pressed - only the ACPI interrupt counter increases as GPE
> 0x17 is raised. Diving into the DSDT [3], you'll find that the _L17
> method only calls another method (NEVT), where some value is retrieved
> (using yet another method, ECG1) and acted upon accordingly. Using ACPI
> method customization, I discovered that ECG1 returns 0x2000 for hotkey
> #2 and 0x1000 for hotkey #3. But if you look at the code of the NEVT
> method, it turns out these values don't cause any code path to be
> executed (while I would expect them to cause the WMIA method to be
> called as it notifies the ACPI WMI object).
> 
> I decompiled the MOF buffer (WQMO) using wmimofck.exe, but no magic
> initialization method popped up. While in Windows, I copied a sample
> VBScript from MSDN for receiving event notifications via WMI, set proper
> namespace ("root\wmi") and notification query ("SELECT * FROM
> BIOSEvent") and it worked. This is why I believe the WMI route is the
> correct one.
> 
> However, even when I customized the NEVT method to call WMIA for values
> 0x1000 and 0x2000, the dell-wmi driver reported all zeros for the event
> data retrieved using _WED.
> 
> Using acpi_os_name didn't change anything. Neither did updating the BIOS
> to the latest version, A04.
> 
> So I wrote a kernel module which installs a custom GPE 0x17 handler,
> which in turn calls the ECG1 method to retrieve the event code and
> generates input events. While this works, GPE 0x17 is also used for
> power and lid events (among others), so loading the module cripples
> other ACPI-based features, rendering it useless.
> 
> If anyone has an idea where to go from here to solve this issue in an
> elegant manner, I'm all ears.
> 
> [1] http://www.spinics.net/lists/platform-driver-x86/msg03232.html
> [2] http://www.spinics.net/lists/platform-driver-x86/msg04555.html
> [3] https://launchpadlibrarian.net/146038073/DSDT.dsl
> 

First make sure you have updated dell-wmi.c driver to last version (at
least v3.19 kernel) and check that your ACPI code contains event WMI
GUID 9DBB5994-A997-11DA-B012-B622A1EF5492

Then compile dell-wmi.ko driver with debug messages, so pr_debug() call
will print messages to dmesg. Press key and check if you see some info
from dell-wmi.ko in dmesg.

I fixed some problems with parsing WMI buffer in dell-wmi.c so maybe it
could help...

-- 
Pali Rohár
pali.rohar@gmail.com

Re: Dell Vostro V131 hotkeys revisited

[Pali Rohár]

CCing Alex

On Tuesday 23 June 2015 13:26:21 Michał Kępień wrote:
> Hi all,
> 
> I'm trying to get all of the Dell Vostro V131 special hotkeys working.
> This issue has been previously raised [1] by Peter Meiser, but it wasn't
> solved. I decided to share my findings on this subject, hoping that
> someone will have an idea how to proceed.
> 
> TL;DR: it looks like pressing these hotkeys should be reported by the
> firmware using WMI, but the DSDT doesn't contain a code path which
> notifies the ACPI WMI object upon a hotkey event.
> 
> Vostro V131 has 3 special hotkeys. Hotkey #1 is simply translated to
> Super+X, so it's not an issue. Hotkey #2 generates keycode 0xEE (it also
> raises a GPE - see below) and can reportedly be coerced to behave [2],
> which leaves us with hotkey #3. While the Dell event GUID is present in
> the ACPI WMI object, the dell-wmi driver does not report any events when
> hotkey #3 is pressed - only the ACPI interrupt counter increases as GPE
> 0x17 is raised. Diving into the DSDT [3], you'll find that the _L17
> method only calls another method (NEVT), where some value is retrieved
> (using yet another method, ECG1) and acted upon accordingly. Using ACPI
> method customization, I discovered that ECG1 returns 0x2000 for hotkey
> #2 and 0x1000 for hotkey #3. But if you look at the code of the NEVT
> method, it turns out these values don't cause any code path to be
> executed (while I would expect them to cause the WMIA method to be
> called as it notifies the ACPI WMI object).
> 
> I decompiled the MOF buffer (WQMO) using wmimofck.exe, but no magic
> initialization method popped up. While in Windows, I copied a sample
> VBScript from MSDN for receiving event notifications via WMI, set proper
> namespace ("root\wmi") and notification query ("SELECT * FROM
> BIOSEvent") and it worked. This is why I believe the WMI route is the
> correct one.
> 
> However, even when I customized the NEVT method to call WMIA for values
> 0x1000 and 0x2000, the dell-wmi driver reported all zeros for the event
> data retrieved using _WED.
> 
> Using acpi_os_name didn't change anything. Neither did updating the BIOS
> to the latest version, A04.
> 
> So I wrote a kernel module which installs a custom GPE 0x17 handler,
> which in turn calls the ECG1 method to retrieve the event code and
> generates input events. While this works, GPE 0x17 is also used for
> power and lid events (among others), so loading the module cripples
> other ACPI-based features, rendering it useless.
> 
> If anyone has an idea where to go from here to solve this issue in an
> elegant manner, I'm all ears.
> 
> [1] http://www.spinics.net/lists/platform-driver-x86/msg03232.html
> [2] http://www.spinics.net/lists/platform-driver-x86/msg04555.html
> [3] https://launchpadlibrarian.net/146038073/DSDT.dsl
> 

Alex, this looks like problem with Dell WMI. Maybe we will not be able
to fix this problem with hotkeys without information/documentation about
Dell WMI events... Do you have any idea about it?

-- 
Pali Rohár
pali.rohar@gmail.com

Re: Dell Vostro V131 hotkeys revisited

[Michał Kępień]

Hi Pali,

Thank you for your suggestions.

> First make sure you have updated dell-wmi.c driver to last version (at
> least v3.19 kernel)

I experimented with multiple kernel versions, including v4.1.

> and check that your ACPI code contains event WMI
> GUID 9DBB5994-A997-11DA-B012-B622A1EF5492

It does - that's what I meant when I wrote "the Dell event GUID is present in
the ACPI WMI object".

> Then compile dell-wmi.ko driver with debug messages, so pr_debug() call
> will print messages to dmesg. Press key and check if you see some info
> from dell-wmi.ko in dmesg.

I did that as well. Nothing appears in dmesg after pressing the
hotkeys, even when dell-wmi is compiled with -DDEBUG.

-- 
Best regards,
Michał Kępień

Re: Dell Vostro V131 hotkeys revisited

[Pali Rohár]

[-- Attachment #1: Type: Text/Plain, Size: 708 bytes --]

On Tuesday 23 June 2015 21:40:15 Michał Kępień wrote:
> > Then compile dell-wmi.ko driver with debug messages, so pr_debug()
> > call will print messages to dmesg. Press key and check if you see
> > some info from dell-wmi.ko in dmesg.
> 
> I did that as well. Nothing appears in dmesg after pressing the
> hotkeys, even when dell-wmi is compiled with -DDEBUG.

In this case it means that event was not received via WMI... pr_debug() 
should write debug info to dmesg when we receive unknown WMI event.

Maybe we need to somehow enable receiving such events? I do not have WMI 
documentation and without it I'm unable to probably fix this problem...

-- 
Pali Rohár
pali.rohar@gmail.com

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

Re: Dell Vostro V131 hotkeys revisited

[Michał Kępień]

> Maybe we need to somehow enable receiving such events?

ACPI method WED0, which should enable event collection, is automatically
invoked when dell-wmi is loaded. Some WMI implementations (e.g. Asus)
require special WMI method calls to enable hotkey event collection, but
these should be visible in the MOF and they're not in this case.

I suspect this is simply a firmware issue that the vendor works around
in Windows using some mysterious hacks. It already happened before [1]
and thus I share your lack of faith in pushing this matter any further
until we hear from Dell...

[1] http://www.spinics.net/lists/linux-acpi/msg34577.html

-- 
Best regards,
Michał Kępień

Re: Dell Vostro V131 hotkeys revisited

[Pali Rohár]

On Wednesday 24 June 2015 13:18:25 Michał Kępień wrote:
> > Maybe we need to somehow enable receiving such events?
> 
> ACPI method WED0, which should enable event collection, is automatically
> invoked when dell-wmi is loaded. Some WMI implementations (e.g. Asus)
> require special WMI method calls to enable hotkey event collection, but
> these should be visible in the MOF and they're not in this case.
> 
> I suspect this is simply a firmware issue that the vendor works around
> in Windows using some mysterious hacks. It already happened before [1]
> and thus I share your lack of faith in pushing this matter any further
> until we hear from Dell...
> 
> [1] http://www.spinics.net/lists/linux-acpi/msg34577.html
> 

Can you try to load wmi.ko with params debug_event=1 and
debug_dump_wdg=1 if you can see something in dmesg?

Maybe we really need some hack/hook if this is firmware issue...

-- 
Pali Rohár
pali.rohar@gmail.com

Re: Dell Vostro V131 hotkeys revisited

[Michał Kępień]

> Can you try to load wmi.ko with params debug_event=1 and
> debug_dump_wdg=1 if you can see something in dmesg?

I tried that too, to no avail (well, debug_dump_wdg obviously caused the
parsed contents of _WDG to be printed out, but there was only one event
GUID - the one already present in dell-wmi). Even inserting a pr_info()
call at the beginning of acpi_wmi_notify() didn't make a difference.

> Maybe we really need some hack/hook if this is firmware issue...

Probably, but I have no elegant solution (note my lack of kernel and
ACPI expertise, though), only two unholy abominations:

 a) install a GPE 0x17 handler which would imitate the actions taken by
    the NEVT method and also handle any additional values which may be
    returned by ECG1; the 0x0400 branch would come out pretty lengthy,
    though,

 b) override the ECG1 method (using ACPI method customization) so that
    it notifies some otherwise unused ACPI device [1] just before it
    returns if an event code not already handled by NEVT is detected;
    then implement a standard notify handler for that device; this
    requires CONFIG_ACPI_CUSTOM_METHOD or installing a precompiled DSDT
    using acpi_install_method(), which would just add to the insanity.

[1] Creating a new one solely for this purpose sounds utterly bonkers.

-- 
Best regards,
Michał Kępień

Re: Dell Vostro V131 hotkeys revisited

[Pali Rohár]

[-- Attachment #1: Type: Text/Plain, Size: 2215 bytes --]

On Thursday 25 June 2015 11:02:06 Michał Kępień wrote:
> > Can you try to load wmi.ko with params debug_event=1 and
> > debug_dump_wdg=1 if you can see something in dmesg?
> 
> I tried that too, to no avail (well, debug_dump_wdg obviously caused
> the parsed contents of _WDG to be printed out, but there was only
> one event GUID - the one already present in dell-wmi). Even
> inserting a pr_info() call at the beginning of acpi_wmi_notify()
> didn't make a difference.
> 
> > Maybe we really need some hack/hook if this is firmware issue...
> 
> Probably, but I have no elegant solution (note my lack of kernel and
> ACPI expertise, though), only two unholy abominations:
> 
>  a) install a GPE 0x17 handler which would imitate the actions taken
> by the NEVT method and also handle any additional values which may
> be returned by ECG1; the 0x0400 branch would come out pretty
> lengthy, though,
> 
>  b) override the ECG1 method (using ACPI method customization) so
> that it notifies some otherwise unused ACPI device [1] just before
> it returns if an event code not already handled by NEVT is detected;
> then implement a standard notify handler for that device; this
> requires CONFIG_ACPI_CUSTOM_METHOD or installing a precompiled DSDT
> using acpi_install_method(), which would just add to the insanity.
> 
> [1] Creating a new one solely for this purpose sounds utterly
> bonkers.

Hi again,

now I looked deeply at your problem. I read that part of ACPI code and 
it really looks like that NEVT method does not handle all possible 
events.

But how can windows driver handle that? In my opinion it either do some 
init magic so NEVT will receive event with mask 0x0800 or it overwrite 
some ACPI method and handle it locally...

You can try to play with overwriting ACPI function NEVT at runtime and 
patch it to call WMIA also for other masks.

Are you 100% sure that keypress is not sent to i8042 controller and that 
linux kbd driver does not filter it somehow? Ideally test events with 
userspace application input-events and not with some X utility (to be 
sure that X does not consume that keypress too).

-- 
Pali Rohár
pali.rohar@gmail.com

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

Re: Dell Vostro V131 hotkeys revisited

[Michał Kępień]

> now I looked deeply at your problem. I read that part of ACPI code and 
> it really looks like that NEVT method does not handle all possible 
> events.

Thank you for taking your time to review my findings.

> But how can windows driver handle that? In my opinion it either do some
> init magic so NEVT will receive event with mask 0x0800 or it overwrite
> some ACPI method and handle it locally...

I have no idea, but Kyle Evans had a few in a message I referenced
earlier in this thread [1].

> You can try to play with overwriting ACPI function NEVT at runtime and 
> patch it to call WMIA also for other masks.

I already tried that before writing the first message in this thread,
which includes the following quote:

"However, even when I customized the NEVT method to call WMIA for values
0x1000 and 0x2000, the dell-wmi driver reported all zeros for the event
data retrieved using _WED."

> Are you 100% sure that keypress is not sent to i8042 controller and that 
> linux kbd driver does not filter it somehow? Ideally test events with 
> userspace application input-events and not with some X utility (to be 
> sure that X does not consume that keypress too).

Yes, I'm sure. First I booted the kernel with i8042.debug=1. Interrupts
were raised as expected for hotkey #2, but not for hotkey #3. Then I
enabled CONFIG_INPUT_EVBUG. As expected, events were generated for
hotkey #2, but not for hotkey #3.

[1] http://www.spinics.net/lists/linux-acpi/msg34577.html 

-- 
Best regards,
Michał Kępień

Re: Dell Vostro V131 hotkeys revisited

[Pali Rohár]

On Tuesday 30 June 2015 09:38:35 Michał Kępień wrote:
> > now I looked deeply at your problem. I read that part of ACPI code and 
> > it really looks like that NEVT method does not handle all possible 
> > events.
> 
> Thank you for taking your time to review my findings.
> 
> > But how can windows driver handle that? In my opinion it either do some
> > init magic so NEVT will receive event with mask 0x0800 or it overwrite
> > some ACPI method and handle it locally...
> 
> I have no idea, but Kyle Evans had a few in a message I referenced
> earlier in this thread [1].
> 
> > You can try to play with overwriting ACPI function NEVT at runtime and 
> > patch it to call WMIA also for other masks.
> 
> I already tried that before writing the first message in this thread,
> which includes the following quote:
> 
> "However, even when I customized the NEVT method to call WMIA for values
> 0x1000 and 0x2000, the dell-wmi driver reported all zeros for the event
> data retrieved using _WED."
> 
> > Are you 100% sure that keypress is not sent to i8042 controller and that 
> > linux kbd driver does not filter it somehow? Ideally test events with 
> > userspace application input-events and not with some X utility (to be 
> > sure that X does not consume that keypress too).
> 
> Yes, I'm sure. First I booted the kernel with i8042.debug=1. Interrupts
> were raised as expected for hotkey #2, but not for hotkey #3. Then I
> enabled CONFIG_INPUT_EVBUG. As expected, events were generated for
> hotkey #2, but not for hotkey #3.
> 
> [1] http://www.spinics.net/lists/linux-acpi/msg34577.html 
> 

Are you able to detect if Windows receive keypress via WMI or keyboard
controller or from other driver?

Also what you can try is to dump EC registers and DSDT table from
Windows and compare it with Linux.

I have no idea other idea. Either we miss some EC init code to enable
receiving events (via i8042 or WMI) or some other driver which use other
ACPI device or GPIO...

Alex, can you ask for some documentation about Dell Vostro V131 hotkeys?

-- 
Pali Rohár
pali.rohar@gmail.com

Re: Dell Vostro V131 hotkeys revisited

[Michał Kępień]

> Are you able to detect if Windows receive keypress via WMI or keyboard
> controller or from other driver?

I believe it's done via WMI. In the first message in this thread, I
wrote:

"While in Windows, I copied a sample VBScript from MSDN for receiving
event notifications via WMI, set proper namespace ("root\wmi") and
notification query ("SELECT * FROM BIOSEvent") and it worked."

> Also what you can try is to dump EC registers and DSDT table from
> Windows and compare it with Linux.

Well, here's the catch: there is no PNP0C09 device in the DSDT and thus
the EC driver isn't even loaded in Linux and I can't dump EC registers.
Yet Windows tools seem to be able to do it, using ports 0x66/0x62. I'm
confused.

DSDT tables dumped from Windows and Linux are identical.

-- 
Best regards,
Michał Kępień

Re: Dell Vostro V131 hotkeys revisited

[Pali Rohár]

On Wednesday 01 July 2015 10:32:01 Michał Kępień wrote:
> > Are you able to detect if Windows receive keypress via WMI or keyboard
> > controller or from other driver?
> 
> I believe it's done via WMI. In the first message in this thread, I
> wrote:
> 
> "While in Windows, I copied a sample VBScript from MSDN for receiving
> event notifications via WMI, set proper namespace ("root\wmi") and
> notification query ("SELECT * FROM BIOSEvent") and it worked."
> 

Ok, I do not know all these windows internals, but it would be cool to
check if WMI event is really received with correct mask in that NEVT
method. No idea if this is possible to debug/test on windows...

> > Also what you can try is to dump EC registers and DSDT table from
> > Windows and compare it with Linux.
> 
> Well, here's the catch: there is no PNP0C09 device in the DSDT and thus
> the EC driver isn't even loaded in Linux and I can't dump EC registers.
> Yet Windows tools seem to be able to do it, using ports 0x66/0x62. I'm
> confused.
> 

Hm... could be this reason? And windows read pressed hotkeys from EC
registers?

Can you ask acpi guys what could *not* work if acpi ec driver is not
loaded?

> DSDT tables dumped from Windows and Linux are identical.
> 

Ok, then we should be able to do it also from Linux.

-- 
Pali Rohár
pali.rohar@gmail.com

Re: Dell Vostro V131 hotkeys revisited

[Michał Kępień]

> Ok, I do not know all these windows internals, but it would be cool to
> check if WMI event is really received with correct mask in that NEVT
> method. No idea if this is possible to debug/test on windows...

That was my first idea after analyzing the NEVT method, but after
skimming through the AMLI Debugger and KD docs, I got the impression
that setting up an ACPI debugging session in Windows is so much of a
hassle [1] for someone with no experience in Windows kernel-mode
debugging that I'd rather hack the hell out of the DSDT in Linux and get
on with my life.

> > Well, here's the catch: there is no PNP0C09 device in the DSDT and thus
> > the EC driver isn't even loaded in Linux and I can't dump EC registers.
> > Yet Windows tools seem to be able to do it, using ports 0x66/0x62. I'm
> > confused.
> > 
> 
> Hm... could be this reason? And windows read pressed hotkeys from EC
> registers?
> 
> Can you ask acpi guys what could *not* work if acpi ec driver is not
> loaded?

Maybe I am missing something here, but even if the above turns out to be
the case, how would such knowledge help in solving the issue? Suppose we
learn that some magic command needs to be sent to the EC to enable event
reporting via WMI, but we cannot do that as the kernel doesn't even see
the EC.

If I'm reading the DSDT dump correctly, it seems the Vostro V131 makes
heavy use of SMIs. \SB.SMII is an alias for the 0xB2 I/O port, which is
written to by the WMI and SXX6 methods. A call to the latter is made
inside ECG1 (from SX11, specifically). IOW, an SMI is generated to get
the event code. My guess would be that some magic SMI has to be
generated if events are to be reported via WMI or something among the
lines. Which gets us back to hearing from Dell as trying random values
doesn't sound like a sane thing to do.

[1] Another Windows machine is needed, debugging over a network cable is
only supported since Windows 8, the Vostro V131 doesn't have any
Firewire or serial ports, so I'd need to buy a USB debug cable, then get
get my hands on a checked version of Acpi.sys and pray it all works. Now
compare all that to recompiling the kernel with
CONFIG_ACPI_CUSTOM_METHOD and CONFIG_ACPI_DEBUG enabled.

-- 
Best regards,
Michał Kępień

Re: Dell Vostro V131 hotkeys revisited

[Pali Rohár]

On Wednesday 01 July 2015 12:11:46 Michał Kępień wrote:
> > Ok, I do not know all these windows internals, but it would be cool to
> > check if WMI event is really received with correct mask in that NEVT
> > method. No idea if this is possible to debug/test on windows...
> 
> That was my first idea after analyzing the NEVT method, but after
> skimming through the AMLI Debugger and KD docs, I got the impression
> that setting up an ACPI debugging session in Windows is so much of a
> hassle [1] for someone with no experience in Windows kernel-mode
> debugging that I'd rather hack the hell out of the DSDT in Linux and get
> on with my life.
> 
> > > Well, here's the catch: there is no PNP0C09 device in the DSDT and thus
> > > the EC driver isn't even loaded in Linux and I can't dump EC registers.
> > > Yet Windows tools seem to be able to do it, using ports 0x66/0x62. I'm
> > > confused.
> > > 
> > 
> > Hm... could be this reason? And windows read pressed hotkeys from EC
> > registers?
> > 
> > Can you ask acpi guys what could *not* work if acpi ec driver is not
> > loaded?
> 
> Maybe I am missing something here, but even if the above turns out to be
> the case, how would such knowledge help in solving the issue? Suppose we
> learn that some magic command needs to be sent to the EC to enable event
> reporting via WMI, but we cannot do that as the kernel doesn't even see
> the EC.
> 

It would mean that we need to write new driver for it (or extend some).

> If I'm reading the DSDT dump correctly, it seems the Vostro V131 makes
> heavy use of SMIs. \SB.SMII is an alias for the 0xB2 I/O port, which is
> written to by the WMI and SXX6 methods. A call to the latter is made
> inside ECG1 (from SX11, specifically). IOW, an SMI is generated to get
> the event code. My guess would be that some magic SMI has to be
> generated if events are to be reported via WMI or something among the
> lines. Which gets us back to hearing from Dell as trying random values
> doesn't sound like a sane thing to do.
> 

Yes, I'm still thinking about some missing init call. And for that we
need documentation: what and how.

> [1] Another Windows machine is needed, debugging over a network cable is
> only supported since Windows 8, the Vostro V131 doesn't have any
> Firewire or serial ports, so I'd need to buy a USB debug cable, then get
> get my hands on a checked version of Acpi.sys and pray it all works. Now
> compare all that to recompiling the kernel with
> CONFIG_ACPI_CUSTOM_METHOD and CONFIG_ACPI_DEBUG enabled.
> 

I know, debugging windows kernel is hard and only sometimes is possible.

-- 
Pali Rohár
pali.rohar@gmail.com

Re: Dell Vostro V131 hotkeys revisited

[Michał Kępień]

> Yes, I'm still thinking about some missing init call.

I finally figured it out and we were right - to enable event reporting
via WMI, a WMI method call with a specially crafted buffer passed as an
argument is needed. (Though the SMI lead was correct as the WMI method
generates an SMI calling a BIOS function specified in the buffer
passed.)

I'll be happy to prepare a patch, though I'll appreciate some guidance
in two areas:

 1) The GUID, buffer format and the function to use (DELL_APP_GUID,
    struct app_wmi_args and dell_wmi_perform_query(), respectively) are
    already defined in drivers/leds/dell-led.c. However, the call to be
    made is obviously not related to LEDs, but rather to WMI hotkeys,
    which are handled in drivers/platform/x86/dell-wmi.c. Also, the call
    should only be made on a Vostro V131 and DMI-based filtering is done
    in yet another file, drivers/platform/x86/dell-laptop.c. Where
    should the fix be placed?

 2) Pressing hotkey #3 on a Dell Vostro V131 generates WMI event 0xe025,
    but no keycode. Apparently, Dell XPS L502X generates the same WMI
    event for a hotkey which also generates a keycode [1]. What's the
    best way to solve this conflict?

[1] commit f1566f0: "dell-wmi: Add keys for Dell XPS L502X"

-- 
Best regards,
Michał Kępień

Re: Dell Vostro V131 hotkeys revisited

[Pali Rohár]

[-- Attachment #1: Type: Text/Plain, Size: 2477 bytes --]

On Thursday 02 July 2015 22:41:22 Michał Kępień wrote:
> > Yes, I'm still thinking about some missing init call.
> 
> I finally figured it out and we were right - to enable event
> reporting via WMI, a WMI method call with a specially crafted buffer
> passed as an argument is needed. (Though the SMI lead was correct as
> the WMI method generates an SMI calling a BIOS function specified in
> the buffer passed.)
> 

Nice :-) Can you write which WMI call needs to be called?

> I'll be happy to prepare a patch, though I'll appreciate some
> guidance in two areas:
> 
>  1) The GUID, buffer format and the function to use (DELL_APP_GUID,
>     struct app_wmi_args and dell_wmi_perform_query(), respectively)
> are already defined in drivers/leds/dell-led.c. However, the call to
> be made is obviously not related to LEDs, but rather to WMI hotkeys,
> which are handled in drivers/platform/x86/dell-wmi.c. Also, the call
> should only be made on a Vostro V131 and DMI-based filtering is done
> in yet another file, drivers/platform/x86/dell-laptop.c. Where
> should the fix be placed?
> 

Last time when I looked into dell-led.c code it called some WMI
functions which are just re-implementation of SMI based SMBIOS
functions. From information which I have that is just WMI interface for
dell SMBIOS one.

I already asked Alex and other people for official ACPI/WMI Dell
documentation, so we would be able to solve these hotkey problems once
and for all, but I did not get anything yet.

What I found on internet is just this one out-of-dated documentation:
http://vpsservice1.sampo.com.tw/sampo_update/document/jimmy/ACPI-WMI%20.pdf

I would suggest you to read it (it is not long) to see Dell WMI methods
are just ACPI "wrapper" around Dell SMBIOS (dcdbas.ko driver) used by
dell-laptop.ko.

>  2) Pressing hotkey #3 on a Dell Vostro V131 generates WMI event
> 0xe025, but no keycode. Apparently, Dell XPS L502X generates the
> same WMI event for a hotkey which also generates a keycode [1].
> What's the best way to solve this conflict?
> 
> [1] commit f1566f0: "dell-wmi: Add keys for Dell XPS L502X"

Look at dell-wmi.c source code. Which event format is that? New one
(partially described in above PDF document) when dell_new_hk_type is
true? Or old one?

Can you please enable pr_debug() in dell-wmi.c and send dmesg output
from dell-wmi.ko (specially dell_wmi_notify)?

-- 
Pali Rohár
pali.rohar@gmail.com

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

Re: Dell Vostro V131 hotkeys revisited

[Michał Kępień]

> Can you write which WMI call needs to be called?

Technically, one needs to call method DoBFn (method ID = 1) using GUID
A80593CE-A997-11DA-B012-B622A1EF5492. Though if you look at the ACPI
method this GUID maps to (WMBA), you'll notice that the first two
arguments passed to it (instance number and method ID) are simply
ignored and the only one that matters is the buffer passed (third
argument).

> Last time when I looked into dell-led.c code it called some WMI
> functions which are just re-implementation of SMI based SMBIOS
> functions. From information which I have that is just WMI interface for
> dell SMBIOS one.
> 
> I already asked Alex and other people for official ACPI/WMI Dell
> documentation, so we would be able to solve these hotkey problems once
> and for all, but I did not get anything yet.
> 
> What I found on internet is just this one out-of-dated documentation:
> http://vpsservice1.sampo.com.tw/sampo_update/document/jimmy/ACPI-WMI%20.pdf
> 
> I would suggest you to read it (it is not long) to see Dell WMI methods
> are just ACPI "wrapper" around Dell SMBIOS (dcdbas.ko driver) used by
> dell-laptop.ko.

Great, thanks. I'll look into it.
 
> >  2) Pressing hotkey #3 on a Dell Vostro V131 generates WMI event
> > 0xe025, but no keycode. Apparently, Dell XPS L502X generates the
> > same WMI event for a hotkey which also generates a keycode [1].
> > What's the best way to solve this conflict?
> > 
> > [1] commit f1566f0: "dell-wmi: Add keys for Dell XPS L502X"
> 
> Look at dell-wmi.c source code. Which event format is that? New one
> (partially described in above PDF document) when dell_new_hk_type is
> true? Or old one?

Vostro V131 is using the legacy keymap.

> Can you please enable pr_debug() in dell-wmi.c and send dmesg output
> from dell-wmi.ko (specially dell_wmi_notify)?

Here's what appears in dmesg after pressing hotkey #3:

------------------------------------------------------------------------
dell_wmi: Received WMI event (02 00 00 00 25 e0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00)
dell_wmi: Key e025 pressed
wmi: DEBUG Event GUID: 9DBB5994-A997-11DA-B012-B622A1EF5492
------------------------------------------------------------------------

-- 
Best regards,
Michał Kępień

Re: Dell Vostro V131 hotkeys revisited

[Pali Rohár]

On Friday 03 July 2015 08:52:44 Michał Kępień wrote:
> > Can you write which WMI call needs to be called?
> 
> Technically, one needs to call method DoBFn (method ID = 1) using GUID
> A80593CE-A997-11DA-B012-B622A1EF5492. Though if you look at the ACPI
> method this GUID maps to (WMBA), you'll notice that the first two
> arguments passed to it (instance number and method ID) are simply
> ignored and the only one that matters is the buffer passed (third
> argument).
> 
> > Last time when I looked into dell-led.c code it called some WMI
> > functions which are just re-implementation of SMI based SMBIOS
> > functions. From information which I have that is just WMI interface for
> > dell SMBIOS one.
> > 
> > I already asked Alex and other people for official ACPI/WMI Dell
> > documentation, so we would be able to solve these hotkey problems once
> > and for all, but I did not get anything yet.
> > 
> > What I found on internet is just this one out-of-dated documentation:
> > http://vpsservice1.sampo.com.tw/sampo_update/document/jimmy/ACPI-WMI%20.pdf
> > 
> > I would suggest you to read it (it is not long) to see Dell WMI methods
> > are just ACPI "wrapper" around Dell SMBIOS (dcdbas.ko driver) used by
> > dell-laptop.ko.
> 
> Great, thanks. I'll look into it.
>  
> > >  2) Pressing hotkey #3 on a Dell Vostro V131 generates WMI event
> > > 0xe025, but no keycode. Apparently, Dell XPS L502X generates the
> > > same WMI event for a hotkey which also generates a keycode [1].
> > > What's the best way to solve this conflict?
> > > 
> > > [1] commit f1566f0: "dell-wmi: Add keys for Dell XPS L502X"
> > 
> > Look at dell-wmi.c source code. Which event format is that? New one
> > (partially described in above PDF document) when dell_new_hk_type is
> > true? Or old one?
> 
> Vostro V131 is using the legacy keymap.
> 
> > Can you please enable pr_debug() in dell-wmi.c and send dmesg output
> > from dell-wmi.ko (specially dell_wmi_notify)?
> 
> Here's what appears in dmesg after pressing hotkey #3:
> 
> ------------------------------------------------------------------------
> dell_wmi: Received WMI event (02 00 00 00 25 e0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00)
> dell_wmi: Key e025 pressed
> wmi: DEBUG Event GUID: 9DBB5994-A997-11DA-B012-B622A1EF5492
> ------------------------------------------------------------------------
> 

It looks like above buffer has format of *new* event (0002 - length of
event, 0000 - type of event, e025 - data). But when using legacy keymap
then dell-wmi.c parse events with old format (which means type=0000 is
dropped and data=e025 is translated to some key).

This is even harder as I thought. Looks like big mess and now I would
say, without documentation for Dell WMI events we are not able to fix
this correctly without breaking other laptops...

========================================================================

CCing kernel Dell developers, can you provide Dell WMI documentation for
events and hotkeys? We have problems with enabling events for additional
buttons/keys on Dell laptops and also parsing WMI events which BIOS/ACPI
generates and send to kernel. Please, I really do not know how to how we
can fix these "hotkey/events" problems.

Something like this document, but updated for new laptops:
http://vpsservice1.sampo.com.tw/sampo_update/document/jimmy/ACPI-WMI%20.pdf

Thanks!

-- 
Pali Rohár
pali.rohar@gmail.com

Re: Dell Vostro V131 hotkeys revisited

[Michał Kępień]

> It looks like above buffer has format of *new* event (0002 - length of
> event, 0000 - type of event, e025 - data). But when using legacy keymap
> then dell-wmi.c parse events with old format (which means type=0000 is
> dropped and data=e025 is translated to some key).
> 
> This is even harder as I thought. Looks like big mess and now I would
> say, without documentation for Dell WMI events we are not able to fix
> this correctly without breaking other laptops...

As far as I understand, the specific case that we're dealing with here
is that on one laptop model a certain WMI event is generated along with
a keycode while another mothel generates the same WMI event without an
accompanying keycode. Currently the Dell WMI driver ignores the WMI
event in question, but it is processed by i8042.

Could we perhaps do the opposite for this specific event, i.e. filter it
out using the i8042 filter in dell-laptop.c and translate the WMI event
into a keycode in dell-wmi.c? This shouldn't conflict with the dell-rbtn
driver as there are no ACPI devices on an XPS L502X that could be
handled by that driver [1] and thus the i8042 filter should be
installed. However, that i8042 keycode could potentially be generated on
other, WMI-less models and such a change would break them, rendering it
unacceptable. I also assumed pressing the hotkey in question on an XPS
L502X produces the same i8042 keycode as the WMI event code indicates...

[1] this statement is based on the DSDT dump from a Dell XPS L502X that
    I found here: https://launchpadlibrarian.net/68880655/DSDT.dsl

-- 
Best regards,
Michał Kępień

Re: Dell Vostro V131 hotkeys revisited

[Pali Rohár]

On Friday 03 July 2015 13:26:11 Michał Kępień wrote:
> > It looks like above buffer has format of *new* event (0002 - length of
> > event, 0000 - type of event, e025 - data). But when using legacy keymap
> > then dell-wmi.c parse events with old format (which means type=0000 is
> > dropped and data=e025 is translated to some key).
> > 
> > This is even harder as I thought. Looks like big mess and now I would
> > say, without documentation for Dell WMI events we are not able to fix
> > this correctly without breaking other laptops...
> 
> As far as I understand, the specific case that we're dealing with here
> is that on one laptop model a certain WMI event is generated along with
> a keycode while another mothel generates the same WMI event without an
> accompanying keycode. Currently the Dell WMI driver ignores the WMI
> event in question, but it is processed by i8042.
> 
> Could we perhaps do the opposite for this specific event, i.e. filter it
> out using the i8042 filter in dell-laptop.c and translate the WMI event
> into a keycode in dell-wmi.c? This shouldn't conflict with the dell-rbtn
> driver as there are no ACPI devices on an XPS L502X that could be
> handled by that driver [1] and thus the i8042 filter should be
> installed. However, that i8042 keycode could potentially be generated on
> other, WMI-less models and such a change would break them, rendering it
> unacceptable. I also assumed pressing the hotkey in question on an XPS
> L502X produces the same i8042 keycode as the WMI event code indicates...
> 
> [1] this statement is based on the DSDT dump from a Dell XPS L502X that
>     I found here: https://launchpadlibrarian.net/68880655/DSDT.dsl
> 

I would like to wait for documentation and not to invent/mess something
again and more. Creating big list with DMI names and associate hooks for
them based on "our" observation is good way to hell!

We even do not know:

1) how to activate code for receiving events
2) what is format of which event
3) which keypress should be reported by i8042 bus and which via ACPI/WMI

-- 
Pali Rohár
pali.rohar@gmail.com

Re: Dell Vostro V131 hotkeys revisited

[Michał Kępień]

> I would like to wait for documentation and not to invent/mess something
> again and more.

I get your point, but even getting our hands on the docs would most
likely do nothing for the fact that hotkey behavior differs between
models.

> Creating big list with DMI names and associate hooks for
> them based on "our" observation is good way to hell!

Obviously it's not an elegant solution. Obviously using WMI for
something as simple as handling a keypress is insane. Yet, this is the
way vendors (at least some of them) chose. I guess the decision to be
made is whether to try to support it anyway or accept the fact that
arbitrary hardware will not be fully functional, even though we know
exactly why.

Of course that's not my call to make and I respect your decision. Just
putting my two cents in as I despise the idea of letting the vendor
decide which features of the hardware I bought from them I can use and
which ones I can't.

> We even do not know:
> 
> 1) how to activate code for receiving events

Oh, but we do! At least for some models ;) We just don't know _why_ it
should be done the way it is done. It sure would be nice to know that,
but should it stop us from implementing a working solution?

> 2) what is format of which event

Well, dell-wmi.ko seems to be decoding the events pretty well. And
again, the format differs between models (and is probably subject to
change in yet to be released hardware) and we can't really do a thing
about it. We can either support it or not.

> 3) which keypress should be reported by i8042 bus and which via ACPI/WMI

That depends on the model ;)

-- 
Best regards,
Michał Kępień

Re: Dell Vostro V131 hotkeys revisited

[Pali Rohár]

On Friday 03 July 2015 15:23:41 Michał Kępień wrote:
> > I would like to wait for documentation and not to invent/mess something
> > again and more.
> 
> I get your point, but even getting our hands on the docs would most
> likely do nothing for the fact that hotkey behavior differs between
> models.
> 
> > Creating big list with DMI names and associate hooks for
> > them based on "our" observation is good way to hell!
> 
> Obviously it's not an elegant solution. Obviously using WMI for
> something as simple as handling a keypress is insane. Yet, this is the
> way vendors (at least some of them) chose. I guess the decision to be
> made is whether to try to support it anyway or accept the fact that
> arbitrary hardware will not be fully functional, even though we know
> exactly why.
> 
> Of course that's not my call to make and I respect your decision. Just
> putting my two cents in as I despise the idea of letting the vendor
> decide which features of the hardware I bought from them I can use and
> which ones I can't.
> 
> > We even do not know:
> > 
> > 1) how to activate code for receiving events
> 
> Oh, but we do! At least for some models ;) We just don't know _why_ it
> should be done the way it is done. It sure would be nice to know that,
> but should it stop us from implementing a working solution?
> 
> > 2) what is format of which event
> 
> Well, dell-wmi.ko seems to be decoding the events pretty well. And
> again, the format differs between models (and is probably subject to
> change in yet to be released hardware) and we can't really do a thing
> about it. We can either support it or not.
> 
> > 3) which keypress should be reported by i8042 bus and which via ACPI/WMI
> 
> That depends on the model ;)
> 

There are two different things:

1) Vendor said that laptop models with specific DMI should be handled by
   code XYZ...

2) Vendor said that all laptop models which report in register ABC value
   47 should be handled by code XYZ.

And we are thing to fix above facts with solution:

3) See how one model reacts and from this information create specific
   hook for that one model.

I'm really against solution 3) if we already know that every model uses
different event handling.

If for model Dell Vostro V131 vendor say 1) I'm fine with solution to
hardcode DMI name and hook for it. 2) is of course better, but 3) for
lot of machines is non go.

-- 
Pali Rohár
pali.rohar@gmail.com

Re: Dell Vostro V131 hotkeys revisited

[Michał Kępień]

> There are two different things:
> 
> 1) Vendor said that laptop models with specific DMI should be handled by
>    code XYZ...
> 
> 2) Vendor said that all laptop models which report in register ABC value
>    47 should be handled by code XYZ.
> 
> And we are thing to fix above facts with solution:
> 
> 3) See how one model reacts and from this information create specific
>    hook for that one model.
> 
> I'm really against solution 3) if we already know that every model uses
> different event handling.
> 
> If for model Dell Vostro V131 vendor say 1) I'm fine with solution to
> hardcode DMI name and hook for it. 2) is of course better, but 3) for
> lot of machines is non go.

I couldn't agree more. Here's the thing, though: the vendor doesn't seem
to be saying anything. I guess I'll have to get over it.

-- 
Best regards,
Michał Kępień

Re: Dell Vostro V131 hotkeys revisited

[Pali Rohár]

On Friday 03 July 2015 15:50:47 Michał Kępień wrote:
> > There are two different things:
> > 
> > 1) Vendor said that laptop models with specific DMI should be handled by
> >    code XYZ...
> > 
> > 2) Vendor said that all laptop models which report in register ABC value
> >    47 should be handled by code XYZ.
> > 
> > And we are thing to fix above facts with solution:
> > 
> > 3) See how one model reacts and from this information create specific
> >    hook for that one model.
> > 
> > I'm really against solution 3) if we already know that every model uses
> > different event handling.
> > 
> > If for model Dell Vostro V131 vendor say 1) I'm fine with solution to
> > hardcode DMI name and hook for it. 2) is of course better, but 3) for
> > lot of machines is non go.
> 
> I couldn't agree more. Here's the thing, though: the vendor doesn't seem
> to be saying anything. I guess I'll have to get over it.
> 

Yes, "vendor does not say anything" is also what could happen...

Then in your case, I would need to know format of *all* events which can
your laptop via WMI receive. If we collect as more as possible events
from different laptops we can try to abstract format/interface.

-- 
Pali Rohár
pali.rohar@gmail.com

Re: Dell Vostro V131 hotkeys revisited

[Pali Rohár]

On Friday 03 July 2015 16:09:01 Pali Rohár wrote:
> Yes, "vendor does not say anything" is also what could happen...
> 
> Then in your case, I would need to know format of *all* events which can
> your laptop via WMI receive. If we collect as more as possible events
> from different laptops we can try to abstract format/interface.
> 

CCing Gabriele, can you please provide buffers of all possible WMI
events which can be received on your dell machine via dell-wmi.ko?
(just enable pr_debug() in dell-wmi.c)

Alex, if you still have Dell testing machines and you have time, can you
do that too?

-- 
Pali Rohár
pali.rohar@gmail.com

Re: Dell Vostro V131 hotkeys revisited

[Gabriele Mazzotta]

On Friday 03 July 2015 16:14:54 Pali Rohár wrote:
> On Friday 03 July 2015 16:09:01 Pali Rohár wrote:
> > Yes, "vendor does not say anything" is also what could happen...
> > 
> > Then in your case, I would need to know format of *all* events which can
> > your laptop via WMI receive. If we collect as more as possible events
> > from different laptops we can try to abstract format/interface.
> > 
> 
> CCing Gabriele, can you please provide buffers of all possible WMI
> events which can be received on your dell machine via dell-wmi.ko?
> (just enable pr_debug() in dell-wmi.c)

Hi,

here below there's what I could get from my XPS13 9333.

[ 6115.412615] wifi - disable/enable
[ 6115.710966] dell_wmi: Received WMI event (06 00 00 00 08 e0 1d 03 0a 00 00 01 01 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00)
[ 6115.710972] dell_wmi: Key e008 pressed
[ 6116.766483] dell_wmi: Received WMI event (06 00 00 00 08 e0 1d 03 09 00 00 01 01 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00)
[ 6116.766483] dell_wmi: Key e008 pressed
[ 6121.555618] battery health
[ 6122.093304] dell_wmi: Received WMI event (02 00 00 00 07 e0 1d 03 08 00 00 01 01 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00)
[ 6122.093313] dell_wmi: Key e007 pressed
[ 6128.550329] brightness down
[ 6129.739787] dell_wmi: Received WMI event (03 00 00 00 05 e0 0e 00 08 00 00 01 01 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00)
[ 6129.739799] dell_wmi: Key e005 pressed
[ 6134.469814] brightness up
[ 6134.853151] dell_wmi: Received WMI event (03 00 00 00 06 e0 0f 00 08 00 00 01 01 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00)
[ 6134.853157] dell_wmi: Key e006 pressed
[ 6143.153178] keyboard illumination - level 2 1 0
[ 6143.056422] dell_wmi: Received WMI event (03 00 00 00 0c e0 02 00 09 00 00 01 01 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00)
[ 6143.056427] dell_wmi: Key e00c pressed
[ 6143.768556] dell_wmi: Received WMI event (03 00 00 00 0c e0 01 00 09 00 00 01 01 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00)
[ 6143.768566] dell_wmi: Key e00c pressed
[ 6144.340347] dell_wmi: Received WMI event (03 00 00 00 0c e0 00 00 09 00 00 01 01 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00)
[ 6144.340357] dell_wmi: Key e00c pressed
[ 6176.922331] volume down
[ 6177.325737] dell_wmi: Received WMI event (02 00 00 00 2e e0 01 00 08 00 00 01 01 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00)
[ 6177.325746] dell_wmi: Key e02e pressed
[ 6182.892971] volume up
[ 6183.240709] dell_wmi: Received WMI event (02 00 00 00 30 e0 01 00 08 00 00 01 01 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00)
[ 6183.240715] dell_wmi: Key e030 pressed
[ 6188.932940] mute
[ 6190.453967] dell_wmi: Received WMI event (02 00 00 00 f7 e0 01 00 08 00 00 01 01 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00)
[ 6190.453975] dell_wmi: Key e0f7 pressed

Re: Dell Vostro V131 hotkeys revisited

[Michał Kępień]

> here below there's what I could get from my XPS13 9333.

Gabriele, is any of the WMI events you listed accompanied by an i8042
interrupt? If so, could you check the generated keycode?

-- 
Best regards,
Michał Kępień

Re: Dell Vostro V131 hotkeys revisited

[Gabriele Mazzotta]

On Friday 03 July 2015 22:07:09 Michał Kępień wrote:
> > here below there's what I could get from my XPS13 9333.
> 
> Gabriele, is any of the WMI events you listed accompanied by an i8042
> interrupt? If so, could you check the generated keycode?

Yes, volume down, volume up and mute.

If you take a look at dell-wmi.c, you'll see that the driver ignores
the WMI events associated to those keys (legacy keymap), so only the
i8042 events are taken into account. The generated keycodes are the
expected ones: KEY_VOLUMEDOWN, KEY_VOLUMEUP and KEY_MIN_INTERESTING.

Re: Dell Vostro V131 hotkeys revisited

[Michał Kępień]

> Then in your case, I would need to know format of *all* events which can
> your laptop via WMI receive. If we collect as more as possible events
> from different laptops we can try to abstract format/interface.

Here's a list of all WMI events I could come up with on a Vostro V131. I
also put the generated keycode in parentheses next to each entry.

  * AC power connected (keycode: none)
    Note: No WMI event is generated when AC power is disconnected.

dell_wmi: Received WMI event (06 00 00 00 00 00 01 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00)
dell_wmi: Unknown key 0 pressed

  * Hotkey #2: Dell Support Center (keycode: 0xe06e)

dell_wmi: Received WMI event (02 00 00 00 6e e0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00)
dell_wmi: Unknown key e06e pressed

  * Hotkey #3: Dell Instant Launch Manager (keycode: none)

dell_wmi: Received WMI event (02 00 00 00 25 e0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00)
dell_wmi: Key e025 pressed

  * Fn + F2: Wireless on -> off (keycode: none)

dell_wmi: Received WMI event (06 00 00 00 08 e0 1d 03 2e 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00)
dell_wmi: Key e008 pressed
 
  * Fn + F2: Wireless off -> on (keycode: none)

dell_wmi: Received WMI event (06 00 00 00 08 e0 1d 03 21 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00)
dell_wmi: Key e008 pressed

  * Fn + F4: LCD brightness down (keycode: none)

dell_wmi: Received WMI event (03 00 00 00 05 e0 05 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00)
dell_wmi: Key e005 pressed

  * Fn + F5: LCD brightness up (keycode: none)

dell_wmi: Received WMI event (03 00 00 00 06 e0 07 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00)
dell_wmi: Key e006 pressed

  * Fn + F6: Cycle keyboard backlight brightness (keycode: none)
    Note: Exact same event for all backlight brightness levels.

dell_wmi: Received WMI event (03 00 00 00 0c e0 01 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00)
dell_wmi: Key e00c pressed

  * Fn + F11: Volume down (keycode: 0xe02e)

dell_wmi: Received WMI event (02 00 00 00 2e e0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00)
dell_wmi: Key e02e pressed

  * Fn + F12: Volume up (keycode: 0xe030)

dell_wmi: Received WMI event (02 00 00 00 30 e0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00)
dell_wmi: Key e030 pressed

  * Fn + Mute (keycode: 0xe020)
    Note: Yes, all event data bytes are zeros (sigh).

dell_wmi: Received WMI event (00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00)
dell_wmi: Unknown key 0 pressed

-- 
Best regards,
Michał Kępień

Re: Dell Vostro V131 hotkeys revisited

[Pali Rohár]

[-- Attachment #1: Type: Text/Plain, Size: 9129 bytes --]

On Friday 03 July 2015 16:09:01 Pali Rohár wrote:
> Then in your case, I would need to know format of *all* events which
> can your laptop via WMI receive. If we collect as more as possible
> events from different laptops we can try to abstract
> format/interface.

To have list of events "more" complete, here are dumps from my Latitude E6440:
(dell_new_hk_type is true)

(brightness up)
[41389.833588] dell_wmi: Received WMI event (02 00 10 00 48 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00)
[41389.833591] dell_wmi: Process buffer (02 00 10 00 48 00)
[41389.833592] dell_wmi: Key 48 pressed

(brightness down)
[41393.984812] dell_wmi: Received WMI event (02 00 10 00 50 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00)
[41393.984815] dell_wmi: Process buffer (02 00 10 00 50 00)
[41393.984816] dell_wmi: Key 50 pressed

(toggle keyboard backlight)
[41396.660972] dell_wmi: Received WMI event (02 00 10 00 4d 00 02 00 11 00 e1 01 00 00 00 00 00 00 00 00 00 00 00 00 00 
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00)
[41396.660975] dell_wmi: Process buffer (02 00 10 00 4d 00)
[41396.660977] dell_wmi: Key 4d pressed
[41396.660977] dell_wmi: Process buffer (02 00 11 00 e1 01)
[41396.660978] dell_wmi: Keyboard backlight level changed

(toggle keyboard backlight again)
[41408.872213] dell_wmi: Received WMI event (02 00 10 00 4d 00 02 00 11 00 ea 02 00 00 00 00 00 00 00 00 00 00 00 00 00 
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00)
[41408.872215] dell_wmi: Process buffer (02 00 10 00 4d 00)
[41408.872217] dell_wmi: Key 4d pressed
[41408.872218] dell_wmi: Process buffer (02 00 11 00 ea 02)
[41408.872218] dell_wmi: Keyboard backlight level changed

(again)
[41410.604351] dell_wmi: Received WMI event (02 00 10 00 4d 00 02 00 11 00 eb 02 00 00 00 00 00 00 00 00 00 00 00 00 00 
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00)
[41410.604354] dell_wmi: Process buffer (02 00 10 00 4d 00)
[41410.604355] dell_wmi: Key 4d pressed
[41410.604356] dell_wmi: Process buffer (02 00 11 00 eb 02)
[41410.604357] dell_wmi: Keyboard backlight level changed

(and again)
[41411.313732] dell_wmi: Received WMI event (02 00 10 00 4d 00 02 00 11 00 ec 02 00 00 00 00 00 00 00 00 00 00 00 00 00 
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00)
[41411.313735] dell_wmi: Process buffer (02 00 10 00 4d 00)
[41411.313736] dell_wmi: Key 4d pressed
[41411.313737] dell_wmi: Process buffer (02 00 11 00 ec 02)
[41411.313737] dell_wmi: Keyboard backlight level changed

(and again)
[41412.046983] dell_wmi: Received WMI event (02 00 10 00 4d 00 02 00 11 00 f6 02 00 00 00 00 00 00 00 00 00 00 00 00 00 
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00)
[41412.046986] dell_wmi: Process buffer (02 00 10 00 4d 00)
[41412.046988] dell_wmi: Key 4d pressed
[41412.046989] dell_wmi: Process buffer (02 00 11 00 f6 02)
[41412.046989] dell_wmi: Keyboard backlight level changed

(Fn+Q)
[41471.644347] dell_wmi: Received WMI event (02 00 10 00 10 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00)
[41471.644350] dell_wmi: Process buffer (02 00 10 00 10 00)
[41471.644351] dell_wmi: Key 10 pressed

(Fn+W)
[41482.965057] dell_wmi: Received WMI event (02 00 10 00 11 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00)
[41482.965062] dell_wmi: Process buffer (02 00 10 00 11 00)
[41482.965064] dell_wmi: Key 11 pressed

(Fn+E)
[41485.619605] dell_wmi: Received WMI event (02 00 10 00 12 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00)
[41485.619608] dell_wmi: Process buffer (02 00 10 00 12 00)
[41485.619609] dell_wmi: Key 12 pressed

(Fn+R)
[41486.537823] dell_wmi: Received WMI event (02 00 10 00 13 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00)
[41486.537827] dell_wmi: Process buffer (02 00 10 00 13 00)
[41486.537828] dell_wmi: Key 13 pressed

(Fn+T)
[41487.090608] dell_wmi: Received WMI event (02 00 10 00 14 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00)
[41487.090610] dell_wmi: Process buffer (02 00 10 00 14 00)
[41487.090612] dell_wmi: Key 14 pressed

(Fn+A)
[41491.910608] dell_wmi: Received WMI event (02 00 10 00 1e 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00)
[41491.910611] dell_wmi: Process buffer (02 00 10 00 1e 00)
[41491.910613] dell_wmi: Key 1e pressed

(Fn+S)
[41492.645035] dell_wmi: Received WMI event (02 00 10 00 1f 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00)
[41492.645039] dell_wmi: Process buffer (02 00 10 00 1f 00)
[41492.645040] dell_wmi: Key 1f pressed

(Fn+D)
[41493.132750] dell_wmi: Received WMI event (02 00 10 00 20 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00)
[41493.132753] dell_wmi: Process buffer (02 00 10 00 20 00)
[41493.132755] dell_wmi: Key 20 pressed

(Fn+F)
[41493.624070] dell_wmi: Received WMI event (02 00 10 00 21 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00)
[41493.624073] dell_wmi: Process buffer (02 00 10 00 21 00)
[41493.624074] dell_wmi: Key 21 pressed

(Fn+G)
[41494.603007] dell_wmi: Received WMI event (02 00 10 00 22 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00)
[41494.603010] dell_wmi: Process buffer (02 00 10 00 22 00)
[41494.603011] dell_wmi: Key 22 pressed


(now pressed brightness down key more times, but very very quickly)
[41566.295409] dell_wmi: Received WMI event (03 00 10 00 50 00 50 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00)
[41566.295413] dell_wmi: Process buffer (03 00 10 00 50 00 50 00)
[41566.295415] dell_wmi: Key 50 pressed
[41566.295429] dell_wmi: Key 50 pressed

[41566.418593] dell_wmi: Received WMI event (02 00 10 00 50 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00)
[41566.418595] dell_wmi: Process buffer (02 00 10 00 50 00)
[41566.418597] dell_wmi: Key 50 pressed

[41566.448279] dell_wmi: Received WMI event (00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00)

(so sometimes double key is received in one event! and sometimes empty event is received)


(and now via /sys dell-laptop.ko I changed keyboard backlight, very very quickly all 5 levels)
[41602.300604] dell_wmi: Received WMI event (06 00 11 00 f6 02 ec 02 eb 02 ea 02 e1 01 00 00 00 00 00 00 00 00 00 00 00 
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00)
[41602.300607] dell_wmi: Process buffer (06 00 11 00 f6 02 ec 02 eb 02 ea 02 e1 01)
[41602.300608] dell_wmi: Keyboard backlight level changed
[41602.300608] dell_wmi: Keyboard backlight level changed
[41602.300609] dell_wmi: Keyboard backlight level changed
[41602.300609] dell_wmi: Keyboard backlight level changed
[41602.300610] dell_wmi: Keyboard backlight level changed

(and all five events were received in one WMI buffer)


So what is important: Dell BIOS send via one WMI buffer more events and also with different types!

-- 
Pali Rohár
pali.rohar@gmail.com

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

Re: Dell Vostro V131 hotkeys revisited

[Pali Rohár]

On Friday 03 July 2015 20:22:22 Gabriele Mazzotta wrote:
> On Friday 03 July 2015 16:14:54 Pali Rohár wrote:
> > On Friday 03 July 2015 16:09:01 Pali Rohár wrote:
> > > Yes, "vendor does not say anything" is also what could happen...
> > > 
> > > Then in your case, I would need to know format of *all* events which can
> > > your laptop via WMI receive. If we collect as more as possible events
> > > from different laptops we can try to abstract format/interface.
> > > 
> > 
> > CCing Gabriele, can you please provide buffers of all possible WMI
> > events which can be received on your dell machine via dell-wmi.ko?
> > (just enable pr_debug() in dell-wmi.c)
> 
> Hi,
> 
> here below there's what I could get from my XPS13 9333.
> 
> [ 6115.412615] wifi - disable/enable
> [ 6115.710966] dell_wmi: Received WMI event (06 00 00 00 08 e0 1d 03 0a 00 00 01 01 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00)
> [ 6115.710972] dell_wmi: Key e008 pressed
> [ 6116.766483] dell_wmi: Received WMI event (06 00 00 00 08 e0 1d 03 09 00 00 01 01 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00)
> [ 6116.766483] dell_wmi: Key e008 pressed
> [ 6121.555618] battery health
> [ 6122.093304] dell_wmi: Received WMI event (02 00 00 00 07 e0 1d 03 08 00 00 01 01 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00)
> [ 6122.093313] dell_wmi: Key e007 pressed
> [ 6128.550329] brightness down
> [ 6129.739787] dell_wmi: Received WMI event (03 00 00 00 05 e0 0e 00 08 00 00 01 01 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00)
> [ 6129.739799] dell_wmi: Key e005 pressed
> [ 6134.469814] brightness up
> [ 6134.853151] dell_wmi: Received WMI event (03 00 00 00 06 e0 0f 00 08 00 00 01 01 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00)
> [ 6134.853157] dell_wmi: Key e006 pressed
> [ 6143.153178] keyboard illumination - level 2 1 0
> [ 6143.056422] dell_wmi: Received WMI event (03 00 00 00 0c e0 02 00 09 00 00 01 01 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00)
> [ 6143.056427] dell_wmi: Key e00c pressed
> [ 6143.768556] dell_wmi: Received WMI event (03 00 00 00 0c e0 01 00 09 00 00 01 01 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00)
> [ 6143.768566] dell_wmi: Key e00c pressed
> [ 6144.340347] dell_wmi: Received WMI event (03 00 00 00 0c e0 00 00 09 00 00 01 01 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00)
> [ 6144.340357] dell_wmi: Key e00c pressed
> [ 6176.922331] volume down
> [ 6177.325737] dell_wmi: Received WMI event (02 00 00 00 2e e0 01 00 08 00 00 01 01 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00)
> [ 6177.325746] dell_wmi: Key e02e pressed
> [ 6182.892971] volume up
> [ 6183.240709] dell_wmi: Received WMI event (02 00 00 00 30 e0 01 00 08 00 00 01 01 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00)
> [ 6183.240715] dell_wmi: Key e030 pressed
> [ 6188.932940] mute
> [ 6190.453967] dell_wmi: Received WMI event (02 00 00 00 f7 e0 01 00 08 00 00 01 01 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00)
> [ 6190.453975] dell_wmi: Key e0f7 pressed

Hi!

I have looked at your DSDT table which you sent me months ago and I see
that your ACPI code does not clear WMI buffer before sending it to OS
driver (buffer named INFO, and u16* values in INF0, INF1, ... INF7).

And I see that your ACPI code always send one "message" in WMI buffer,
not like on my E6440 when I receive one "message" for keypress event and
appended "message" that keyboard backlight was changed.

Because your ACPI code does not clear buffer before filling it, it is
impossible to parse correctly on both machines (my and your)... :-(

But I see that on your machine ACPI set "WMI Interface Version" to 0x0.
On my machine and Michał's too it is set to 0x1. (See ACPI-WMI%20.pdf)
So maybe this information is important?

Anyway your ACPI DSDT code contains all possible WMI events (for your
machine) as they are generated by ACPI and not by EC/firmware...

-- 
Pali Rohár
pali.rohar@gmail.com

Re: Dell Vostro V131 hotkeys revisited

[Pali Rohár]

[-- Attachment #1: Type: Text/Plain, Size: 900 bytes --]

And I forgot to send these two events:

(calling ifconfig eth0 down)
[44634.098954] dell_wmi: Received WMI event (02 00 00 00 44 e0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00)
[44634.098957] dell_wmi: Process buffer (02 00 00 00 44 e0)
[44634.098958] dell_wmi: NIC Link is Down

(calling ifconfig eth0 up)
[44639.722292] dell_wmi: Received WMI event (02 00 00 00 43 e0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00)
[44639.722296] dell_wmi: Process buffer (02 00 00 00 43 e0)
[44639.722296] dell_wmi: NIC Link is Up

Important is that type of event is 0x00 like old hotkey event...

-- 
Pali Rohár
pali.rohar@gmail.com

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

Re: Dell Vostro V131 hotkeys revisited

[Gabriele Mazzotta]

On Saturday 04 July 2015 21:41:51 Pali Rohár wrote:
> On Friday 03 July 2015 20:22:22 Gabriele Mazzotta wrote:
> > On Friday 03 July 2015 16:14:54 Pali Rohár wrote:
> > > On Friday 03 July 2015 16:09:01 Pali Rohár wrote:
> > > > Yes, "vendor does not say anything" is also what could happen...
> > > > 
> > > > Then in your case, I would need to know format of *all* events which can
> > > > your laptop via WMI receive. If we collect as more as possible events
> > > > from different laptops we can try to abstract format/interface.
> > > > 
> > > 
> > > CCing Gabriele, can you please provide buffers of all possible WMI
> > > events which can be received on your dell machine via dell-wmi.ko?
> > > (just enable pr_debug() in dell-wmi.c)
> > 
> > Hi,
> > 
> > here below there's what I could get from my XPS13 9333.
> > 
> > [ 6115.412615] wifi - disable/enable
> > [ 6115.710966] dell_wmi: Received WMI event (06 00 00 00 08 e0 1d 03 0a 00 00 01 01 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00)
> > [ 6115.710972] dell_wmi: Key e008 pressed
> > [ 6116.766483] dell_wmi: Received WMI event (06 00 00 00 08 e0 1d 03 09 00 00 01 01 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00)
> > [ 6116.766483] dell_wmi: Key e008 pressed
> > [ 6121.555618] battery health
> > [ 6122.093304] dell_wmi: Received WMI event (02 00 00 00 07 e0 1d 03 08 00 00 01 01 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00)
> > [ 6122.093313] dell_wmi: Key e007 pressed
> > [ 6128.550329] brightness down
> > [ 6129.739787] dell_wmi: Received WMI event (03 00 00 00 05 e0 0e 00 08 00 00 01 01 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00)
> > [ 6129.739799] dell_wmi: Key e005 pressed
> > [ 6134.469814] brightness up
> > [ 6134.853151] dell_wmi: Received WMI event (03 00 00 00 06 e0 0f 00 08 00 00 01 01 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00)
> > [ 6134.853157] dell_wmi: Key e006 pressed
> > [ 6143.153178] keyboard illumination - level 2 1 0
> > [ 6143.056422] dell_wmi: Received WMI event (03 00 00 00 0c e0 02 00 09 00 00 01 01 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00)
> > [ 6143.056427] dell_wmi: Key e00c pressed
> > [ 6143.768556] dell_wmi: Received WMI event (03 00 00 00 0c e0 01 00 09 00 00 01 01 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00)
> > [ 6143.768566] dell_wmi: Key e00c pressed
> > [ 6144.340347] dell_wmi: Received WMI event (03 00 00 00 0c e0 00 00 09 00 00 01 01 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00)
> > [ 6144.340357] dell_wmi: Key e00c pressed
> > [ 6176.922331] volume down
> > [ 6177.325737] dell_wmi: Received WMI event (02 00 00 00 2e e0 01 00 08 00 00 01 01 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00)
> > [ 6177.325746] dell_wmi: Key e02e pressed
> > [ 6182.892971] volume up
> > [ 6183.240709] dell_wmi: Received WMI event (02 00 00 00 30 e0 01 00 08 00 00 01 01 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00)
> > [ 6183.240715] dell_wmi: Key e030 pressed
> > [ 6188.932940] mute
> > [ 6190.453967] dell_wmi: Received WMI event (02 00 00 00 f7 e0 01 00 08 00 00 01 01 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00)
> > [ 6190.453975] dell_wmi: Key e0f7 pressed
> 
> Hi!
> 
> I have looked at your DSDT table which you sent me months ago and I see
> that your ACPI code does not clear WMI buffer before sending it to OS
> driver (buffer named INFO, and u16* values in INF0, INF1, ... INF7).
> 
> And I see that your ACPI code always send one "message" in WMI buffer,
> not like on my E6440 when I receive one "message" for keypress event and
> appended "message" that keyboard backlight was changed.
>
> Because your ACPI code does not clear buffer before filling it, it is
> impossible to parse correctly on both machines (my and your)... :-(

I guess this is because the size of the meaningful data is stored at
the beginning of the buffer (INF0, the first 2 bytes in the output here
above) and so there's no need to clear it entirely.

> But I see that on your machine ACPI set "WMI Interface Version" to 0x0.
> On my machine and Michał's too it is set to 0x1. (See ACPI-WMI%20.pdf)
> So maybe this information is important?
> 
> Anyway your ACPI DSDT code contains all possible WMI events (for your
> machine) as they are generated by ACPI and not by EC/firmware...

Yes, there are some events that I don't even know how to trigger.

Here an additional event that I get from time to time:
[20052.604628] dell_wmi: Received WMI event (02 00 00 00 0e e0 0f 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00)
[20052.604634] dell_wmi: Unknown key e00e pressed

According to my acpi table, this has to do with battery related stuff.
On a side note, I guess this event can be added to the "ignore list" of
the legacy keymap.

Anyway, I think that reading the acpi dump of my laptop is easier
than collecting and reading these logs. However, things are implemented
in a different way (probably this is the difference between "WMI
Interface Version" 0 and 1), so I don't know how helpful it can be.

In any case, here the acpidump in case someone is interested:
https://bugzilla.kernel.org/attachment.cgi?id=178381

Re: Dell Vostro V131 hotkeys revisited

[Pali Rohár]

[-- Attachment #1: Type: Text/Plain, Size: 589 bytes --]

On Friday 03 July 2015 08:52:44 Michał Kępień wrote:
> > Can you write which WMI call needs to be called?
> 
> Technically, one needs to call method DoBFn (method ID = 1) using
> GUID A80593CE-A997-11DA-B012-B622A1EF5492. Though if you look at the
> ACPI method this GUID maps to (WMBA), you'll notice that the first
> two arguments passed to it (instance number and method ID) are
> simply ignored and the only one that matters is the buffer passed
> (third argument).
> 

OK, and can you write what is needed to fill into buffer?

-- 
Pali Rohár
pali.rohar@gmail.com

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

Re: Dell Vostro V131 hotkeys revisited

[Michał Kępień]

> OK, and can you write what is needed to fill into buffer?

Here is the critical part of a working patch I prepared for
dell-laptop.c:

    get_buffer();
    buffer->input[0] = 0x10000;
    buffer->input[1] = 0x51534554;
    buffer->input[3] = 0x1;
    dell_send_request(buffer, 17, 3);
    ret = buffer->output[0];
    release_buffer();

-- 
Best regards,
Michał Kępień

Re: Dell Vostro V131 hotkeys revisited

[Mario Limonciello]

On 07/03/2015 02:48 AM, Pali Rohár wrote:
> On Friday 03 July 2015 08:52:44 Michał Kępień wrote:
>>> Can you write which WMI call needs to be called?
>> Technically, one needs to call method DoBFn (method ID = 1) using GUID
>> A80593CE-A997-11DA-B012-B622A1EF5492. Though if you look at the ACPI
>> method this GUID maps to (WMBA), you'll notice that the first two
>> arguments passed to it (instance number and method ID) are simply
>> ignored and the only one that matters is the buffer passed (third
>> argument).
>>
>>> Last time when I looked into dell-led.c code it called some WMI
>>> functions which are just re-implementation of SMI based SMBIOS
>>> functions. From information which I have that is just WMI interface for
>>> dell SMBIOS one.
>>>
>>> I already asked Alex and other people for official ACPI/WMI Dell
>>> documentation, so we would be able to solve these hotkey problems once
>>> and for all, but I did not get anything yet.
>>>
>>> What I found on internet is just this one out-of-dated documentation:
>>> http://vpsservice1.sampo.com.tw/sampo_update/document/jimmy/ACPI-WMI%20.pdf
>>>
>>> I would suggest you to read it (it is not long) to see Dell WMI methods
>>> are just ACPI "wrapper" around Dell SMBIOS (dcdbas.ko driver) used by
>>> dell-laptop.ko.
>> Great, thanks. I'll look into it.
>>  
>>>>  2) Pressing hotkey #3 on a Dell Vostro V131 generates WMI event
>>>> 0xe025, but no keycode. Apparently, Dell XPS L502X generates the
>>>> same WMI event for a hotkey which also generates a keycode [1].
>>>> What's the best way to solve this conflict?
>>>>
>>>> [1] commit f1566f0: "dell-wmi: Add keys for Dell XPS L502X"
>>> Look at dell-wmi.c source code. Which event format is that? New one
>>> (partially described in above PDF document) when dell_new_hk_type is
>>> true? Or old one?
>> Vostro V131 is using the legacy keymap.
>>
>>> Can you please enable pr_debug() in dell-wmi.c and send dmesg output
>>> from dell-wmi.ko (specially dell_wmi_notify)?
>> Here's what appears in dmesg after pressing hotkey #3:
>>
>> ------------------------------------------------------------------------
>> dell_wmi: Received WMI event (02 00 00 00 25 e0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00)
>> dell_wmi: Key e025 pressed
>> wmi: DEBUG Event GUID: 9DBB5994-A997-11DA-B012-B622A1EF5492
>> ------------------------------------------------------------------------
>>
> It looks like above buffer has format of *new* event (0002 - length of
> event, 0000 - type of event, e025 - data). But when using legacy keymap
> then dell-wmi.c parse events with old format (which means type=0000 is
> dropped and data=e025 is translated to some key).
>
> This is even harder as I thought. Looks like big mess and now I would
> say, without documentation for Dell WMI events we are not able to fix
> this correctly without breaking other laptops...
>
> ========================================================================
>
> CCing kernel Dell developers, can you provide Dell WMI documentation for
> events and hotkeys? We have problems with enabling events for additional
> buttons/keys on Dell laptops and also parsing WMI events which BIOS/ACPI
> generates and send to kernel. Please, I really do not know how to how we
> can fix these "hotkey/events" problems.
>
> Something like this document, but updated for new laptops:
> http://vpsservice1.sampo.com.tw/sampo_update/document/jimmy/ACPI-WMI%20.pdf
>
> Thanks!
>
I'm unsure how that document ended up on the web, it shouldn't have been
released in verbose form like that, but aside from that the BIOS
ACPI-WMI interface has not changed since that document was created. 
There are some other BIOS specs that do refer to a few other things I
should mention though.

You added a patch to look at multiple events in one buffer in November. 
I didn't see anything checking for the type, so here's the detail you
missed:
Word 0 is the length (as you mentioned)
Word 1 is the type.  It can be either :
* 0x0000 meaning one hot key is pressed or an event occured. 
* 0x000F meaning a sequence of hotkeys are pressed.

e025 is supposed to be translated into "Dell Instant Launch".  This key
is a bit special because the EC can be configured to send programmed
scan codes.  Some other documentation that isn't part of the WMI
documentation does describe more clearly how you can query what is
supported. 
Query key press simulation capability:
class 4, selector 11.
Arg1=0x40.
Res1 value of 0, means success
Res1 value of -1, error
Res1 value of -2, not supported
Res2 bit0 if set means that the EC can send scan codes when Instant
Launch is pressed.

What's probably happening is that  the earlier system doesn't yet
support key press simulation.  You can add a check for it with the above.

Now as for actually simulating a keypress, it can be programmed using
the following calling interface (on receiving the e025 WMI notification).
To actually simulate the keypress:
Arg1=0x41
Arg2 Byte [1:0]: Scan code to simulate
Byte [3:2]
* Bit0 - L Alt
* Bit1 - R Alt
* Bit2 - L Ctrl
* Bit3 - R Ctrl
* Bit4 - L Shift
* Bit5 - R shift
* Bit6 - L Win
* Bit7 - R Win
* Bit8 - Fn key

Re: Dell Vostro V131 hotkeys revisited

[Pali Rohár]

On Tuesday 07 July 2015 13:36:07 Mario Limonciello wrote:
> 
> 
> On 07/03/2015 02:48 AM, Pali Rohár wrote:
> > On Friday 03 July 2015 08:52:44 Michał Kępień wrote:
> >>> Can you write which WMI call needs to be called?
> >> Technically, one needs to call method DoBFn (method ID = 1) using GUID
> >> A80593CE-A997-11DA-B012-B622A1EF5492. Though if you look at the ACPI
> >> method this GUID maps to (WMBA), you'll notice that the first two
> >> arguments passed to it (instance number and method ID) are simply
> >> ignored and the only one that matters is the buffer passed (third
> >> argument).
> >>
> >>> Last time when I looked into dell-led.c code it called some WMI
> >>> functions which are just re-implementation of SMI based SMBIOS
> >>> functions. From information which I have that is just WMI interface for
> >>> dell SMBIOS one.
> >>>
> >>> I already asked Alex and other people for official ACPI/WMI Dell
> >>> documentation, so we would be able to solve these hotkey problems once
> >>> and for all, but I did not get anything yet.
> >>>
> >>> What I found on internet is just this one out-of-dated documentation:
> >>> http://vpsservice1.sampo.com.tw/sampo_update/document/jimmy/ACPI-WMI%20.pdf
> >>>
> >>> I would suggest you to read it (it is not long) to see Dell WMI methods
> >>> are just ACPI "wrapper" around Dell SMBIOS (dcdbas.ko driver) used by
> >>> dell-laptop.ko.
> >> Great, thanks. I'll look into it.
> >>  
> >>>>  2) Pressing hotkey #3 on a Dell Vostro V131 generates WMI event
> >>>> 0xe025, but no keycode. Apparently, Dell XPS L502X generates the
> >>>> same WMI event for a hotkey which also generates a keycode [1].
> >>>> What's the best way to solve this conflict?
> >>>>
> >>>> [1] commit f1566f0: "dell-wmi: Add keys for Dell XPS L502X"
> >>> Look at dell-wmi.c source code. Which event format is that? New one
> >>> (partially described in above PDF document) when dell_new_hk_type is
> >>> true? Or old one?
> >> Vostro V131 is using the legacy keymap.
> >>
> >>> Can you please enable pr_debug() in dell-wmi.c and send dmesg output
> >>> from dell-wmi.ko (specially dell_wmi_notify)?
> >> Here's what appears in dmesg after pressing hotkey #3:
> >>
> >> ------------------------------------------------------------------------
> >> dell_wmi: Received WMI event (02 00 00 00 25 e0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00)
> >> dell_wmi: Key e025 pressed
> >> wmi: DEBUG Event GUID: 9DBB5994-A997-11DA-B012-B622A1EF5492
> >> ------------------------------------------------------------------------
> >>
> > It looks like above buffer has format of *new* event (0002 - length of
> > event, 0000 - type of event, e025 - data). But when using legacy keymap
> > then dell-wmi.c parse events with old format (which means type=0000 is
> > dropped and data=e025 is translated to some key).
> >
> > This is even harder as I thought. Looks like big mess and now I would
> > say, without documentation for Dell WMI events we are not able to fix
> > this correctly without breaking other laptops...
> >
> > ========================================================================
> >
> > CCing kernel Dell developers, can you provide Dell WMI documentation for
> > events and hotkeys? We have problems with enabling events for additional
> > buttons/keys on Dell laptops and also parsing WMI events which BIOS/ACPI
> > generates and send to kernel. Please, I really do not know how to how we
> > can fix these "hotkey/events" problems.
> >
> > Something like this document, but updated for new laptops:
> > http://vpsservice1.sampo.com.tw/sampo_update/document/jimmy/ACPI-WMI%20.pdf
> >
> > Thanks!
> >
> I'm unsure how that document ended up on the web, it shouldn't have been
> released in verbose form like that, but aside from that the BIOS
> ACPI-WMI interface has not changed since that document was created. 
> There are some other BIOS specs that do refer to a few other things I
> should mention though.
> 

Hi Mario! I'm happy that you provided some response to us!

I just used search tools and I tried to find some information about
DELL, ACPI and WMI. And I come across that PDF document on internet
which provided me some information useful how events can be received.

> You added a patch to look at multiple events in one buffer in November. 
> I didn't see anything checking for the type

In my patch from Nov 2014 (83fc44c32) there are checks for types. You
can look into dell-wmi.c at line "switch (buffer_entry[1])".

> so here's the detail you missed:
> Word 0 is the length (as you mentioned)
> Word 1 is the type.  It can be either :
> * 0x0000 meaning one hot key is pressed or an event occured. 
> * 0x000F meaning a sequence of hotkeys are pressed.
> 

And what are types 0x0010 and 0x0011? As you can see in source code and
sent logs to LKML key presses and events are sent also with these two
types.

Is there somewhere list of all events and key presses which can BIOS/WMI
send to running system?

And in that PDF document is specified to query for BIOS WMI Descriptor
at first (UUID 8D9DDCBC-A997-11DA-B012-B622A1EF5492). And it returns
also "WMI Interface Version". From ACPI DSDT dumps we already see that
version is either 0 or 1.

Is there some difference between these two versions (0 and 1)? Was
something changed for receiving events or something else?

And should Linux dell-wmi.c driver check that "BIOS WMI Descriptor"
before doing something?

> e025 is supposed to be translated into "Dell Instant Launch".  This key
> is a bit special because the EC can be configured to send programmed
> scan codes.  Some other documentation that isn't part of the WMI
> documentation does describe more clearly how you can query what is
> supported. 
> Query key press simulation capability:
> class 4, selector 11.
> Arg1=0x40.
> Res1 value of 0, means success
> Res1 value of -1, error
> Res1 value of -2, not supported
> Res2 bit0 if set means that the EC can send scan codes when Instant
> Launch is pressed.
> 

Hmm... class=4 and selector=11? Is not this id for keyboard
illuminations settings? It is used in smbios-keyboard-ctl tool on:
http://linux.dell.com/cgi-bin/cgit.cgi/libsmbios.git/tree/src/bin/smbios-keyboard-ctl#n667

I tried to send smbios request with:

class=4
selector=11
arg1=64

(0x40 hex = 64 dec)

And it disabled keyboard backlight on my E6440 machine, then it set
keyboard backlight inactivity timeout to 5 seconds and call returned:

Res1=-2

So this smbios query is not safe :-( as it set some keyboard backlight
default values and return "error not supported".

So are you sure that 4, 11, 64 is call correct? Or is above side-effect
of setting keyboard backlight values expected?

> What's probably happening is that  the earlier system doesn't yet
> support key press simulation.  You can add a check for it with the above.
> 
> Now as for actually simulating a keypress, it can be programmed using
> the following calling interface (on receiving the e025 WMI notification).
> To actually simulate the keypress:
> Arg1=0x41
> Arg2 Byte [1:0]: Scan code to simulate
> Byte [3:2]
> * Bit0 - L Alt
> * Bit1 - R Alt
> * Bit2 - L Ctrl
> * Bit3 - R Ctrl
> * Bit4 - L Shift
> * Bit5 - R shift
> * Bit6 - L Win
> * Bit7 - R Win
> * Bit8 - Fn key
> 
> 

Hm... what does it means if some bit in Byte [3:2] is set together with
some scan code in Byte [1:0]?


Anyway Michał Kępień already decoded from ACPI DSDT code that SBIOS WMI
call 17, 3 needs to be send to enable receiving events for e025 key. See
email: http://www.spinics.net/lists/platform-driver-x86/msg07195.htmls

After that on libsmbios-devel@lists.us.dell.com ML we got answer from
Srinivas_G_Gowda what SMBIOS call 17, 3 is doing, see email:
http://lists.us.dell.com/pipermail/libsmbios-devel/2015-July/000612.html

So I believe code like this:

    get_buffer();
    buffer->input[0] = 0x10000;
    buffer->input[1] = 0x51534554;
    buffer->input[3] = 0x1;
    dell_send_request(buffer, 17, 3);
    ret = buffer->output[0];
    release_buffer();

Could be OK for enabling e025 event. Or not? And if yes, how to detect
if we need to call this SMBIOS 17, 3 function?

-- 
Pali Rohár
pali.rohar@gmail.com

Re: Dell Vostro V131 hotkeys revisited

[Michał Kępień]

> I tried to send smbios request with:
> 
> class=4
> selector=11
> arg1=64
> 
> (0x40 hex = 64 dec)
> 
> And it disabled keyboard backlight on my E6440 machine, then it set
> keyboard backlight inactivity timeout to 5 seconds and call returned:
> 
> Res1=-2
> 
> So this smbios query is not safe :-( as it set some keyboard backlight
> default values and return "error not supported".

What a shame. My Vostro V131 returns 0 in both Res1 and Res2, as
anticipated, without the ill effects you described.

> So are you sure that 4, 11, 64 is call correct? Or is above side-effect
> of setting keyboard backlight values expected?

I second these questions. And if the side effects Pali wrote about are
not expected, perhaps there is a well-known subset of devices this call
can be whitelisted or blacklisted on?

-- 
Best regards,
Michał Kępień

Re: Dell Vostro V131 hotkeys revisited

[Michał Kępień]

Mario,

Thank you very much for the information provided.

> Now as for actually simulating a keypress, it can be programmed using
> the following calling interface (on receiving the e025 WMI notification).
> To actually simulate the keypress:
> Arg1=0x41
> Arg2 Byte [1:0]: Scan code to simulate
> Byte [3:2]
> * Bit0 - L Alt
> * Bit1 - R Alt
> * Bit2 - L Ctrl
> * Bit3 - R Ctrl
> * Bit4 - L Shift
> * Bit5 - R shift
> * Bit6 - L Win
> * Bit7 - R Win
> * Bit8 - Fn key

And is it possible to disable keypress simulation on systems that have
that capability?

My understanding is that all hardware equipped with an Instant Launch
button is capable of generating a WMI event upon its press, but not all
models can generate a keypress at the same time, correct? If that's the
case, then the arguably cleanest solution would be to change the keymap
entry for event 0xe025 in dell-wmi.c to KE_KEY and ensure (probably in
dell-laptop.c) no i8042 interrupt is raised when the Instant Launch
button is pressed. Though that would still leave us with the question of
how to determine (ideally without side effects) whether a given model
needs disabling keypress simulation. I imagine the pseudocode would be
like:

    if (ec_can_simulate_keypresses)
        disable_keypress_simulation();
    else
        enable_wmi_event_generation();

If disabling keypress simulation is not possible, dell-wmi.c has to
somehow determine whether a 0xe025 WMI event should be ignored or not.

Am I making any sense here?

-- 
Best regards,
Michał Kępień

Re: Dell Vostro V131 hotkeys revisited

[Michał Kępień]

> > Now as for actually simulating a keypress, it can be programmed using
> > the following calling interface (on receiving the e025 WMI notification).
> > To actually simulate the keypress:
> > Arg1=0x41
> > Arg2 Byte [1:0]: Scan code to simulate
> > Byte [3:2]
> > * Bit0 - L Alt
> > * Bit1 - R Alt
> > * Bit2 - L Ctrl
> > * Bit3 - R Ctrl
> > * Bit4 - L Shift
> > * Bit5 - R shift
> > * Bit6 - L Win
> > * Bit7 - R Win
> > * Bit8 - Fn key
> 
> And is it possible to disable keypress simulation on systems that have
> that capability?
> 
> My understanding is that all hardware equipped with an Instant Launch
> button is capable of generating a WMI event upon its press, but not all
> models can generate a keypress at the same time, correct? If that's the
> case, then the arguably cleanest solution would be to change the keymap
> entry for event 0xe025 in dell-wmi.c to KE_KEY and ensure (probably in
> dell-laptop.c) no i8042 interrupt is raised when the Instant Launch
> button is pressed. Though that would still leave us with the question of
> how to determine (ideally without side effects) whether a given model
> needs disabling keypress simulation. I imagine the pseudocode would be
> like:
> 
>     if (ec_can_simulate_keypresses)
>         disable_keypress_simulation();
>     else
>         enable_wmi_event_generation();
> 
> If disabling keypress simulation is not possible, dell-wmi.c has to
> somehow determine whether a 0xe025 WMI event should be ignored or not.
> 
> Am I making any sense here?

Mario,

Just pinging; any chance you could comment on these issues? Thanks,

-- 
Best regards,
Michał Kępień

Re: Dell Vostro V131 hotkeys revisited

[Michał Kępień]

> Yes, "vendor does not say anything" is also what could happen...
> 
> Then in your case, I would need to know format of *all* events which can
> your laptop via WMI receive. If we collect as more as possible events
> from different laptops we can try to abstract format/interface.

Darek Stojaczyk reported [1] that his Dell Inspiron M5110 (Q15R) needs
the same special SMI as the Vostro V131 in order for the Instant Launch
hotkey to be reported using WMI. He also prepared a WMI event listing
for his machine [2]. It's worth noting that in his case the Instant
Launch hotkey produces yet another WMI event, 0xe029, which isn't
currently handled by dell-wmi.c.

[1] https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1205791/comments/12
[2] https://launchpadlibrarian.net/212841338/M5110_wmi_events.txt

-- 
Best regards,
Michał Kępień

Re: Dell Vostro V131 hotkeys revisited

[Michał Kępień]

> > > Now as for actually simulating a keypress, it can be programmed using
> > > the following calling interface (on receiving the e025 WMI notification).
> > > To actually simulate the keypress:
> > > Arg1=0x41
> > > Arg2 Byte [1:0]: Scan code to simulate
> > > Byte [3:2]
> > > * Bit0 - L Alt
> > > * Bit1 - R Alt
> > > * Bit2 - L Ctrl
> > > * Bit3 - R Ctrl
> > > * Bit4 - L Shift
> > > * Bit5 - R shift
> > > * Bit6 - L Win
> > > * Bit7 - R Win
> > > * Bit8 - Fn key
> > 
> > And is it possible to disable keypress simulation on systems that have
> > that capability?
> > 
> > My understanding is that all hardware equipped with an Instant Launch
> > button is capable of generating a WMI event upon its press, but not all
> > models can generate a keypress at the same time, correct? If that's the
> > case, then the arguably cleanest solution would be to change the keymap
> > entry for event 0xe025 in dell-wmi.c to KE_KEY and ensure (probably in
> > dell-laptop.c) no i8042 interrupt is raised when the Instant Launch
> > button is pressed. Though that would still leave us with the question of
> > how to determine (ideally without side effects) whether a given model
> > needs disabling keypress simulation. I imagine the pseudocode would be
> > like:
> > 
> >     if (ec_can_simulate_keypresses)
> >         disable_keypress_simulation();
> >     else
> >         enable_wmi_event_generation();
> > 
> > If disabling keypress simulation is not possible, dell-wmi.c has to
> > somehow determine whether a 0xe025 WMI event should be ignored or not.
> > 
> > Am I making any sense here?

As the holiday season is coming to an end, I'm taking my last shot at
reviving this thread. Could anyone please tell us:

  * Is there a way to determine whether the EC is capable of simulating
    keypresses without the side effects that the SMBIOS call 4, 11 with
    argument 64 causes on certain hardware (e.g. disabling keyboard
    backlight on an E6440)? Or is there perhaps a well-defined list of
    machines that SMBIOS call is (un)safe on?

  * Is it possible to disable keypress simulation on machines on which
    the EC supports it? If so, how would one do that?

Thanks!

-- 
Best regards,
Michał Kępień

Re: Dell Vostro V131 hotkeys revisited

[Darren Hart]

On Mon, Aug 31, 2015 at 11:51:07AM +0200, Michał Kępień wrote:
> > > > Now as for actually simulating a keypress, it can be programmed using
> > > > the following calling interface (on receiving the e025 WMI notification).
> > > > To actually simulate the keypress:
> > > > Arg1=0x41
> > > > Arg2 Byte [1:0]: Scan code to simulate
> > > > Byte [3:2]
> > > > * Bit0 - L Alt
> > > > * Bit1 - R Alt
> > > > * Bit2 - L Ctrl
> > > > * Bit3 - R Ctrl
> > > > * Bit4 - L Shift
> > > > * Bit5 - R shift
> > > > * Bit6 - L Win
> > > > * Bit7 - R Win
> > > > * Bit8 - Fn key
> > > 
> > > And is it possible to disable keypress simulation on systems that have
> > > that capability?
> > > 
> > > My understanding is that all hardware equipped with an Instant Launch
> > > button is capable of generating a WMI event upon its press, but not all
> > > models can generate a keypress at the same time, correct? If that's the
> > > case, then the arguably cleanest solution would be to change the keymap
> > > entry for event 0xe025 in dell-wmi.c to KE_KEY and ensure (probably in
> > > dell-laptop.c) no i8042 interrupt is raised when the Instant Launch
> > > button is pressed. Though that would still leave us with the question of
> > > how to determine (ideally without side effects) whether a given model
> > > needs disabling keypress simulation. I imagine the pseudocode would be
> > > like:
> > > 
> > >     if (ec_can_simulate_keypresses)
> > >         disable_keypress_simulation();
> > >     else
> > >         enable_wmi_event_generation();
> > > 
> > > If disabling keypress simulation is not possible, dell-wmi.c has to
> > > somehow determine whether a 0xe025 WMI event should be ignored or not.
> > > 
> > > Am I making any sense here?
> 
> As the holiday season is coming to an end, I'm taking my last shot at
> reviving this thread. Could anyone please tell us:
> 
>   * Is there a way to determine whether the EC is capable of simulating
>     keypresses without the side effects that the SMBIOS call 4, 11 with
>     argument 64 causes on certain hardware (e.g. disabling keyboard
>     backlight on an E6440)? Or is there perhaps a well-defined list of
>     machines that SMBIOS call is (un)safe on?
> 
>   * Is it possible to disable keypress simulation on machines on which
>     the EC supports it? If so, how would one do that?

I certainly don't know myself, not what you were hoping to hear back I'm sure.
Some of that requires documentation, which I don't know if we have. Does anyone
from Dell on Cc have documentation they can share to help answer these
questions?

-- 
Darren Hart
Intel Open Source Technology Center

Re: Dell Vostro V131 hotkeys revisited

[Michał Kępień]

For those of you playing along at home, I have some news (mostly bad,
I'm afraid).

TL;DR: I don't believe there is any way of getting Vostro V131 fully
supported by the kernel without breaking stuff that already works, so I
suggest a slightly different approach (see the last paragraph).

I have recently noticed that backlight control on a Vostro V131 running
Linux has some glitches as well.  Before WMI gets enabled, pressing
either the "brightness down" (Fn+F4) or the "brightness up" (Fn+F5) key
causes two "presses" of the respective keycode (KEY_BRIGHTNESSUP or
KEY_BRIGHTNESSDOWN) to be reported.  This itself seems buggy to me, but
whatever.  The worse part is that there is an irritating flickering
effect as well [1].  But if that wasn't enough, it gets even worse after
issuing the WMI-enabling SMI call, because the keycode simulated by ACPI
gets "shifted" by one event while the WMI events are reported correctly.
Consider the following sequence of key presses:

Key pressed     Keycode reported        WMI event reported 
-----------     ----------------        ------------------
Fn+F4           (none)                  0xe005
Fn+F4           KEY_BRIGHTNESSDOWN      0xe005
Fn+F5           KEY_BRIGHTNESSDOWN      0xe006
Fn+F5           KEY_BRIGHTNESSUP        0xe006
Fn+Mute         KEY_BRIGHTNESSUP        0x0000
Fn+Mute         (none)                  0x0000

I determined that both brightness flickering and incorrect keycode
reporting are caused (the latter indirectly) by ACPI method CESM (and
later I found out that [1] agrees in regard to flickering).  While I
haven't found the source of the "shifting" bug (and I am not willing to,
thanks, I'd rather cut myself with a butter knife), the basic tests I've
performed indicate that simply overriding that CESM method with a no-op
does the job, if combined with correct kernel parameters.

However, all this nonsense makes me come to the conclusion that any
attempts to fix it by only changing existing kernel code are futile [2].
Thus, to avoid breaking other Dell devices which already work fine with
Linux, I devised a "solution" using libsmbios (which in turn uses
dcdbas) and ACPI method overriding which seems to work fine.  It still
needs a kernel patch which enables reporting the 0xe025 event as a
keypress (this event is currently associated with a KE_IGNORE sparse
keymap entry).  I prepared a patch which adds a module parameter to
dell-wmi that enables event 0xe025 to be either ignored or not,
depending on the user's choice.  Does that sound sane or is there a
better way to do it?  I'll be happy to post the patch once I'm done
polishing it, given that this route sounds reasonable to the
maintainers.  If we enable the kernel to react to WMI event 0xe025,
Vostro V131 users (at least those using kernels compiled with
CONFIG_ACPI_CUSTOM_METHOD) will actually be able to use all standard
features of their laptops on Linux without recompiling the kernel, which
I would consider a win (a Pyrrhic one, but still).

[1] https://bugzilla.kernel.org/show_bug.cgi?id=100441
[2] without Dell's assistance

-- 
Best regards,
Michał Kępień

Re: Dell Vostro V131 hotkeys revisited

[Pali Rohár]

Hi Michał!

On Friday 13 November 2015 11:17:16 Michał Kępień wrote:
> For those of you playing along at home, I have some news (mostly bad,
> I'm afraid).
> 
> TL;DR: I don't believe there is any way of getting Vostro V131 fully
> supported by the kernel without breaking stuff that already works, so I
> suggest a slightly different approach (see the last paragraph).
> 
> I have recently noticed that backlight control on a Vostro V131 running
> Linux has some glitches as well.  Before WMI gets enabled, pressing
> either the "brightness down" (Fn+F4) or the "brightness up" (Fn+F5) key
> causes two "presses" of the respective keycode (KEY_BRIGHTNESSUP or
> KEY_BRIGHTNESSDOWN) to be reported.  This itself seems buggy to me, but
> whatever.  The worse part is that there is an irritating flickering
> effect as well [1].

From that bug I understood that solution is to use native backlight
control (via acpi_backlight=native). This is something which can be
forced or changed by default per DMI type (for buggy machines like
this). Right?

> But if that wasn't enough, it gets even worse after
> issuing the WMI-enabling SMI call, because the keycode simulated by ACPI
> gets "shifted" by one event while the WMI events are reported correctly.
> Consider the following sequence of key presses:
> 
> Key pressed     Keycode reported        WMI event reported 
> -----------     ----------------        ------------------
> Fn+F4           (none)                  0xe005
> Fn+F4           KEY_BRIGHTNESSDOWN      0xe005
> Fn+F5           KEY_BRIGHTNESSDOWN      0xe006
> Fn+F5           KEY_BRIGHTNESSUP        0xe006
> Fn+Mute         KEY_BRIGHTNESSUP        0x0000
> Fn+Mute         (none)                  0x0000

Hm... I'm not sure if I understood this problem correctly, but those
keycodes are reported on i8042 bus by atk keyboard? Or are reported by
ACPI video.ko module? And problem is only with brightness keys?

What happen if you boot 4.2+ kernel with acpi_backlight=native?

> I determined that both brightness flickering and incorrect keycode
> reporting are caused (the latter indirectly) by ACPI method CESM (and
> later I found out that [1] agrees in regard to flickering).  While I
> haven't found the source of the "shifting" bug (and I am not willing to,
> thanks, I'd rather cut myself with a butter knife), the basic tests I've
> performed indicate that simply overriding that CESM method with a no-op
> does the job, if combined with correct kernel parameters.
> 
> However, all this nonsense makes me come to the conclusion that any
> attempts to fix it by only changing existing kernel code are futile [2].
> Thus, to avoid breaking other Dell devices which already work fine with
> Linux, I devised a "solution" using libsmbios (which in turn uses
> dcdbas) and ACPI method overriding which seems to work fine.  It still
> needs a kernel patch which enables reporting the 0xe025 event as a
> keypress (this event is currently associated with a KE_IGNORE sparse
> keymap entry).  I prepared a patch which adds a module parameter to
> dell-wmi that enables event 0xe025 to be either ignored or not,
> depending on the user's choice.  Does that sound sane or is there a
> better way to do it?  I'll be happy to post the patch once I'm done
> polishing it, given that this route sounds reasonable to the
> maintainers.  If we enable the kernel to react to WMI event 0xe025,
> Vostro V131 users (at least those using kernels compiled with
> CONFIG_ACPI_CUSTOM_METHOD) will actually be able to use all standard
> features of their laptops on Linux without recompiling the kernel, which
> I would consider a win (a Pyrrhic one, but still).
> 
> [1] https://bugzilla.kernel.org/show_bug.cgi?id=100441
> [2] without Dell's assistance
> 

-- 
Pali Rohár
pali.rohar@gmail.com

Re: Dell Vostro V131 hotkeys revisited

[Michał Kępień]

> > I have recently noticed that backlight control on a Vostro V131 running
> > Linux has some glitches as well.  Before WMI gets enabled, pressing
> > either the "brightness down" (Fn+F4) or the "brightness up" (Fn+F5) key
> > causes two "presses" of the respective keycode (KEY_BRIGHTNESSUP or
> > KEY_BRIGHTNESSDOWN) to be reported.  This itself seems buggy to me, but
> > whatever.  The worse part is that there is an irritating flickering
> > effect as well [1].
> 
> From that bug I understood that solution is to use native backlight
> control (via acpi_backlight=native). This is something which can be
> forced or changed by default per DMI type (for buggy machines like
> this). Right?

Setting acpi_backlight=native only solves the flickering problem.  So if
you don't want to enable WMI (i.e. use the Dell Instant Launch hotkey),
that's it, you're good.  But once you add the WMI-enabling SMI into the
mix, things go awry again.  In other words, I see no way of making all
features of this laptop work correctly at the same time without
resorting to DSDT patching (or properly fixing the firmware).
Hopefully, someone will.  See below for a detailed explanation.

> > But if that wasn't enough, it gets even worse after
> > issuing the WMI-enabling SMI call, because the keycode simulated by ACPI
> > gets "shifted" by one event while the WMI events are reported correctly.
> > Consider the following sequence of key presses:
> > 
> > Key pressed     Keycode reported        WMI event reported 
> > -----------     ----------------        ------------------
> > Fn+F4           (none)                  0xe005
> > Fn+F4           KEY_BRIGHTNESSDOWN      0xe005
> > Fn+F5           KEY_BRIGHTNESSDOWN      0xe006
> > Fn+F5           KEY_BRIGHTNESSUP        0xe006
> > Fn+Mute         KEY_BRIGHTNESSUP        0x0000
> > Fn+Mute         (none)                  0x0000
> 
> Hm... I'm not sure if I understood this problem correctly, but those
> keycodes are reported on i8042 bus by atk keyboard? Or are reported by
> ACPI video.ko module? And problem is only with brightness keys?
> 
> What happen if you boot 4.2+ kernel with acpi_backlight=native?

Okay, so here is the full story.  First, assume you're booting an
unpatched kernel with default command line arguments.  When you press
the "brightness up" or "brightness down" key, its scancode is reported
by the i8042 driver.  That's perfect, but the CESM method still does two
things: it sends a request to the i915 driver using the ASLE OpRegion
_and_ notifies the ACPI video driver about brightness change.  Note that
it probably does both of these things due to a broken conditional
expression in the AML code.  With acpi_backlight=native, the ASLE
request is ignored by the i915 driver (which alleviates the flickering
problem), but the Notify() calls inside the CESM method still cause
another (identical) scancode to be emitted by acpi-video (to be precise,
by acpi_video_device_notify()).  dell-wmi is not involved, because no
WMI events are generated.  In total, you get two identical scancodes for
a single key press.  It's suboptimal, but at least not completely
broken.

Now, assume you perform the WMI-enabling SMI call.  It causes the
brightness keys to no longer be reported by i8042, but rather using WMI
events.  Unless acpi_backlight=native, dell-wmi will remain idle, but
the ACPI video driver will still emit scancodes.  In other words, you
will get a single scancode for each key press.  Sounds good, but not
really because the generated scancodes are shifted (see the table from
my previous message in this thread) and you are still left with the
flickering issue.  If you use acpi_backlight=native, the flickering will
be gone, but then dell-wmi will start reacting to key presses as well
and in the extreme case you might get two different scancodes
(KEY_BRIGHTNESSUP and KEY_BRIGHTNESSDOWN) for a single key press - one
(the correct one) will be generated by dell-wmi and the other (the
shifted one) by acpi-video.

The most straightforward hack seems to be to just kill CESM with fire
and then with acpi_backlight=native you will get a single, correct
scancode for each key press.  Though that solution is still not ideal
because it makes it impossible to change brightness without using some
userspace helper.

Answering your question, AFAICT brightness keys are the only ones
affected by the WMI-enabling SMI call, but that's bad enough.  Without
DSDT patching you have to choose between hotkey support and sane
brightness control.  Unless you can prove me wrong, which I am hoping
for.

-- 
Best regards,
Michał Kępień

Re: Dell Vostro V131 hotkeys revisited

[Pali Rohár]

On Wednesday 16 December 2015 10:05:31 Michał Kępień wrote:
> > > I have recently noticed that backlight control on a Vostro V131 running
> > > Linux has some glitches as well.  Before WMI gets enabled, pressing
> > > either the "brightness down" (Fn+F4) or the "brightness up" (Fn+F5) key
> > > causes two "presses" of the respective keycode (KEY_BRIGHTNESSUP or
> > > KEY_BRIGHTNESSDOWN) to be reported.  This itself seems buggy to me, but
> > > whatever.  The worse part is that there is an irritating flickering
> > > effect as well [1].
> > 
> > From that bug I understood that solution is to use native backlight
> > control (via acpi_backlight=native). This is something which can be
> > forced or changed by default per DMI type (for buggy machines like
> > this). Right?
> 
> Setting acpi_backlight=native only solves the flickering problem.  So if
> you don't want to enable WMI (i.e. use the Dell Instant Launch hotkey),
> that's it, you're good.  But once you add the WMI-enabling SMI into the
> mix, things go awry again.  In other words, I see no way of making all
> features of this laptop work correctly at the same time without
> resorting to DSDT patching (or properly fixing the firmware).
> Hopefully, someone will.  See below for a detailed explanation.
> 
> > > But if that wasn't enough, it gets even worse after
> > > issuing the WMI-enabling SMI call, because the keycode simulated by ACPI
> > > gets "shifted" by one event while the WMI events are reported correctly.
> > > Consider the following sequence of key presses:
> > > 
> > > Key pressed     Keycode reported        WMI event reported 
> > > -----------     ----------------        ------------------
> > > Fn+F4           (none)                  0xe005
> > > Fn+F4           KEY_BRIGHTNESSDOWN      0xe005
> > > Fn+F5           KEY_BRIGHTNESSDOWN      0xe006
> > > Fn+F5           KEY_BRIGHTNESSUP        0xe006
> > > Fn+Mute         KEY_BRIGHTNESSUP        0x0000
> > > Fn+Mute         (none)                  0x0000
> > 
> > Hm... I'm not sure if I understood this problem correctly, but those
> > keycodes are reported on i8042 bus by atk keyboard? Or are reported by
> > ACPI video.ko module? And problem is only with brightness keys?
> > 
> > What happen if you boot 4.2+ kernel with acpi_backlight=native?
> 
> Okay, so here is the full story.  First, assume you're booting an
> unpatched kernel with default command line arguments.  When you press
> the "brightness up" or "brightness down" key, its scancode is reported
> by the i8042 driver.  That's perfect, but the CESM method still does two
> things: it sends a request to the i915 driver using the ASLE OpRegion
> _and_ notifies the ACPI video driver about brightness change.  Note that
> it probably does both of these things due to a broken conditional
> expression in the AML code.  With acpi_backlight=native, the ASLE
> request is ignored by the i915 driver (which alleviates the flickering
> problem), but the Notify() calls inside the CESM method still cause
> another (identical) scancode to be emitted by acpi-video (to be precise,
> by acpi_video_device_notify()).  dell-wmi is not involved, because no
> WMI events are generated.  In total, you get two identical scancodes for
> a single key press.  It's suboptimal, but at least not completely
> broken.
> 
> Now, assume you perform the WMI-enabling SMI call.  It causes the
> brightness keys to no longer be reported by i8042, but rather using WMI
> events.  Unless acpi_backlight=native, dell-wmi will remain idle, but
> the ACPI video driver will still emit scancodes.  In other words, you
> will get a single scancode for each key press.  Sounds good, but not
> really because the generated scancodes are shifted (see the table from
> my previous message in this thread) and you are still left with the
> flickering issue.  If you use acpi_backlight=native, the flickering will
> be gone, but then dell-wmi will start reacting to key presses as well
> and in the extreme case you might get two different scancodes
> (KEY_BRIGHTNESSUP and KEY_BRIGHTNESSDOWN) for a single key press - one
> (the correct one) will be generated by dell-wmi and the other (the
> shifted one) by acpi-video.
> 
> The most straightforward hack seems to be to just kill CESM with fire
> and then with acpi_backlight=native you will get a single, correct
> scancode for each key press.  Though that solution is still not ideal
> because it makes it impossible to change brightness without using some
> userspace helper.
> 
> Answering your question, AFAICT brightness keys are the only ones
> affected by the WMI-enabling SMI call, but that's bad enough.  Without
> DSDT patching you have to choose between hotkey support and sane
> brightness control.  Unless you can prove me wrong, which I am hoping
> for.
> 

CCing Hans de Goede

Hans, you tried to fix problems with acpi backlight... do you have idea
how to fix above problem with those two brightness keys?

In my opinion we should drop keypress events in acpi-video module. And
use event from dell-wmi if SMM was enabled.

-- 
Pali Rohár
pali.rohar@gmail.com

Re: Dell Vostro V131 hotkeys revisited

[Hans de Goede]

[-- Attachment #1: Type: text/plain, Size: 7458 bytes --]

Hi all,

On 16-12-15 10:30, Pali Rohár wrote:
> On Wednesday 16 December 2015 10:05:31 Michał Kępień wrote:
>>>> I have recently noticed that backlight control on a Vostro V131 running
>>>> Linux has some glitches as well.  Before WMI gets enabled, pressing
>>>> either the "brightness down" (Fn+F4) or the "brightness up" (Fn+F5) key
>>>> causes two "presses" of the respective keycode (KEY_BRIGHTNESSUP or
>>>> KEY_BRIGHTNESSDOWN) to be reported.  This itself seems buggy to me, but
>>>> whatever.  The worse part is that there is an irritating flickering
>>>> effect as well [1].
>>>
>>>  From that bug I understood that solution is to use native backlight
>>> control (via acpi_backlight=native). This is something which can be
>>> forced or changed by default per DMI type (for buggy machines like
>>> this). Right?
>>
>> Setting acpi_backlight=native only solves the flickering problem.  So if
>> you don't want to enable WMI (i.e. use the Dell Instant Launch hotkey),
>> that's it, you're good.  But once you add the WMI-enabling SMI into the
>> mix, things go awry again.  In other words, I see no way of making all
>> features of this laptop work correctly at the same time without
>> resorting to DSDT patching (or properly fixing the firmware).
>> Hopefully, someone will.  See below for a detailed explanation.
>>
>>>> But if that wasn't enough, it gets even worse after
>>>> issuing the WMI-enabling SMI call, because the keycode simulated by ACPI
>>>> gets "shifted" by one event while the WMI events are reported correctly.
>>>> Consider the following sequence of key presses:
>>>>
>>>> Key pressed     Keycode reported        WMI event reported
>>>> -----------     ----------------        ------------------
>>>> Fn+F4           (none)                  0xe005
>>>> Fn+F4           KEY_BRIGHTNESSDOWN      0xe005
>>>> Fn+F5           KEY_BRIGHTNESSDOWN      0xe006
>>>> Fn+F5           KEY_BRIGHTNESSUP        0xe006
>>>> Fn+Mute         KEY_BRIGHTNESSUP        0x0000
>>>> Fn+Mute         (none)                  0x0000
>>>
>>> Hm... I'm not sure if I understood this problem correctly, but those
>>> keycodes are reported on i8042 bus by atk keyboard? Or are reported by
>>> ACPI video.ko module? And problem is only with brightness keys?
>>>
>>> What happen if you boot 4.2+ kernel with acpi_backlight=native?
>>
>> Okay, so here is the full story.  First, assume you're booting an
>> unpatched kernel with default command line arguments.  When you press
>> the "brightness up" or "brightness down" key, its scancode is reported
>> by the i8042 driver.  That's perfect, but the CESM method still does two
>> things: it sends a request to the i915 driver using the ASLE OpRegion
>> _and_ notifies the ACPI video driver about brightness change.  Note that
>> it probably does both of these things due to a broken conditional
>> expression in the AML code.  With acpi_backlight=native, the ASLE
>> request is ignored by the i915 driver (which alleviates the flickering
>> problem), but the Notify() calls inside the CESM method still cause
>> another (identical) scancode to be emitted by acpi-video (to be precise,
>> by acpi_video_device_notify()).  dell-wmi is not involved, because no
>> WMI events are generated.  In total, you get two identical scancodes for
>> a single key press.  It's suboptimal, but at least not completely
>> broken.
>>
>> Now, assume you perform the WMI-enabling SMI call.  It causes the
>> brightness keys to no longer be reported by i8042, but rather using WMI
>> events.  Unless acpi_backlight=native, dell-wmi will remain idle, but
>> the ACPI video driver will still emit scancodes.  In other words, you
>> will get a single scancode for each key press.  Sounds good, but not
>> really because the generated scancodes are shifted (see the table from
>> my previous message in this thread) and you are still left with the
>> flickering issue.  If you use acpi_backlight=native, the flickering will
>> be gone, but then dell-wmi will start reacting to key presses as well
>> and in the extreme case you might get two different scancodes
>> (KEY_BRIGHTNESSUP and KEY_BRIGHTNESSDOWN) for a single key press - one
>> (the correct one) will be generated by dell-wmi and the other (the
>> shifted one) by acpi-video.
>>
>> The most straightforward hack seems to be to just kill CESM with fire
>> and then with acpi_backlight=native you will get a single, correct
>> scancode for each key press.  Though that solution is still not ideal
>> because it makes it impossible to change brightness without using some
>> userspace helper.
>>
>> Answering your question, AFAICT brightness keys are the only ones
>> affected by the WMI-enabling SMI call, but that's bad enough.  Without
>> DSDT patching you have to choose between hotkey support and sane
>> brightness control.  Unless you can prove me wrong, which I am hoping
>> for.
>>
>
> CCing Hans de Goede
>
> Hans, you tried to fix problems with acpi backlight... do you have idea
> how to fix above problem with those two brightness keys?
>
> In my opinion we should drop keypress events in acpi-video module. And
> use event from dell-wmi if SMM was enabled.

Pali, thanks for bringing this one to my attention, so as I see it we
need to do a number of things:

1) Add a dmi based quirk to: drivers/acpi/video_detect.c to
    use native backlight on this model, so that the flickering gets fixed,
    for now you can use acpi_backlight=native for testing, until we've got
    the keys sorted out and then we should submit a kernel patch with this
    quirk

2a) I'm not familiar with the WMI bits, but as I see it we want that driver to
    be loaded to get other hotkeys to work, so lets load it (I assume this will
    already happen automatically if enabled). If I understand things correctly
    then doing this will silence the i8042 generated brightness key events, but
    it will cause the acpi-video bus generated key events lag in time by one
    event. So we will need an option in drivers/acpi/acpi_video.c to stop it
    from generating key-presses, this may be useful in some other (rare) cases
    too. I've written a patch for this (attached), can you build a kernel with
    this patch and then add "video.report_key_events=1" to the kernel cmdline
    and see if that helps ?

Or alternatively we could not load the wmi driver, and fix the double events
being reported by the i8042 / atkbd driver by adding a udev hwdb entry to
filter these out, we already do that for some laptops because of similar issues,
see e.g. this part of: /lib/udev/hwdb.d/60-keyboard.hwdb

# Dell Inspiron 1520
evdev:atkbd:dmi:bvn*:bvr*:bd*:svnDell*:pnInspiron*1520:pvr*
KEYBOARD_KEY_85=unknown # Brightness Down, also emitted by acpi-video, ignore
KEYBOARD_KEY_86=unknown # Brightness Up, also emitted by acpi-video, ignore

To test this you need to edit /lib/udev/hwdb.d/60-keyboard.hwdb add an entry
for your laptop (see "cat /sys/class/dmi/id/product_name" output to find what to
put after "pn" ), then rebuild the hwdb: "sudo udevadm hwdb --update" and then
reboot, yes reboot there is another way to re-apply the rules but rebooting is
really so much easier.

I think you should try this method too and see if the flickering goes away
when fixing the double events, without needing to use acpi_backlight=native.

It is also not clear to me if you've tried using the WMI events without
acpi_backlight=native, maybe that fixes things magically ?

Regards,

Hans

[-- Attachment #2: 0001-acpi-video-Add-a-module-option-to-disable-the-report.patch --]
[-- Type: text/x-patch, Size: 2475 bytes --]

From fc76b85ba7fd6fa9a37b696ab743568d5c7742c4 Mon Sep 17 00:00:00 2001
From: Hans de Goede <hdegoede@redhat.com>
Date: Wed, 16 Dec 2015 11:19:00 +0100
Subject: [PATCH] acpi-video: Add a module option to disable the reporting of
 keypresses

Add a module option to disable the reporting of keypresses, in some buggy
firmware implementatinon, the reported events are wrong. E.g. they lag
reality by one event in the case triggering the writing of this patch.

In this case it is better to not forward these wrong events to userspace
(esp.) when there is another source of the same events which is not buggy.

Note this is only intended to work around implementations which send
events which are plain wrong. In some cases we get double events, e.g.
from both acpi-video and the atkbd driver, in this case acpi-video is
considered the canonical source, and the events from the other source
should be filtered (using e.g. /lib/udev/hwdb.d/60-keyboard.hwdb).

Signed-off-by: Hans de Goede <hdegoede@redhat.com>
---
 drivers/acpi/acpi_video.c | 11 +++++++++--
 1 file changed, 9 insertions(+), 2 deletions(-)

diff --git a/drivers/acpi/acpi_video.c b/drivers/acpi/acpi_video.c
index 3405f7a..d41c95b 100644
--- a/drivers/acpi/acpi_video.c
+++ b/drivers/acpi/acpi_video.c
@@ -77,6 +77,13 @@ module_param(allow_duplicates, bool, 0644);
 static int disable_backlight_sysfs_if = -1;
 module_param(disable_backlight_sysfs_if, int, 0444);
 
+#define REPORT_OUTPUT_KEY_EVENTS		0x01
+#define REPORT_BRIGHTNESS_KEY_EVENTS		0x02
+static int report_key_events = -1;
+module_param(report_key_events, int, 0644);
+MODULE_PARM_DESC(report_key_events,
+	"0: none, 1: output changes, 2: brightness changes, 3: all");
+
 static bool device_id_scheme = false;
 module_param(device_id_scheme, bool, 0444);
 
@@ -1480,7 +1487,7 @@ static void acpi_video_bus_notify(struct acpi_device *device, u32 event)
 		/* Something vetoed the keypress. */
 		keycode = 0;
 
-	if (keycode) {
+	if (keycode && (report_key_events & REPORT_OUTPUT_KEY_EVENTS)) {
 		input_report_key(input, keycode, 1);
 		input_sync(input);
 		input_report_key(input, keycode, 0);
@@ -1544,7 +1551,7 @@ static void acpi_video_device_notify(acpi_handle handle, u32 event, void *data)
 
 	acpi_notifier_call_chain(device, event, 0);
 
-	if (keycode) {
+	if (keycode && (report_key_events & REPORT_BRIGHTNESS_KEY_EVENTS)) {
 		input_report_key(input, keycode, 1);
 		input_sync(input);
 		input_report_key(input, keycode, 0);
-- 
2.5.0

Re: Dell Vostro V131 hotkeys revisited

[Michał Kępień]

Hi Hans,

> Pali, thanks for bringing this one to my attention, so as I see it we
> need to do a number of things:
> 
> 1) Add a dmi based quirk to: drivers/acpi/video_detect.c to
>    use native backlight on this model, so that the flickering gets fixed,
>    for now you can use acpi_backlight=native for testing, until we've got
>    the keys sorted out and then we should submit a kernel patch with this
>    quirk
> 
> 2a) I'm not familiar with the WMI bits, but as I see it we want that driver to
>    be loaded to get other hotkeys to work, so lets load it (I assume this will
>    already happen automatically if enabled). If I understand things correctly
>    then doing this will silence the i8042 generated brightness key events, but
>    it will cause the acpi-video bus generated key events lag in time by one
>    event. So we will need an option in drivers/acpi/acpi_video.c to stop it
>    from generating key-presses, this may be useful in some other (rare) cases
>    too. I've written a patch for this (attached), can you build a kernel with
>    this patch and then add "video.report_key_events=1" to the kernel cmdline
>    and see if that helps ?

Thank you for a quick response.  Your patch works fine.  If per-model
key event generation suppression is acceptable, I believe this would
indeed work around V131's issues.  The elegance of this solution is that
it doesn't depend on the state of WMI event reporting - if it is off,
events will still be correctly reported by i8042; if it is on, dell-wmi
will generate them.  Either way, the behavior will be correct.

> Or alternatively we could not load the wmi driver, and fix the double events
> being reported by the i8042 / atkbd driver by adding a udev hwdb entry to
> filter these out, we already do that for some laptops because of similar issues,
> see e.g. this part of: /lib/udev/hwdb.d/60-keyboard.hwdb
> 
> # Dell Inspiron 1520
> evdev:atkbd:dmi:bvn*:bvr*:bd*:svnDell*:pnInspiron*1520:pvr*
> KEYBOARD_KEY_85=unknown # Brightness Down, also emitted by acpi-video, ignore
> KEYBOARD_KEY_86=unknown # Brightness Up, also emitted by acpi-video, ignore
> 
> To test this you need to edit /lib/udev/hwdb.d/60-keyboard.hwdb add an entry
> for your laptop (see "cat /sys/class/dmi/id/product_name" output to find what to
> put after "pn" ), then rebuild the hwdb: "sudo udevadm hwdb --update" and then
> reboot, yes reboot there is another way to re-apply the rules but rebooting is
> really so much easier.
> 
> I think you should try this method too and see if the flickering goes away
> when fixing the double events, without needing to use acpi_backlight=native.

The flickering is caused by two things happening in short succession:

  * an erroneous ASLE request, which is only ignored by the i915 driver
    with acpi_backlight=native,

  * a notification sent to the ACPI video driver, which causes
    brightness to be switched after HZ / 10 with acpi_backlight=video.

So I believe those double events are just a side effect, not the root
cause of the flickering.

> It is also not clear to me if you've tried using the WMI events without
> acpi_backlight=native, maybe that fixes things magically ?

In order for WMI events to be reported at all on Vostro V131, a special
SMI has to be invoked.  That SMI always messes up the key events
reported by the ACPI video driver, no matter what acpi_backlight is set
to.  And the flickering is caused by yet another piece of faulty AML
inside the CESM method.  Is this what you were asking?  If not, I'll be
happy to answer any further questions you might have.

Also, I need to apologize.  While testing your patch I noticed that my
notes got mixed up at some point, rendering the story in my previous
message partially invalid.  I wrote that in order for dell-wmi to report
key events, acpi_backlight has to be set to "native".  That is not true
as it has to be set to "vendor", as the code in dell_wmi_init() and
dell_wmi_process_key() clearly shows.

To clear things up, here is the current state of affairs:

  * acpi_backlight=native solves the flickering issue, but doesn't help
    with key event "lagging" after WMI is enabled,

  * using the patch provided by Hans (or a similar one), the "lagged"
    events can be filtered, leaving key event generation to dell-wmi,

  * dell-wmi won't generate events unless acpi_backlight=vendor, which
    in turn breaks brightness control due to faulty ASLE requests.

To break out of this loop, I suggest that:

  * acpi_backlight should default to "native" for Vostro V131, based on
    a DMI check,

  * brightness key event generation performed by the ACPI video driver
    should always be suppressed on Vostro V131, because it's faulty due
    to firmware bugs (and correct events will be reported anyway by
    either i8042 or WMI),

  * yet another quirk should be added to dell-wmi, so that brightness
    key events are generated not only when acpi_backlight=vendor, but
    also when acpi_backlight=native.

The only downside I see to such a solution is that by default the user
would have to use a userspace helper in order for the key events to be
translated into brightness changes.  However, if they so desire,
acpi_backlight may still be set to "video", which would enable
brightness changes to be done by the kernel, though with the flickering
effect still in place.  Sounds like a fair choice to me.  What do you
think?

-- 
Best regards,
Michał Kępień

Re: Dell Vostro V131 hotkeys revisited

[Hans de Goede]

[-- Attachment #1: Type: text/plain, Size: 7397 bytes --]

Hi Michał,

On 17-12-15 09:05, Michał Kępień wrote:
> Hi Hans,
>
>> Pali, thanks for bringing this one to my attention, so as I see it we
>> need to do a number of things:
>>
>> 1) Add a dmi based quirk to: drivers/acpi/video_detect.c to
>>     use native backlight on this model, so that the flickering gets fixed,
>>     for now you can use acpi_backlight=native for testing, until we've got
>>     the keys sorted out and then we should submit a kernel patch with this
>>     quirk
>>
>> 2a) I'm not familiar with the WMI bits, but as I see it we want that driver to
>>     be loaded to get other hotkeys to work, so lets load it (I assume this will
>>     already happen automatically if enabled). If I understand things correctly
>>     then doing this will silence the i8042 generated brightness key events, but
>>     it will cause the acpi-video bus generated key events lag in time by one
>>     event. So we will need an option in drivers/acpi/acpi_video.c to stop it
>>     from generating key-presses, this may be useful in some other (rare) cases
>>     too. I've written a patch for this (attached), can you build a kernel with
>>     this patch and then add "video.report_key_events=1" to the kernel cmdline
>>     and see if that helps ?
>
> Thank you for a quick response.  Your patch works fine.  If per-model
> key event generation suppression is acceptable, I believe this would
> indeed work around V131's issues.  The elegance of this solution is that
> it doesn't depend on the state of WMI event reporting - if it is off,
> events will still be correctly reported by i8042; if it is on, dell-wmi
> will generate them.  Either way, the behavior will be correct.
>
>> Or alternatively we could not load the wmi driver, and fix the double events
>> being reported by the i8042 / atkbd driver by adding a udev hwdb entry to
>> filter these out, we already do that for some laptops because of similar issues,
>> see e.g. this part of: /lib/udev/hwdb.d/60-keyboard.hwdb
>>
>> # Dell Inspiron 1520
>> evdev:atkbd:dmi:bvn*:bvr*:bd*:svnDell*:pnInspiron*1520:pvr*
>> KEYBOARD_KEY_85=unknown # Brightness Down, also emitted by acpi-video, ignore
>> KEYBOARD_KEY_86=unknown # Brightness Up, also emitted by acpi-video, ignore
>>
>> To test this you need to edit /lib/udev/hwdb.d/60-keyboard.hwdb add an entry
>> for your laptop (see "cat /sys/class/dmi/id/product_name" output to find what to
>> put after "pn" ), then rebuild the hwdb: "sudo udevadm hwdb --update" and then
>> reboot, yes reboot there is another way to re-apply the rules but rebooting is
>> really so much easier.
>>
>> I think you should try this method too and see if the flickering goes away
>> when fixing the double events, without needing to use acpi_backlight=native.
>
> The flickering is caused by two things happening in short succession:
>
>    * an erroneous ASLE request, which is only ignored by the i915 driver
>      with acpi_backlight=native,
>
>    * a notification sent to the ACPI video driver, which causes
>      brightness to be switched after HZ / 10 with acpi_backlight=video.
>
> So I believe those double events are just a side effect, not the root
> cause of the flickering.
>
>> It is also not clear to me if you've tried using the WMI events without
>> acpi_backlight=native, maybe that fixes things magically ?
>
> In order for WMI events to be reported at all on Vostro V131, a special
> SMI has to be invoked.  That SMI always messes up the key events
> reported by the ACPI video driver, no matter what acpi_backlight is set
> to.  And the flickering is caused by yet another piece of faulty AML
> inside the CESM method.  Is this what you were asking?  If not, I'll be
> happy to answer any further questions you might have.
>
> Also, I need to apologize.  While testing your patch I noticed that my
> notes got mixed up at some point, rendering the story in my previous
> message partially invalid.  I wrote that in order for dell-wmi to report
> key events, acpi_backlight has to be set to "native".  That is not true
> as it has to be set to "vendor", as the code in dell_wmi_init() and
> dell_wmi_process_key() clearly shows.
>
> To clear things up, here is the current state of affairs:
>
>    * acpi_backlight=native solves the flickering issue, but doesn't help
>      with key event "lagging" after WMI is enabled,
>
>    * using the patch provided by Hans (or a similar one), the "lagged"
>      events can be filtered, leaving key event generation to dell-wmi,
>
>    * dell-wmi won't generate events unless acpi_backlight=vendor, which
>      in turn breaks brightness control due to faulty ASLE requests.
>
> To break out of this loop, I suggest that:
>
>    * acpi_backlight should default to "native" for Vostro V131, based on
>      a DMI check,

Ack.

>    * brightness key event generation performed by the ACPI video driver
>      should always be suppressed on Vostro V131, because it's faulty due
>      to firmware bugs (and correct events will be reported anyway by
>      either i8042 or WMI),

s/should always be suppressed/should be suppressed by default/ otherwise
ack. We can easily do this the same way we currently deal with the
disable_backlight_sysfs_if option in acpi_video.c

>    * yet another quirk should be added to dell-wmi, so that brightness
>      key events are generated not only when acpi_backlight=vendor, but
>      also when acpi_backlight=native.

Nack, the real problem here is that checking if acpi_backlight!=vendor
is the wrong way to check if key event generation should be suppressed.

This actually reminds me that I've the following item on my
todo list for a while but I've not gotten around to it yet:

  -Add an acpi_video_handles_key_presses() helper, and use this where
   appropriate (dell-wmi and others).

The mean reason for that item on my todo list was to make code doing
brigthness key-event suppression more readable. But we can also use
it for this case, if we check the new video.report_key_events parameter
in the acpi_video_handles_key_presses() helper, and switch dell-wmi
over to this helper, things will just work without needing yet another
quirk in dell-wmi :)

I've written a patch-set implementing this (attached), this obsoletes
my previous patch. As before, please test this with:

acpi_backlight=native video.report_key_events=1

On the kernel cmdline, we can add a patch adding dmi quirks to make
those the default later.

For that patch I'm going to need the dmi strings for your laptop,
can you please do:

for i in /sys/class/dmi/id/*_*; do echo $i; cat $i; done

And then include the output in your next mail ? Feel free to leave
out the serial numbers, asset tags and uuids, those are potentially
privacy sensitive and I don't need them.

> The only downside I see to such a solution is that by default the user
> would have to use a userspace helper in order for the key events to be
> translated into brightness changes.  However, if they so desire,
> acpi_backlight may still be set to "video", which would enable
> brightness changes to be done by the kernel, though with the flickering
> effect still in place.  Sounds like a fair choice to me.  What do you
> think?

I do not see the need for a userspace helper as a problem, this actually
is the case on most modern laptops already, as we default to
acpi_backlight=native there, and that has the same requirement.

Regards,

Hans

[-- Attachment #2: 0001-acpi-video-Add-a-acpi_video_handles_brightness_key_p.patch --]
[-- Type: text/x-patch, Size: 2975 bytes --]

From d2ee1961d2a94a5f7b9f2bf5ae9fb2e6a791f25b Mon Sep 17 00:00:00 2001
From: Hans de Goede <hdegoede@redhat.com>
Date: Thu, 17 Dec 2015 09:51:07 +0100
Subject: [PATCH 1/4] acpi-video: Add a
 acpi_video_handles_brightness_key_presses() helper

Several drivers want to know if the acpi-video is generating key-presses
for brightness change hotkeys to avoid sending double key-events to
userspace for these. Currently these driver use this construct for this:

	if (acpi_video_get_backlight_type() == acpi_backlight_vendor)
		report_brightness_key_event();

This indirect way of detecting if acpi-video is active does not make the
code easier to understand, and in some cases it is wrong because just
because the preferred type != vendor does not mean that acpi-video is
actually listening for brightness events, e.g. there may be no acpi-video
bus on the system at all.

This commit adds a acpi_video_handles_brightness_key_presses() helper
function, making the code needing this functionality both easier to read
and more correct.

Signed-off-by: Hans de Goede <hdegoede@redhat.com>
---
 drivers/acpi/acpi_video.c | 12 ++++++++++++
 include/acpi/video.h      |  6 ++++++
 2 files changed, 18 insertions(+)

diff --git a/drivers/acpi/acpi_video.c b/drivers/acpi/acpi_video.c
index 3405f7a..2a649f3e 100644
--- a/drivers/acpi/acpi_video.c
+++ b/drivers/acpi/acpi_video.c
@@ -2072,6 +2072,18 @@ void acpi_video_unregister_backlight(void)
 	mutex_unlock(&register_count_mutex);
 }
 
+bool acpi_video_handles_brightness_key_presses(void)
+{
+	bool have_video_busses;
+
+	mutex_lock(&video_list_lock);
+	have_video_busses = !list_empty(&video_bus_head);
+	mutex_unlock(&video_list_lock);
+
+	return have_video_busses;
+}
+EXPORT_SYMBOL(acpi_video_handles_brightness_key_presses);
+
 /*
  * This is kind of nasty. Hardware using Intel chipsets may require
  * the video opregion code to be run first in order to initialise
diff --git a/include/acpi/video.h b/include/acpi/video.h
index c62392d..f11d342 100644
--- a/include/acpi/video.h
+++ b/include/acpi/video.h
@@ -2,6 +2,7 @@
 #define __ACPI_VIDEO_H
 
 #include <linux/errno.h> /* for ENODEV */
+#include <linux/types.h> /* for bool */
 
 struct acpi_device;
 
@@ -31,6 +32,7 @@ extern int acpi_video_get_edid(struct acpi_device *device, int type,
 			       int device_id, void **edid);
 extern enum acpi_backlight_type acpi_video_get_backlight_type(void);
 extern void acpi_video_set_dmi_backlight_type(enum acpi_backlight_type type);
+extern bool acpi_video_handles_brightness_key_presses(void);
 #else
 static inline int acpi_video_register(void) { return 0; }
 static inline void acpi_video_unregister(void) { return; }
@@ -46,6 +48,10 @@ static inline enum acpi_backlight_type acpi_video_get_backlight_type(void)
 static inline void acpi_video_set_dmi_backlight_type(enum acpi_backlight_type type)
 {
 }
+static inline bool acpi_video_handles_brightness_key_presses(void)
+{
+	return false;
+}
 #endif
 
 #endif
-- 
2.5.0


[-- Attachment #3: 0002-dell-wmi-Use-acpi_video_handles_brightness_key_press.patch --]
[-- Type: text/x-patch, Size: 1685 bytes --]

From 9355058f5c1d7c815a293e0c0731d85f0a59b4a1 Mon Sep 17 00:00:00 2001
From: Hans de Goede <hdegoede@redhat.com>
Date: Thu, 17 Dec 2015 09:59:01 +0100
Subject: [PATCH 2/4] dell-wmi: Use acpi_video_handles_brightness_key_presses()

Use the new acpi_video_handles_brightness_key_presses function to check
if we should report brightness key-presses.

This makes the code both easier to read and makes it properly report
key-presses when acpi-video is not reporting them for reasons other
then the backlight type being vendor.

Signed-off-by: Hans de Goede <hdegoede@redhat.com>
---
 drivers/platform/x86/dell-wmi.c | 6 ++----
 1 file changed, 2 insertions(+), 4 deletions(-)

diff --git a/drivers/platform/x86/dell-wmi.c b/drivers/platform/x86/dell-wmi.c
index f2d77fe..cb8a9c2 100644
--- a/drivers/platform/x86/dell-wmi.c
+++ b/drivers/platform/x86/dell-wmi.c
@@ -43,8 +43,6 @@ MODULE_LICENSE("GPL");
 
 #define DELL_EVENT_GUID "9DBB5994-A997-11DA-B012-B622A1EF5492"
 
-static int acpi_video;
-
 MODULE_ALIAS("wmi:"DELL_EVENT_GUID);
 
 /*
@@ -159,7 +157,8 @@ static void dell_wmi_process_key(int reported_key)
 
 	/* Don't report brightness notifications that will also come via ACPI */
 	if ((key->keycode == KEY_BRIGHTNESSUP ||
-	     key->keycode == KEY_BRIGHTNESSDOWN) && acpi_video)
+	     key->keycode == KEY_BRIGHTNESSDOWN) &&
+	    acpi_video_handles_brightness_key_presses())
 		return;
 
 	sparse_keymap_report_entry(dell_wmi_input_dev, key, 1, true);
@@ -398,7 +397,6 @@ static int __init dell_wmi_init(void)
 	}
 
 	dmi_walk(find_hk_type, NULL);
-	acpi_video = acpi_video_get_backlight_type() != acpi_backlight_vendor;
 
 	err = dell_wmi_input_setup();
 	if (err)
-- 
2.5.0


[-- Attachment #4: 0003-thinkpad_acpi-Use-acpi_video_handles_brightness_key_.patch --]
[-- Type: text/x-patch, Size: 1384 bytes --]

From b55c9c38169a543465dd8a213e7330e1561eee95 Mon Sep 17 00:00:00 2001
From: Hans de Goede <hdegoede@redhat.com>
Date: Thu, 17 Dec 2015 10:19:18 +0100
Subject: [PATCH 3/4] thinkpad_acpi: Use
 acpi_video_handles_brightness_key_presses()

Use the new acpi_video_handles_brightness_key_presses function to check
if we should report brightness key-presses.

This makes the code both easier to read and makes it properly report
key-presses when acpi-video is not reporting them for reasons other
then the backlight type being vendor.

Signed-off-by: Hans de Goede <hdegoede@redhat.com>
---
 drivers/platform/x86/thinkpad_acpi.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/platform/x86/thinkpad_acpi.c b/drivers/platform/x86/thinkpad_acpi.c
index 0bed473..f453d5d 100644
--- a/drivers/platform/x86/thinkpad_acpi.c
+++ b/drivers/platform/x86/thinkpad_acpi.c
@@ -3488,7 +3488,7 @@ static int __init hotkey_init(struct ibm_init_struct *iibm)
 	/* Do not issue duplicate brightness change events to
 	 * userspace. tpacpi_detect_brightness_capabilities() must have
 	 * been called before this point  */
-	if (acpi_video_get_backlight_type() != acpi_backlight_vendor) {
+	if (acpi_video_handles_brightness_key_presses()) {
 		pr_info("This ThinkPad has standard ACPI backlight "
 			"brightness control, supported by the ACPI "
 			"video driver\n");
-- 
2.5.0


[-- Attachment #5: 0004-acpi-video-Add-a-module-option-to-disable-the-report.patch --]
[-- Type: text/x-patch, Size: 2830 bytes --]

From 5e7ff99407aeb60c2f1516cdd80d7859646497dd Mon Sep 17 00:00:00 2001
From: Hans de Goede <hdegoede@redhat.com>
Date: Wed, 16 Dec 2015 11:19:00 +0100
Subject: [PATCH 4/4] acpi-video: Add a module option to disable the reporting
 of keypresses

Add a module option to disable the reporting of keypresses, in some buggy
firmware implementatinon, the reported events are wrong. E.g. they lag
reality by one event in the case triggering the writing of this patch.

In this case it is better to not forward these wrong events to userspace
(esp.) when there is another source of the same events which is not buggy.

Note this is only intended to work around implementations which send
events which are plain wrong. In some cases we get double events, e.g.
from both acpi-video and the atkbd driver, in this case acpi-video is
considered the canonical source, and the events from the other source
should be filtered (using e.g. /lib/udev/hwdb.d/60-keyboard.hwdb).

Signed-off-by: Hans de Goede <hdegoede@redhat.com>
---
 drivers/acpi/acpi_video.c | 14 +++++++++++---
 1 file changed, 11 insertions(+), 3 deletions(-)

diff --git a/drivers/acpi/acpi_video.c b/drivers/acpi/acpi_video.c
index 2a649f3e..2971154 100644
--- a/drivers/acpi/acpi_video.c
+++ b/drivers/acpi/acpi_video.c
@@ -77,6 +77,13 @@ module_param(allow_duplicates, bool, 0644);
 static int disable_backlight_sysfs_if = -1;
 module_param(disable_backlight_sysfs_if, int, 0444);
 
+#define REPORT_OUTPUT_KEY_EVENTS		0x01
+#define REPORT_BRIGHTNESS_KEY_EVENTS		0x02
+static int report_key_events = -1;
+module_param(report_key_events, int, 0644);
+MODULE_PARM_DESC(report_key_events,
+	"0: none, 1: output changes, 2: brightness changes, 3: all");
+
 static bool device_id_scheme = false;
 module_param(device_id_scheme, bool, 0444);
 
@@ -1480,7 +1487,7 @@ static void acpi_video_bus_notify(struct acpi_device *device, u32 event)
 		/* Something vetoed the keypress. */
 		keycode = 0;
 
-	if (keycode) {
+	if (keycode && (report_key_events & REPORT_OUTPUT_KEY_EVENTS)) {
 		input_report_key(input, keycode, 1);
 		input_sync(input);
 		input_report_key(input, keycode, 0);
@@ -1544,7 +1551,7 @@ static void acpi_video_device_notify(acpi_handle handle, u32 event, void *data)
 
 	acpi_notifier_call_chain(device, event, 0);
 
-	if (keycode) {
+	if (keycode && (report_key_events & REPORT_BRIGHTNESS_KEY_EVENTS)) {
 		input_report_key(input, keycode, 1);
 		input_sync(input);
 		input_report_key(input, keycode, 0);
@@ -2080,7 +2087,8 @@ bool acpi_video_handles_brightness_key_presses(void)
 	have_video_busses = !list_empty(&video_bus_head);
 	mutex_unlock(&video_list_lock);
 
-	return have_video_busses;
+	return have_video_busses &&
+	       (report_key_events & REPORT_BRIGHTNESS_KEY_EVENTS);
 }
 EXPORT_SYMBOL(acpi_video_handles_brightness_key_presses);
 
-- 
2.5.0

Re: Dell Vostro V131 hotkeys revisited

[Pali Rohár]

Hi Hans! See my comments below about your patches.

> From 9355058f5c1d7c815a293e0c0731d85f0a59b4a1 Mon Sep 17 00:00:00 2001
> From: Hans de Goede <hdegoede@redhat.com>
> Date: Thu, 17 Dec 2015 09:59:01 +0100
> Subject: [PATCH 2/4] dell-wmi: Use acpi_video_handles_brightness_key_presses()
> 
> Use the new acpi_video_handles_brightness_key_presses function to check
> if we should report brightness key-presses.
> 
> This makes the code both easier to read and makes it properly report
> key-presses when acpi-video is not reporting them for reasons other
> then the backlight type being vendor.
> 
> Signed-off-by: Hans de Goede <hdegoede@redhat.com>
> ---
>  drivers/platform/x86/dell-wmi.c | 6 ++----
>  1 file changed, 2 insertions(+), 4 deletions(-)
> 
> diff --git a/drivers/platform/x86/dell-wmi.c b/drivers/platform/x86/dell-wmi.c
> index f2d77fe..cb8a9c2 100644
> --- a/drivers/platform/x86/dell-wmi.c
> +++ b/drivers/platform/x86/dell-wmi.c
> @@ -43,8 +43,6 @@ MODULE_LICENSE("GPL");
>  
>  #define DELL_EVENT_GUID "9DBB5994-A997-11DA-B012-B622A1EF5492"
>  
> -static int acpi_video;
> -
>  MODULE_ALIAS("wmi:"DELL_EVENT_GUID);
>  
>  /*
> @@ -159,7 +157,8 @@ static void dell_wmi_process_key(int reported_key)
>  
>  	/* Don't report brightness notifications that will also come via ACPI */
>  	if ((key->keycode == KEY_BRIGHTNESSUP ||
> -	     key->keycode == KEY_BRIGHTNESSDOWN) && acpi_video)
> +	     key->keycode == KEY_BRIGHTNESSDOWN) &&
> +	    acpi_video_handles_brightness_key_presses())

I do not like this, because that function uses mutex and is called every
time when brightness key event is received by wmi notify handler.

>  		return;
>  
>  	sparse_keymap_report_entry(dell_wmi_input_dev, key, 1, true);
> @@ -398,7 +397,6 @@ static int __init dell_wmi_init(void)
>  	}
>  
>  	dmi_walk(find_hk_type, NULL);
> -	acpi_video = acpi_video_get_backlight_type() != acpi_backlight_vendor;
>  
>  	err = dell_wmi_input_setup();
>  	if (err)
> -- 
> 2.5.0
> 

> From 5e7ff99407aeb60c2f1516cdd80d7859646497dd Mon Sep 17 00:00:00 2001
> From: Hans de Goede <hdegoede@redhat.com>
> Date: Wed, 16 Dec 2015 11:19:00 +0100
> Subject: [PATCH 4/4] acpi-video: Add a module option to disable the reporting
>  of keypresses
> 
> Add a module option to disable the reporting of keypresses, in some buggy
> firmware implementatinon, the reported events are wrong. E.g. they lag
> reality by one event in the case triggering the writing of this patch.
> 
> In this case it is better to not forward these wrong events to userspace
> (esp.) when there is another source of the same events which is not buggy.
> 
> Note this is only intended to work around implementations which send
> events which are plain wrong. In some cases we get double events, e.g.
> from both acpi-video and the atkbd driver, in this case acpi-video is
> considered the canonical source, and the events from the other source
> should be filtered (using e.g. /lib/udev/hwdb.d/60-keyboard.hwdb).
> 
> Signed-off-by: Hans de Goede <hdegoede@redhat.com>
> ---
>  drivers/acpi/acpi_video.c | 14 +++++++++++---
>  1 file changed, 11 insertions(+), 3 deletions(-)
> 
> diff --git a/drivers/acpi/acpi_video.c b/drivers/acpi/acpi_video.c
> index 2a649f3e..2971154 100644
> --- a/drivers/acpi/acpi_video.c
> +++ b/drivers/acpi/acpi_video.c
> @@ -77,6 +77,13 @@ module_param(allow_duplicates, bool, 0644);
>  static int disable_backlight_sysfs_if = -1;
>  module_param(disable_backlight_sysfs_if, int, 0444);
>  
> +#define REPORT_OUTPUT_KEY_EVENTS		0x01
> +#define REPORT_BRIGHTNESS_KEY_EVENTS		0x02
> +static int report_key_events = -1;
> +module_param(report_key_events, int, 0644);
> +MODULE_PARM_DESC(report_key_events,
> +	"0: none, 1: output changes, 2: brightness changes, 3: all");
> +

-1 is default value? Should not be it 3? Or -1 as some default which use
quirks?

>  static bool device_id_scheme = false;
>  module_param(device_id_scheme, bool, 0444);
>  
> @@ -1480,7 +1487,7 @@ static void acpi_video_bus_notify(struct acpi_device *device, u32 event)
>  		/* Something vetoed the keypress. */
>  		keycode = 0;
>  
> -	if (keycode) {
> +	if (keycode && (report_key_events & REPORT_OUTPUT_KEY_EVENTS)) {
>  		input_report_key(input, keycode, 1);
>  		input_sync(input);
>  		input_report_key(input, keycode, 0);
> @@ -1544,7 +1551,7 @@ static void acpi_video_device_notify(acpi_handle handle, u32 event, void *data)
>  
>  	acpi_notifier_call_chain(device, event, 0);
>  
> -	if (keycode) {
> +	if (keycode && (report_key_events & REPORT_BRIGHTNESS_KEY_EVENTS)) {
>  		input_report_key(input, keycode, 1);
>  		input_sync(input);
>  		input_report_key(input, keycode, 0);
> @@ -2080,7 +2087,8 @@ bool acpi_video_handles_brightness_key_presses(void)
>  	have_video_busses = !list_empty(&video_bus_head);
>  	mutex_unlock(&video_list_lock);
>  
> -	return have_video_busses;
> +	return have_video_busses &&
> +	       (report_key_events & REPORT_BRIGHTNESS_KEY_EVENTS);
>  }
>  EXPORT_SYMBOL(acpi_video_handles_brightness_key_presses);
>  
> -- 
> 2.5.0
> 

-- 
Pali Rohár
pali.rohar@gmail.com

Re: Dell Vostro V131 hotkeys revisited

[Hans de Goede]

Hi,

On 17-12-15 19:47, Pali Rohár wrote:
> Hi Hans! See my comments below about your patches.
>
>>  From 9355058f5c1d7c815a293e0c0731d85f0a59b4a1 Mon Sep 17 00:00:00 2001
>> From: Hans de Goede <hdegoede@redhat.com>
>> Date: Thu, 17 Dec 2015 09:59:01 +0100
>> Subject: [PATCH 2/4] dell-wmi: Use acpi_video_handles_brightness_key_presses()
>>
>> Use the new acpi_video_handles_brightness_key_presses function to check
>> if we should report brightness key-presses.
>>
>> This makes the code both easier to read and makes it properly report
>> key-presses when acpi-video is not reporting them for reasons other
>> then the backlight type being vendor.
>>
>> Signed-off-by: Hans de Goede <hdegoede@redhat.com>
>> ---
>>   drivers/platform/x86/dell-wmi.c | 6 ++----
>>   1 file changed, 2 insertions(+), 4 deletions(-)
>>
>> diff --git a/drivers/platform/x86/dell-wmi.c b/drivers/platform/x86/dell-wmi.c
>> index f2d77fe..cb8a9c2 100644
>> --- a/drivers/platform/x86/dell-wmi.c
>> +++ b/drivers/platform/x86/dell-wmi.c
>> @@ -43,8 +43,6 @@ MODULE_LICENSE("GPL");
>>
>>   #define DELL_EVENT_GUID "9DBB5994-A997-11DA-B012-B622A1EF5492"
>>
>> -static int acpi_video;
>> -
>>   MODULE_ALIAS("wmi:"DELL_EVENT_GUID);
>>
>>   /*
>> @@ -159,7 +157,8 @@ static void dell_wmi_process_key(int reported_key)
>>
>>   	/* Don't report brightness notifications that will also come via ACPI */
>>   	if ((key->keycode == KEY_BRIGHTNESSUP ||
>> -	     key->keycode == KEY_BRIGHTNESSDOWN) && acpi_video)
>> +	     key->keycode == KEY_BRIGHTNESSDOWN) &&
>> +	    acpi_video_handles_brightness_key_presses())
>
> I do not like this, because that function uses mutex and is called every
> time when brightness key event is received by wmi notify handler.

Right and this is going to happen 1000-s of times a second so is
really going to be a performance problem (not).

We cannot cache the return value as was being done before because it
can change during startup depending in module loading order (the old
code actually got this somewhat wrong), and taking a mutex in a code-path
which gets executed only once a second tops is really a non issue.

>
>>   		return;
>>
>>   	sparse_keymap_report_entry(dell_wmi_input_dev, key, 1, true);
>> @@ -398,7 +397,6 @@ static int __init dell_wmi_init(void)
>>   	}
>>
>>   	dmi_walk(find_hk_type, NULL);
>> -	acpi_video = acpi_video_get_backlight_type() != acpi_backlight_vendor;
>>
>>   	err = dell_wmi_input_setup();
>>   	if (err)
>> --
>> 2.5.0
>>
>
>>  From 5e7ff99407aeb60c2f1516cdd80d7859646497dd Mon Sep 17 00:00:00 2001
>> From: Hans de Goede <hdegoede@redhat.com>
>> Date: Wed, 16 Dec 2015 11:19:00 +0100
>> Subject: [PATCH 4/4] acpi-video: Add a module option to disable the reporting
>>   of keypresses
>>
>> Add a module option to disable the reporting of keypresses, in some buggy
>> firmware implementatinon, the reported events are wrong. E.g. they lag
>> reality by one event in the case triggering the writing of this patch.
>>
>> In this case it is better to not forward these wrong events to userspace
>> (esp.) when there is another source of the same events which is not buggy.
>>
>> Note this is only intended to work around implementations which send
>> events which are plain wrong. In some cases we get double events, e.g.
>> from both acpi-video and the atkbd driver, in this case acpi-video is
>> considered the canonical source, and the events from the other source
>> should be filtered (using e.g. /lib/udev/hwdb.d/60-keyboard.hwdb).
>>
>> Signed-off-by: Hans de Goede <hdegoede@redhat.com>
>> ---
>>   drivers/acpi/acpi_video.c | 14 +++++++++++---
>>   1 file changed, 11 insertions(+), 3 deletions(-)
>>
>> diff --git a/drivers/acpi/acpi_video.c b/drivers/acpi/acpi_video.c
>> index 2a649f3e..2971154 100644
>> --- a/drivers/acpi/acpi_video.c
>> +++ b/drivers/acpi/acpi_video.c
>> @@ -77,6 +77,13 @@ module_param(allow_duplicates, bool, 0644);
>>   static int disable_backlight_sysfs_if = -1;
>>   module_param(disable_backlight_sysfs_if, int, 0444);
>>
>> +#define REPORT_OUTPUT_KEY_EVENTS		0x01
>> +#define REPORT_BRIGHTNESS_KEY_EVENTS		0x02
>> +static int report_key_events = -1;
>> +module_param(report_key_events, int, 0644);
>> +MODULE_PARM_DESC(report_key_events,
>> +	"0: none, 1: output changes, 2: brightness changes, 3: all");
>> +
>
> -1 is default value? Should not be it 3? Or -1 as some default which use
> quirks?

Right, the -1 is to later detect if the value was overriden from the kernel
cmdline so that we do not apply dmi quirks when the value comes from the
kernel cmdline.


>
>>   static bool device_id_scheme = false;
>>   module_param(device_id_scheme, bool, 0444);
>>
>> @@ -1480,7 +1487,7 @@ static void acpi_video_bus_notify(struct acpi_device *device, u32 event)
>>   		/* Something vetoed the keypress. */
>>   		keycode = 0;
>>
>> -	if (keycode) {
>> +	if (keycode && (report_key_events & REPORT_OUTPUT_KEY_EVENTS)) {
>>   		input_report_key(input, keycode, 1);
>>   		input_sync(input);
>>   		input_report_key(input, keycode, 0);
>> @@ -1544,7 +1551,7 @@ static void acpi_video_device_notify(acpi_handle handle, u32 event, void *data)
>>
>>   	acpi_notifier_call_chain(device, event, 0);
>>
>> -	if (keycode) {
>> +	if (keycode && (report_key_events & REPORT_BRIGHTNESS_KEY_EVENTS)) {
>>   		input_report_key(input, keycode, 1);
>>   		input_sync(input);
>>   		input_report_key(input, keycode, 0);
>> @@ -2080,7 +2087,8 @@ bool acpi_video_handles_brightness_key_presses(void)
>>   	have_video_busses = !list_empty(&video_bus_head);
>>   	mutex_unlock(&video_list_lock);
>>
>> -	return have_video_busses;
>> +	return have_video_busses &&
>> +	       (report_key_events & REPORT_BRIGHTNESS_KEY_EVENTS);
>>   }
>>   EXPORT_SYMBOL(acpi_video_handles_brightness_key_presses);
>>
>> --
>> 2.5.0
>>
>

Regards,

Hans

Re: Dell Vostro V131 hotkeys revisited

[Michał Kępień]

> >To clear things up, here is the current state of affairs:
> >
> >   * acpi_backlight=native solves the flickering issue, but doesn't help
> >     with key event "lagging" after WMI is enabled,
> >
> >   * using the patch provided by Hans (or a similar one), the "lagged"
> >     events can be filtered, leaving key event generation to dell-wmi,
> >
> >   * dell-wmi won't generate events unless acpi_backlight=vendor, which
> >     in turn breaks brightness control due to faulty ASLE requests.
> >
> >To break out of this loop, I suggest that:
> >
> >   * acpi_backlight should default to "native" for Vostro V131, based on
> >     a DMI check,
> 
> Ack.
> 
> >   * brightness key event generation performed by the ACPI video driver
> >     should always be suppressed on Vostro V131, because it's faulty due
> >     to firmware bugs (and correct events will be reported anyway by
> >     either i8042 or WMI),
> 
> s/should always be suppressed/should be suppressed by default/ otherwise
> ack. We can easily do this the same way we currently deal with the
> disable_backlight_sysfs_if option in acpi_video.c
> 
> >   * yet another quirk should be added to dell-wmi, so that brightness
> >     key events are generated not only when acpi_backlight=vendor, but
> >     also when acpi_backlight=native.
> 
> Nack, the real problem here is that checking if acpi_backlight!=vendor
> is the wrong way to check if key event generation should be suppressed.

Well, I'm sure you know better, given that you wrote the code that this
new patch series fixes :)

> This actually reminds me that I've the following item on my
> todo list for a while but I've not gotten around to it yet:
> 
>  -Add an acpi_video_handles_key_presses() helper, and use this where
>   appropriate (dell-wmi and others).
> 
> The mean reason for that item on my todo list was to make code doing
> brigthness key-event suppression more readable. But we can also use
> it for this case, if we check the new video.report_key_events parameter
> in the acpi_video_handles_key_presses() helper, and switch dell-wmi
> over to this helper, things will just work without needing yet another
> quirk in dell-wmi :)
> 
> I've written a patch-set implementing this (attached), this obsoletes
> my previous patch. As before, please test this with:
> 
> acpi_backlight=native video.report_key_events=1
> 
> On the kernel cmdline, we can add a patch adding dmi quirks to make
> those the default later.

I tested the patch series you submitted and it seems to work fine for
me, given that proper kernel parameters are provided.

> For that patch I'm going to need the dmi strings for your laptop,
> can you please do:
> 
> for i in /sys/class/dmi/id/*_*; do echo $i; cat $i; done
> 
> And then include the output in your next mail ? Feel free to leave
> out the serial numbers, asset tags and uuids, those are potentially
> privacy sensitive and I don't need them.

/sys/class/dmi/id/bios_date
06/12/2014
/sys/class/dmi/id/bios_vendor
Dell Inc.
/sys/class/dmi/id/bios_version
A04
/sys/class/dmi/id/board_name
0X3GJK
/sys/class/dmi/id/board_vendor
Dell Inc.
/sys/class/dmi/id/board_version
A04
/sys/class/dmi/id/chassis_type
8
/sys/class/dmi/id/chassis_vendor
Dell Inc.
/sys/class/dmi/id/chassis_version
Not Specified
/sys/class/dmi/id/product_name
Vostro V131
/sys/class/dmi/id/product_version
Not Specified
/sys/class/dmi/id/sys_vendor
Dell Inc.

> >The only downside I see to such a solution is that by default the user
> >would have to use a userspace helper in order for the key events to be
> >translated into brightness changes.  However, if they so desire,
> >acpi_backlight may still be set to "video", which would enable
> >brightness changes to be done by the kernel, though with the flickering
> >effect still in place.  Sounds like a fair choice to me.  What do you
> >think?
> 
> I do not see the need for a userspace helper as a problem, this actually
> is the case on most modern laptops already, as we default to
> acpi_backlight=native there, and that has the same requirement.

Thanks for the clarification.

-- 
Best regards,
Michał Kępień

Re: Dell Vostro V131 hotkeys revisited

[Hans de Goede]

[-- Attachment #1: Type: text/plain, Size: 3855 bytes --]

Hi,

On 18-12-15 08:10, Michał Kępień wrote:
>>> To clear things up, here is the current state of affairs:
>>>
>>>    * acpi_backlight=native solves the flickering issue, but doesn't help
>>>      with key event "lagging" after WMI is enabled,
>>>
>>>    * using the patch provided by Hans (or a similar one), the "lagged"
>>>      events can be filtered, leaving key event generation to dell-wmi,
>>>
>>>    * dell-wmi won't generate events unless acpi_backlight=vendor, which
>>>      in turn breaks brightness control due to faulty ASLE requests.
>>>
>>> To break out of this loop, I suggest that:
>>>
>>>    * acpi_backlight should default to "native" for Vostro V131, based on
>>>      a DMI check,
>>
>> Ack.
>>
>>>    * brightness key event generation performed by the ACPI video driver
>>>      should always be suppressed on Vostro V131, because it's faulty due
>>>      to firmware bugs (and correct events will be reported anyway by
>>>      either i8042 or WMI),
>>
>> s/should always be suppressed/should be suppressed by default/ otherwise
>> ack. We can easily do this the same way we currently deal with the
>> disable_backlight_sysfs_if option in acpi_video.c
>>
>>>    * yet another quirk should be added to dell-wmi, so that brightness
>>>      key events are generated not only when acpi_backlight=vendor, but
>>>      also when acpi_backlight=native.
>>
>> Nack, the real problem here is that checking if acpi_backlight!=vendor
>> is the wrong way to check if key event generation should be suppressed.
>
> Well, I'm sure you know better, given that you wrote the code that this
> new patch series fixes :)
>
>> This actually reminds me that I've the following item on my
>> todo list for a while but I've not gotten around to it yet:
>>
>>   -Add an acpi_video_handles_key_presses() helper, and use this where
>>    appropriate (dell-wmi and others).
>>
>> The mean reason for that item on my todo list was to make code doing
>> brigthness key-event suppression more readable. But we can also use
>> it for this case, if we check the new video.report_key_events parameter
>> in the acpi_video_handles_key_presses() helper, and switch dell-wmi
>> over to this helper, things will just work without needing yet another
>> quirk in dell-wmi :)
>>
>> I've written a patch-set implementing this (attached), this obsoletes
>> my previous patch. As before, please test this with:
>>
>> acpi_backlight=native video.report_key_events=1
>>
>> On the kernel cmdline, we can add a patch adding dmi quirks to make
>> those the default later.
>
> I tested the patch series you submitted and it seems to work fine for
> me, given that proper kernel parameters are provided.
>
>> For that patch I'm going to need the dmi strings for your laptop,
>> can you please do:
>>
>> for i in /sys/class/dmi/id/*_*; do echo $i; cat $i; done
>>
>> And then include the output in your next mail ? Feel free to leave
>> out the serial numbers, asset tags and uuids, those are potentially
>> privacy sensitive and I don't need them.
>
> /sys/class/dmi/id/bios_date
> 06/12/2014
> /sys/class/dmi/id/bios_vendor
> Dell Inc.
> /sys/class/dmi/id/bios_version
> A04
> /sys/class/dmi/id/board_name
> 0X3GJK
> /sys/class/dmi/id/board_vendor
> Dell Inc.
> /sys/class/dmi/id/board_version
> A04
> /sys/class/dmi/id/chassis_type
> 8
> /sys/class/dmi/id/chassis_vendor
> Dell Inc.
> /sys/class/dmi/id/chassis_version
> Not Specified
> /sys/class/dmi/id/product_name
> Vostro V131
> /sys/class/dmi/id/product_version
> Not Specified
> /sys/class/dmi/id/sys_vendor
> Dell Inc.

Thanks for both the testing and the dmi info, attached is a patch
which applies on top of the other 4 which should automatically do the
right thing, can you please test this patch with an "empty" kernel
cmdline, once that bit works I'll post the entire set upstream for
merging.

Regards,

Hans

[-- Attachment #2: 0005-acpi-video-Add-quirks-for-the-Dell-Vostro-V131.patch --]
[-- Type: text/x-patch, Size: 3237 bytes --]

From 3225a9c43a02682e3cae5c02ca6d38e923256de1 Mon Sep 17 00:00:00 2001
From: Hans de Goede <hdegoede@redhat.com>
Date: Fri, 18 Dec 2015 11:36:16 +0100
Subject: [PATCH 5/5] acpi-video: Add quirks for the Dell Vostro V131

The Dell Vostro V131 has an especially broken acpi-video implementation.

The backlight control bits work, but when the brightness is changed via
the acpi-video interface the backlight flickers annoyingly before settling
at the new brightness, switching to using the native interface fixes the
flickering so add a quirk for this (the vendor interface has the same
problem).

Brightness keypresses reported through the acpi-video-bus are also broken,
they get reported one event delayed, so if you press the brightness-up
hotkey on the keyboard nothing happens, then if you press brightness-down,
the previous brightness-up event gets reported. Since the keypresses are
also reported via wmi (if active) and via atkbd (when wmi is not active)
add a quirk to simply filter out the delayed (broken) events.

Signed-off-by: Hans de Goede <hdegoede@redhat.com>
---
 drivers/acpi/acpi_video.c   | 25 +++++++++++++++++++++++++
 drivers/acpi/video_detect.c |  8 ++++++++
 2 files changed, 33 insertions(+)

diff --git a/drivers/acpi/acpi_video.c b/drivers/acpi/acpi_video.c
index 2971154..80b13d4 100644
--- a/drivers/acpi/acpi_video.c
+++ b/drivers/acpi/acpi_video.c
@@ -419,6 +419,13 @@ static int video_enable_only_lcd(const struct dmi_system_id *d)
 	return 0;
 }
 
+static int video_set_report_key_events(const struct dmi_system_id *id)
+{
+	if (report_key_events == -1)
+		report_key_events = (uintptr_t)id->driver_data;
+	return 0;
+}
+
 static struct dmi_system_id video_dmi_table[] = {
 	/*
 	 * Broken _BQC workaround http://bugzilla.kernel.org/show_bug.cgi?id=13121
@@ -507,6 +514,24 @@ static struct dmi_system_id video_dmi_table[] = {
 		DMI_MATCH(DMI_PRODUCT_NAME, "ESPRIMO Mobile M9410"),
 		},
 	},
+	/*
+	 * Some machines report wrong key events on the acpi-bus, suppress
+	 * key event reporting on these.  Note this is only intended to work
+	 * around events which are plain wrong. In some cases we get double
+	 * events, in this case acpi-video is considered the canonical source
+	 * and the events from the other source should be filtered. E.g.
+	 * by calling acpi_video_handles_brightness_key_presses() from the
+	 * vendor acpi/wmi driver or by using /lib/udev/hwdb.d/60-keyboard.hwdb
+	 */
+	{
+	 .callback = video_set_report_key_events,
+	 .driver_data = (void *)((uintptr_t)REPORT_OUTPUT_KEY_EVENTS),
+	 .ident = "Dell Vostro V131",
+	 .matches = {
+		DMI_MATCH(DMI_SYS_VENDOR, "Dell Inc."),
+		DMI_MATCH(DMI_PRODUCT_NAME, "Vostro V131"),
+		},
+	},
 	{}
 };
 
diff --git a/drivers/acpi/video_detect.c b/drivers/acpi/video_detect.c
index daaf1c4..8fe2682 100644
--- a/drivers/acpi/video_detect.c
+++ b/drivers/acpi/video_detect.c
@@ -279,6 +279,14 @@ static const struct dmi_system_id video_detect_dmi_table[] = {
 		DMI_MATCH(DMI_PRODUCT_NAME, "MacBookPro12,1"),
 		},
 	},
+	{
+	 .callback = video_detect_force_native,
+	 .ident = "Dell Vostro V131",
+	 .matches = {
+		DMI_MATCH(DMI_SYS_VENDOR, "Dell Inc."),
+		DMI_MATCH(DMI_PRODUCT_NAME, "Vostro V131"),
+		},
+	},
 	{ },
 };
 
-- 
2.5.0

Re: Dell Vostro V131 hotkeys revisited

[Darren Hart]

On Thu, Dec 17, 2015 at 07:54:35PM +0100, Hans de Goede wrote:
> Hi,
> 
> On 17-12-15 19:47, Pali Rohár wrote:
> >Hi Hans! See my comments below about your patches.

...

> >>@@ -159,7 +157,8 @@ static void dell_wmi_process_key(int reported_key)
> >>
> >>  	/* Don't report brightness notifications that will also come via ACPI */
> >>  	if ((key->keycode == KEY_BRIGHTNESSUP ||
> >>-	     key->keycode == KEY_BRIGHTNESSDOWN) && acpi_video)
> >>+	     key->keycode == KEY_BRIGHTNESSDOWN) &&
> >>+	    acpi_video_handles_brightness_key_presses())
> >
> >I do not like this, because that function uses mutex and is called every
> >time when brightness key event is received by wmi notify handler.
> 
> Right and this is going to happen 1000-s of times a second so is
> really going to be a performance problem (not).
> 
> We cannot cache the return value as was being done before because it
> can change during startup depending in module loading order (the old
> code actually got this somewhat wrong), and taking a mutex in a code-path
> which gets executed only once a second tops is really a non issue.

Right, this is not a hot path, so the mutex is, indeed, not an issue.

-- 
Darren Hart
Intel Open Source Technology Center

Re: Dell Vostro V131 hotkeys revisited

[Pali Rohár]

[-- Attachment #1: Type: Text/Plain, Size: 1394 bytes --]

On Saturday 19 December 2015 01:02:53 Darren Hart wrote:
> On Thu, Dec 17, 2015 at 07:54:35PM +0100, Hans de Goede wrote:
> > Hi,
> > 
> > On 17-12-15 19:47, Pali Rohár wrote:
> > >Hi Hans! See my comments below about your patches.
> 
> ...
> 
> > >>@@ -159,7 +157,8 @@ static void dell_wmi_process_key(int
> > >>reported_key)
> > >>
> > >>  	/* Don't report brightness notifications that will also come
> > >>  	via ACPI */ if ((key->keycode == KEY_BRIGHTNESSUP ||
> > >>
> > >>-	     key->keycode == KEY_BRIGHTNESSDOWN) && acpi_video)
> > >>+	     key->keycode == KEY_BRIGHTNESSDOWN) &&
> > >>+	    acpi_video_handles_brightness_key_presses())
> > >
> > >I do not like this, because that function uses mutex and is called
> > >every time when brightness key event is received by wmi notify
> > >handler.
> > 
> > Right and this is going to happen 1000-s of times a second so is
> > really going to be a performance problem (not).
> > 
> > We cannot cache the return value as was being done before because
> > it can change during startup depending in module loading order
> > (the old code actually got this somewhat wrong), and taking a
> > mutex in a code-path which gets executed only once a second tops
> > is really a non issue.
> 
> Right, this is not a hot path, so the mutex is, indeed, not an issue.

Ok.

-- 
Pali Rohár
pali.rohar@gmail.com

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

Re: Dell Vostro V131 hotkeys revisited

[Michał Kępień]

> Thanks for both the testing and the dmi info, attached is a patch
> which applies on top of the other 4 which should automatically do the
> right thing, can you please test this patch with an "empty" kernel
> cmdline, once that bit works I'll post the entire set upstream for
> merging.

The patch works as expected, thanks!

> From 3225a9c43a02682e3cae5c02ca6d38e923256de1 Mon Sep 17 00:00:00 2001
> From: Hans de Goede <hdegoede@redhat.com>
> Date: Fri, 18 Dec 2015 11:36:16 +0100
> Subject: [PATCH 5/5] acpi-video: Add quirks for the Dell Vostro V131
> 
> The Dell Vostro V131 has an especially broken acpi-video implementation.
> 
> The backlight control bits work, but when the brightness is changed via
> the acpi-video interface the backlight flickers annoyingly before settling
> at the new brightness, switching to using the native interface fixes the
> flickering so add a quirk for this (the vendor interface has the same
> problem).
> 
> Brightness keypresses reported through the acpi-video-bus are also broken,
> they get reported one event delayed, so if you press the brightness-up
> hotkey on the keyboard nothing happens, then if you press brightness-down,
> the previous brightness-up event gets reported. Since the keypresses are
> also reported via wmi (if active) and via atkbd (when wmi is not active)
> add a quirk to simply filter out the delayed (broken) events.

Just my two cents here: those brightness events sourced from acpi-video
are only delayed after the special WMI-enabling SMI is raised.  So if
you boot the kernel today, those events won't be lagged because the
special WMI-enabling SMI isn't merged yet.  Of course, those events are
still just useless duplicates.  Extending the commit message by
including this detail might spare posterity confusion.  It's just a
thought, though.

-- 
Best regards,
Michał Kępień