linux-kernel - Re: [PATCH] dell-wmi: add module param to control Dell Instant Launch hotkey processing

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20151130143756.GC29576@pali>
Date:	Mon, 30 Nov 2015 15:37:56 +0100
From:	Pali Rohár <pali.rohar@...il.com>
To:	Michał Kępień <kernel@...pniu.pl>
Cc:	Matthew Garrett <mjg59@...f.ucam.org>,
	Darren Hart <dvhart@...radead.org>,
	platform-driver-x86@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH] dell-wmi: add module param to control Dell Instant
 Launch hotkey processing

On Monday 30 November 2015 15:14:00 Michał Kępień wrote:
> Hi Pali,
> 
> Thanks again for your efforts.
> 
> > $ sudo /usr/bin/input-events 4
> > /dev/input/event4
> >     bustype : BUS_I8042
> >     vendor  : 0x1
> >     product : 0x1
> >     version : 43841
> >     name    : "AT Translated Set 2 keyboard"
> >     phys    : "isa0060/serio0/input0"
> >     bits ev : EV_SYN EV_KEY EV_MSC EV_LED EV_REP
> > 
> > waiting for events
> > 
> > 10:26:29.945739: EV_MSC MSC_SCAN 219
> > 10:26:29.945739: EV_KEY KEY_LEFTMETA (0x7d) pressed
> > 10:26:29.945739: EV_SYN code=0 value=0
> > 10:26:29.946468: EV_MSC MSC_SCAN 45
> > 10:26:29.946468: EV_KEY KEY_X (0x2d) pressed
> > 10:26:29.946468: EV_SYN code=0 value=0
> > 10:26:29.948469: EV_MSC MSC_SCAN 45
> > 10:26:29.948469: EV_KEY KEY_X (0x2d) released
> > 10:26:29.948469: EV_SYN code=0 value=0
> > 10:26:29.951473: EV_MSC MSC_SCAN 219
> > 10:26:29.951473: EV_KEY KEY_LEFTMETA (0x7d) released
> > 10:26:29.951473: EV_SYN code=0 value=0
> > x
> > 
> > (Press+release first key with name "Windows Mobility Center control")
> > (key X was printed to console)
> > 
> > 10:26:32.898689: EV_MSC MSC_SCAN 133
> > 10:26:32.898689: EV_KEY KEY_BRIGHTNESSDOWN (0xe0) pressed
> > 10:26:32.898689: EV_SYN code=0 value=0
> > 10:26:32.898730: EV_MSC MSC_SCAN 133
> > 10:26:32.898730: EV_KEY KEY_BRIGHTNESSDOWN (0xe0) released
> > 10:26:32.898730: EV_SYN code=0 value=0
> > 
> > (Press+release second key with name "Instant launch control")
> > 
> > 10:26:35.090018: EV_MSC MSC_SCAN 132
> > 10:26:35.090018: EV_KEY KEY_NEXTSONG (0xa3) pressed
> > 10:26:35.090018: EV_SYN code=0 value=0
> > 10:26:35.092765: EV_MSC MSC_SCAN 132
> > 10:26:35.092765: EV_KEY KEY_NEXTSONG (0xa3) released
> > 10:26:35.092765: EV_SYN code=0 value=0
> > 
> > (Press+release third key with name "Audio control-panel control")
> > 
> > As you can see events are send also via keyboard controller!
> > 
> > Key codes are configured by userspace (udev/systemd) and looks like 
> > there is bug in userspace rules (reason for brightnes or nextsong), see:
> > https://wiki.ubuntu.com/HardwareSupport/Machines/Laptops/Dell/XPS/15
> 
> Well, the V131 also sends its second hotkey (Dell Support Center) as a
> scancode, which can be mapped in userspace.  But I fail to understand
> why this would be problematic, see below.
> 

Same reason what you wrote below... On some machines WMI event must be
ignored and on other must be sent to userspace.

The best would be if embedded controller could be configured to send
events via i8042 bus...

I'm starting to thing that blacklist or whitelist of machines is needed
to collect. And via it decide if WMI event will be accepted or dropped.

> > So it is not easy to make both machines (Dell XPS L502X and Dell Vostro 
> > V131) works correctly :-( At least I do not see how.
> 
> As far as I understand, it's not the keyboard events that are a problem
> for us, it's the WMI events, because some models generate them along
> with the scancode (L502x) while on others the WMI event is the only
> notification the OS can get that the hotkey was pressed (V131).  So the
> only sparse keymap entry which has to vary between models seems to be
> the 0xe025 entry (obviously that's just the current state of our
> knowledge, not vendor-provided information).  That is why I submitted a
> patch attempting to resolve this conflict.
> 
> If you disagree with the above, could you please elaborate?
> 
> > And that mapping "Windows Mobility Center control" key to combination of 
> > two keys (KEY_LEFTMETA + X) is some total stupid nonsense...
> 
> Well, it is unfortunate, but at least I can map it to what I please in
> my window manager.  What I am really struggling to understand is why on
> earth would one employ something as complicated as ACPI/WMI for handling
> keypresses.  Not to mention requiring cryptic SMI calls for enabling the
> notifications in the first place.
> 

I remember that on older Acer laptops was needed to send some PS/2
command to enable additional Fn keys to generate scan codes... Dell just
upgraded this "feature" that OS needs to send SMI call!

-- 
Pali Rohár
pali.rohar@...il.com
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/