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