From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S932149AbcFUSha (ORCPT ); Tue, 21 Jun 2016 14:37:30 -0400 Received: from ausxipps301.us.dell.com ([143.166.148.223]:30710 "EHLO ausxipps301.us.dell.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752010AbcFUSh1 (ORCPT ); Tue, 21 Jun 2016 14:37:27 -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=GAJLkYZDdrngKf29ajfs9xT7qZLPCOfOLhQYLuSGifGIqdfz1MxNBpKs eMcFcTyJI5gI8iFXqs6D2O/ZAyFOL+mMzCXT8vEb5hFWkPeo4Yk7V14Cv lhL1gRsIOvSpVUle8aeZk54lh8B+v6Pw/D6TaAhjK2R7EbCSDnTWjvqF1 I=; X-LoopCount0: from 10.175.216.250 X-IronPort-AV: E=Sophos;i="5.26,505,1459832400"; d="scan'208";a="808871388" 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//6yD4A== Date: Tue, 21 Jun 2016 18:37:19 +0000 Message-ID: <284b4ec68aae43e6ab6a257574d5b58a@ausx13mpc120.AMER.DELL.COM> References: <1466020153-10877-1-git-send-email-pali.rohar@gmail.com> <20160621180617.GD3685@f23x64.localdomain> <201606212029.28029@pali> In-Reply-To: <201606212029.28029@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.208.89.195] 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 u5LIbYQ8003922 > -----Original Message----- > From: Pali Rohár [mailto:pali.rohar@gmail.com] > Sent: Tuesday, June 21, 2016 1:29 PM > To: Limonciello, Mario > 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 > > On Tuesday 21 June 2016 20:16:09 Mario_Limonciello@dell.com wrote: > > > -----Original Message----- > > > From: Darren Hart [mailto:dvhart@infradead.org] > > > Sent: Tuesday, June 21, 2016 1:06 PM > > > To: Pali Rohár > > > Cc: Gabriele Mazzotta ; Andy Lutomirski > > > ; Alex Hung ; Matthew > > > Garrett ; Michał Kępień ; > > > Limonciello, Mario ; 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 > > > > > > 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 + 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. 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. 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.