> -----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. ��.n��������+%������w��{.n������_���v��z����n�r������&��z�ޗ�zf���h���~����������_��+v���)ߣ�
