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

[<Mario_Limonciello@Dell.com>]

> -----Original Message-----
> From: Pali Rohár [mailto:pali.rohar@gmail.com]
> Sent: Tuesday, June 21, 2016 1:29 PM
> To: Limonciello, Mario <Mario_Limonciello@Dell.com>
> Cc: dvhart@infradead.org; gabriele.mzt@gmail.com; luto@kernel.org;
> alex.hung@canonical.com; mjg59@srcf.ucam.org; kernel@kempniu.pl;
> platform-driver-x86@vger.kernel.org; linux-kernel@vger.kernel.org
> Subject: Re: [PATCH v3 0/4] dell-wmi: Changes in WMI event code handling
> 
> On Tuesday 21 June 2016 20:16:09 Mario_Limonciello@dell.com wrote:
> > > -----Original Message-----
> > > From: Darren Hart [mailto:dvhart@infradead.org]
> > > Sent: Tuesday, June 21, 2016 1:06 PM
> > > To: Pali Rohár <pali.rohar@gmail.com>
> > > Cc: Gabriele Mazzotta <gabriele.mzt@gmail.com>; Andy Lutomirski
> > > <luto@kernel.org>; Alex Hung <alex.hung@canonical.com>; Matthew
> > > Garrett <mjg59@srcf.ucam.org>; Michał Kępień <kernel@kempniu.pl>;
> > > Limonciello, Mario <Mario_Limonciello@Dell.com>; platform-driver-
> > > x86@vger.kernel.org; linux-kernel@vger.kernel.org
> > > 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.