RE: [PATCH v3 0/4] dell-wmi: Changes in WMI event code handling

[Mario_Limonciello]

> -----Original Message-----
> From: Pali RohÃr [mailto:pali.rohar@xxxxxxxxx]
> Sent: Tuesday, June 21, 2016 1:29 PM
> To: Limonciello, Mario <Mario_Limonciello@xxxxxxxx>
> Cc: dvhart@xxxxxxxxxxxxx; gabriele.mzt@xxxxxxxxx; luto@xxxxxxxxxx;
> alex.hung@xxxxxxxxxxxxx; mjg59@xxxxxxxxxxxxx; kernel@xxxxxxxxxx;
> platform-driver-x86@xxxxxxxxxxxxxxx; linux-kernel@xxxxxxxxxxxxxxx
> Subject: Re: [PATCH v3 0/4] dell-wmi: Changes in WMI event code handling
> 
> On Tuesday 21 June 2016 20:16:09 Mario_Limonciello@xxxxxxxx wrote:
> > > -----Original Message-----
> > > From: Darren Hart [mailto:dvhart@xxxxxxxxxxxxx]
> > > Sent: Tuesday, June 21, 2016 1:06 PM
> > > To: Pali RohÃr <pali.rohar@xxxxxxxxx>
> > > Cc: Gabriele Mazzotta <gabriele.mzt@xxxxxxxxx>; Andy Lutomirski
> > > <luto@xxxxxxxxxx>; Alex Hung <alex.hung@xxxxxxxxxxxxx>; Matthew
> > > Garrett <mjg59@xxxxxxxxxxxxx>; MichaÅ KÄpieÅ <kernel@xxxxxxxxxx>;
> > > Limonciello, Mario <Mario_Limonciello@xxxxxxxx>; platform-driver-
> > > x86@xxxxxxxxxxxxxxx; linux-kernel@xxxxxxxxxxxxxxx
> > > Subject: Re: [PATCH v3 0/4] dell-wmi: Changes in WMI event code
> > > handling
> > >
> > > On Thu, Jun 16, 2016 at 09:33:02AM +0200, Pali RohÃr wrote:
> > > > On Wednesday 15 June 2016 20:19:58 Darren Hart wrote:
> > > > > On Wed, Jun 15, 2016 at 09:49:09PM +0200, Pali RohÃr wrote:
> > > > > > First patch describe problem about 0xe045 code. Second and
> > > > > > third are
> > >
> > > just
> > >
> > > > > > cosmetic and last rework code which processing WMI events. It
> > > > > > should
> > >
> > > be
> > >
> > > > > > properly tested on more Dell machines, to check that
> > > > > > everything is still working correctly.
> > > > >
> > > > > Is this "should be properly tested on more Dell machines" still
> > > > > the case?
> > >
> > > Are
> > >
> > > > > you ready for this to go into linux-next?
> > > >
> > > > Series should be OK, but I would like to see if someone else test
> > > > this series... Gabriele, Alex or Andy? Do you have time?
> > >
> > > Tested on a Dell XPS 13 2016 (9350). All hotkeys appear to work
> > > without warning
> > > messages. I didn't get anything out of Fn-F8 which has a picture of
> > > a laptop and
> > > white screen behind it. Not sure what that is supposed to do - if
> > > it was meant to blank the screen, it did not, perhaps it is meant
> > > to toggle screen outputs... will test that when I have access to
> > > an external display.
> >
> > That key is meant to toggle screen outputs.  I believe it's still
> > done by the EC emitting <super> + p.  If your WM doesn't recognize
> > that, it won't do much, but you can see in xev the key combinations.
> 
> I still do not understand this stupidity, pressing *one* key cause
> emitting two keys to OS and then OS needs to handle combinations of keys
> and acts on it correctly.... (like windows manager)
> 
> Is there some way to disable this insane nonsense activity of BIOS,
> firmware or whatever it is doing in HW to send *one* key scancode when
> pressing *one* key?
> 

I talked to the EC team about this a while back when it was first implemented.
That's not possible without _OSI detection of Linux.  _OSI detection could be 
used to relay to the EC to behave differently, but otherwise the EC will have 
no idea what OS it's on for which way to behave.

I don't remember all the history behind the switch over from a single scan code 
To <super> + P, but I think it's along the lines of Windows 8/Windows 10 allow
you to iterate the display selection menu based upon holding super and pressing
P multiple times and waiting for you to stop.  

Sending a single scan code will change displays immediately, so having the 
EC send super+p unifies the behavior of fn-f8 and super+p.