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

[Pali RohÃr]

On Tuesday 21 June 2016 18:37:19 Mario_Limonciello@xxxxxxxx wrote:
> > -----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.

ACPI code should not behave differently for different operating systems.
If there is bug in kernel, report bug to kernel, subtree maintainer for
fixing it. And not doing workaround and hacks in ACPI.

In this case there could be (standardized) ACPI function for turning off
this nonsense functionality and supported kernel could call it.

Is not there such ACPI function? Or Dell specific SMBIOS call?

> 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.  

Windows systems doing stupid things and fixing their bugs in ACPI is
wrong. It broke for example this key on all other systems (Linux too).

> 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.

And due to this OS/kernel cannot distinguish between Fn-F8 and Super+p
keys...

-- 
Pali RohÃr
pali.rohar@xxxxxxxxx