All of lore.kernel.org
 help / color / mirror / Atom feed
From: <Mario_Limonciello@Dell.com>
To: <pali.rohar@gmail.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
Date: Wed, 22 Jun 2016 13:20:12 +0000	[thread overview]
Message-ID: <1402523c32044788ab64db22d075fc83@ausx13mpc124.AMER.DELL.COM> (raw)
In-Reply-To: <20160622103028.GB29844@pali>

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

WARNING: multiple messages have this Message-ID (diff)
From: <Mario_Limonciello@Dell.com>
To: pali.rohar@gmail.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
Date: Wed, 22 Jun 2016 13:20:12 +0000	[thread overview]
Message-ID: <1402523c32044788ab64db22d075fc83@ausx13mpc124.AMER.DELL.COM> (raw)
In-Reply-To: <20160622103028.GB29844@pali>

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

  reply	other threads:[~2016-06-22 13:20 UTC|newest]

Thread overview: 21+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-06-15 19:49 [PATCH v3 0/4] dell-wmi: Changes in WMI event code handling Pali Rohár
2016-06-15 19:49 ` [PATCH v3 1/4] dell-wmi: Ignore WMI event code 0xe045 Pali Rohár
2016-06-15 19:49   ` Pali Rohár
2016-06-15 19:49 ` [PATCH v3 2/4] dell-wmi: Sort WMI event codes and update comments Pali Rohár
2016-06-15 19:49 ` [PATCH v3 3/4] dell-wmi: Add information about other WMI event codes Pali Rohár
2016-06-15 19:49 ` [PATCH v3 4/4] dell-wmi: Generate one sparse keymap for all machines Pali Rohár
2016-06-16  3:19 ` [PATCH v3 0/4] dell-wmi: Changes in WMI event code handling Darren Hart
2016-06-16  7:33   ` Pali Rohár
2016-06-16 23:01     ` Gabriele Mazzotta
2016-06-21 16:27     ` Darren Hart
2016-06-21 18:06     ` Darren Hart
2016-06-21 18:16       ` Mario_Limonciello
2016-06-21 18:16         ` Mario_Limonciello
2016-06-21 18:29         ` Pali Rohár
2016-06-21 18:33           ` Matthew Garrett
2016-06-22 10:31             ` Pali Rohár
2016-06-21 18:37           ` Mario_Limonciello
2016-06-21 18:37             ` Mario_Limonciello
2016-06-22 10:30             ` Pali Rohár
2016-06-22 13:20               ` Mario_Limonciello [this message]
2016-06-22 13:20                 ` Mario_Limonciello

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=1402523c32044788ab64db22d075fc83@ausx13mpc124.AMER.DELL.COM \
    --to=mario_limonciello@dell.com \
    --cc=alex.hung@canonical.com \
    --cc=dvhart@infradead.org \
    --cc=gabriele.mzt@gmail.com \
    --cc=kernel@kempniu.pl \
    --cc=linux-kernel@vger.kernel.org \
    --cc=luto@kernel.org \
    --cc=mjg59@srcf.ucam.org \
    --cc=pali.rohar@gmail.com \
    --cc=platform-driver-x86@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.