From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1758238AbcG0UPT (ORCPT ); Wed, 27 Jul 2016 16:15:19 -0400 Received: from mail-wm0-f68.google.com ([74.125.82.68]:34287 "EHLO mail-wm0-f68.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752018AbcG0UPQ (ORCPT ); Wed, 27 Jul 2016 16:15:16 -0400 From: Pali =?utf-8?q?Roh=C3=A1r?= To: Mario_Limonciello@dell.com Subject: Re: [PATCH] dell-wmi: Add events created by Dell Rugged 2-in-1s Date: Wed, 27 Jul 2016 22:15:12 +0200 User-Agent: KMail/1.13.7 (Linux/3.13.0-92-generic; KDE/4.14.2; x86_64; ; ) Cc: dvhart@infradead.org, linux-kernel@vger.kernel.org, platform-driver-x86@vger.kernel.org References: <1469217684-6643-1-git-send-email-mario_limonciello@dell.com> <201607271805.57123@pali> <13ec06e37e284263b6bf4fe4a6a04a78@ausx13mpc120.AMER.DELL.COM> In-Reply-To: <13ec06e37e284263b6bf4fe4a6a04a78@ausx13mpc120.AMER.DELL.COM> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart2220508.SY45cCOlcm"; protocol="application/pgp-signature"; micalg=pgp-sha1 Content-Transfer-Encoding: 7bit Message-Id: <201607272215.12385@pali> Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org --nextPart2220508.SY45cCOlcm Content-Type: Text/Plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable On Wednesday 27 July 2016 21:03:57 Mario_Limonciello@dell.com wrote: > > -----Original Message----- > > From: Pali Roh=C3=A1r [mailto:pali.rohar@gmail.com] > > Sent: Wednesday, July 27, 2016 11:06 AM > > To: Limonciello, Mario > > Cc: dvhart@infradead.org; linux-kernel@vger.kernel.org; > > platform-driver- x86@vger.kernel.org > > Subject: Re: [PATCH] dell-wmi: Add events created by Dell Rugged > > 2-in-1s > >=20 > > On Wednesday 27 July 2016 17:55:09 Mario_Limonciello@dell.com wrote: > > > > Hi! I'm not sure if KEY_PROG1/2/3 are good names here as we > > > > already use > > > > > > > >those for other actions (see bios_to_linux_keycode). Also there > > > >is: > > > I had missed this, do you have some recommendations on what would > > > be better codes to map this to? > >=20 > > Problem is that I do not know when those KEY_PROG keys from > > bios_to_linux_keycode table are emitted. There are missing comments > > or description. > >=20 > > Are you able to find out description for all those keys in that > > table? Maybe now (when linux key constants are extended), there > > could be better candidates... >=20 > I'll ask around. It's not immediately obvious to me though, maybe > from old specs? Do not know if it is old. At least some codes from it are used on my=20 E6440 machine. Table itself was added by Rezwanul Kabir in this commit: https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id= =3D5ea2559726b786283236835dc2905c23b36ac91c Maybe commit message could help you to indentify what it is... > > > I'll double check what the things that "were" mapping to > > > KEY_PROG1 etc actually were. This might be a case of an > > > expected clash if the functions aren't in current generations. > > >=20 > > > >/* Wifi Catcher */ > > > > > > > > { KE_KEY, 0xe011, { KEY_PROG2 } }, > > >=20 > > > It's worth mentioning that Wifi Catcher hasn't been used for any > > > Dell laptops for a handful generations. The rugged 2in1's are > > > current generation that have these programmable buttons and > > > don't have wifi catcher. > >=20 > > Anyway, what is "Wifi Catcher"? HW switch buttton which > > enable/disable wifi? Or something else? >=20 > Wifi catcher was a special hardware switch slider switch. When the > machine was turned in S3 the sliding the switch beyond the on > position would scan for available wifi networks and light up an LED > if some from your predefined list were found. >=20 > When the machine was on, it would open up the applet that let you > configure the behavior for the switch in S3. Hm... maybe it better fit KEY_WLAN then? Just speculation. > > > So there should be no "real" clash here. > >=20 > > Problem can be in future. This driver is unified for all Dell > > products with wmi interface and so future product could do some > > nasty things... >=20 > I agree with Darren here. >=20 > At least on Dell side we're creating new codes for "new" buttons and > the limitation is really on the kernel side for how many KEY_PROG# > or similar functions they can be re-assigned to. Ok. > Maybe it's time to think of another way to get this information to > userspace rather that always translating them into key codes? If event is generated by pressing key, button or hw switch, then input=20 key is correct way. If there is no KEY define which fit for new vendor=20 hw button, then I think we should start discussion with input subsystem=20 how to handle such situation. > There's a lot that are marked as KE_IGNORE because the kernel can't > do anything interesting with them as no 1-1 mapping exists to a > keycode. Most marked as KE_IGNORE are because duplicate event is sent via=20 keyboard controller or via other subsystem (e.g. rfkill). But events which are not keys or buttons should not be sent via input=20 devices. At least I think it is against usage of input devices. Events like "battery was removed" or "keyboard backlight was changed" or=20 "battery lifetime decreased under X %" can be useful for userspace=20 applications. I agree. But I think we do not have any subsystem or=20 interface for sending them from kernel to userspace. If we start talking about creating interface for it, I would rather see=20 something more generic, not Dell-only specific or created specially for=20 Dell machines which will not fit for others... Darren, what do you think about it? > Those could still be passed on somehow to have things like > gnome-settings-daemon or other userspace tools to react however and > show a notification. Yes, that can be useful and with some genetic way, other hardware can=20 benefit from it too... > > > > But probably we do not have better names... > > >=20 > > > In this particular case, I was thinking PROG1/2/3 were really the > > > best option and would be most intuitive because the keys really > > > are labels "P1" "P2" and "P3". > >=20 > > Probably yes, as I wrote I do not have in my mind better names for > > now. >=20 > OK, I'll resend with the cosmetic tabbing change and a clearer > description, but keep the same mapping. Ok. =2D-=20 Pali Roh=C3=A1r pali.rohar@gmail.com --nextPart2220508.SY45cCOlcm Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) iEYEABECAAYFAleZFlAACgkQi/DJPQPkQ1La8gCdFQJwVuDhOkHECO+q/hnqHYeD 1LwAn0qtFbwsGE4y2flHwxdpGbJST8i9 =kw5P -----END PGP SIGNATURE----- --nextPart2220508.SY45cCOlcm--