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