> -----Original Message----- > From: Pali Rohár [mailto:pali.ro...@gmail.com] > Sent: Tuesday, June 21, 2016 1:29 PM > To: Limonciello, Mario <mario_limoncie...@dell.com> > Cc: dvh...@infradead.org; gabriele....@gmail.com; l...@kernel.org; > alex.h...@canonical.com; mj...@srcf.ucam.org; ker...@kempniu.pl; > platform-driver-...@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_limoncie...@dell.com wrote: > > > -----Original Message----- > > > From: Darren Hart [mailto:dvh...@infradead.org] > > > Sent: Tuesday, June 21, 2016 1:06 PM > > > To: Pali Rohár <pali.ro...@gmail.com> > > > Cc: Gabriele Mazzotta <gabriele....@gmail.com>; Andy Lutomirski > > > <l...@kernel.org>; Alex Hung <alex.h...@canonical.com>; Matthew > > > Garrett <mj...@srcf.ucam.org>; Michał Kępień <ker...@kempniu.pl>; > > > Limonciello, Mario <mario_limoncie...@dell.com>; platform-driver- > > > x...@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.
