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

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <1402523c32044788ab64db22d075fc83@ausx13mpc124.AMER.DELL.COM>
Date:	Wed, 22 Jun 2016 13:20:12 +0000
From:	<Mario_Limonciello@...l.com>
To:	<pali.rohar@...il.com>
CC:	<dvhart@...radead.org>, <gabriele.mzt@...il.com>,
	<luto@...nel.org>, <alex.hung@...onical.com>,
	<mjg59@...f.ucam.org>, <kernel@...pniu.pl>,
	<platform-driver-x86@...r.kernel.org>,
	<linux-kernel@...r.kernel.org>
Subject: RE: [PATCH v3 0/4] dell-wmi: Changes in WMI event code handling

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

This isn't ACPI code, this is EC code.

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

I think you might have interpreted my response differently than I intended.
I know that the Linux kernel has chosen to respond as the latest Windows
version for _OSI, and that's why it's not possible to do a different behavior
for Linux and Windows.

If there is a desire to go down the route of having different behavior for 
what the EC does in different OS'es, _OSI is only way to accomplish this.

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

I'm not aware of any standard ACPI function or Dell function for this type 
of request.  Last time this was discussed I was told the EC would emit 
single display scan code for Windows < 7 (as Windows Vista and earlier
doesn't support super + p).  Windows > 7 (as detected  by _OSI and 
passed to EC) will emit super + p.

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

There's no bug in this behavior, it's intended behavior.

Like I said, previously display switch hotkey would immediately cycle outputs.
The behavior followed with super + p allows for OS to toggle through a menu
of outputs in this OS.

" Toggle through the projection mode (new with Windows 7)."
https://msdn.microsoft.com/en-us/library/ms971323.aspx

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

Which is intended behavior from system designer's perspective.