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.
next prev parent 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: linkBe 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.