From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751616AbcFVNUn (ORCPT ); Wed, 22 Jun 2016 09:20:43 -0400 Received: from ausxippc101.us.dell.com ([143.166.85.207]:43158 "EHLO ausxippc101.us.dell.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750970AbcFVNUl (ORCPT ); Wed, 22 Jun 2016 09:20:41 -0400 DomainKey-Signature: s=smtpout; d=dell.com; c=nofws; q=dns; h=X-LoopCount0:X-IronPort-AV:From:To:CC:Subject: Thread-Topic:Thread-Index:Date:Message-ID:References: In-Reply-To:Accept-Language:Content-Language: X-MS-Has-Attach:X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader:x-originating-ip: Content-Type:Content-Transfer-Encoding:MIME-Version: Return-Path; b=wzgKCynXagZhTXes1JyqvPlFxK1nM+YVv9xNxLgN1ALeKNdf3aIzQqp5 cgodSPB1BTGalWoeTo9QXGaYmRsgJ7t7Py8JSg+pMue9syk8Mspl7C1ov 6fahv77hVT17g4/+DmoC9UmB9CzNtls8m3QkvB5yjPEMtIXPRTT1AmSam 8=; X-LoopCount0: from 10.175.216.250 X-IronPort-AV: E=Sophos;i="5.26,509,1459832400"; d="scan'208";a="814615938" From: To: CC: , , , , , , , Subject: RE: [PATCH v3 0/4] dell-wmi: Changes in WMI event code handling Thread-Topic: [PATCH v3 0/4] dell-wmi: Changes in WMI event code handling Thread-Index: AQHRxz8G/UEeb8RPtE+qKVbKdO11kp/rwT8AgABGtQCACIyVgP//rosQgABX7oD//6yD4IABX/8A///LG2A= Date: Wed, 22 Jun 2016 13:20:12 +0000 Message-ID: <1402523c32044788ab64db22d075fc83@ausx13mpc124.AMER.DELL.COM> References: <1466020153-10877-1-git-send-email-pali.rohar@gmail.com> <20160621180617.GD3685@f23x64.localdomain> <201606212029.28029@pali> <284b4ec68aae43e6ab6a257574d5b58a@ausx13mpc120.AMER.DELL.COM> <20160622103028.GB29844@pali> In-Reply-To: <20160622103028.GB29844@pali> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.132.208.210] Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from base64 to 8bit by mail.home.local id u5MDKnZ6009791 > > 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 + 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.