> -----Original Message----- > From: Pali Rohár [mailto:pali.rohar@xxxxxxxxx] > Sent: Wednesday, July 27, 2016 11:06 AM > To: Limonciello, Mario <Mario_Limonciello@xxxxxxxx> > Cc: dvhart@xxxxxxxxxxxxx; linux-kernel@xxxxxxxxxxxxxxx; platform-driver- > x86@xxxxxxxxxxxxxxx > Subject: Re: [PATCH] dell-wmi: Add events created by Dell Rugged 2-in-1s > > On Wednesday 27 July 2016 17:55:09 Mario_Limonciello@xxxxxxxx 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? > > 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. > > 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... I'll ask around. It's not immediately obvious to me though, maybe from old specs? > > > 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. > > > > >/* Wifi Catcher */ > > > > > > { KE_KEY, 0xe011, { KEY_PROG2 } }, > > > > 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. > > Anyway, what is "Wifi Catcher"? HW switch buttton which enable/disable wifi? > Or something else? > 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. When the machine was on, it would open up the applet that let you configure the behavior for the switch in S3. > > So there should be no "real" clash here. > > 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... I agree with Darren here. 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. Maybe it's time to think of another way to get this information to userspace rather that always translating them into key codes? 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. 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. > > > > But probably we do not have better names... > > > > 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". > > Probably yes, as I wrote I do not have in my mind better names for now. > OK, I'll resend with the cosmetic tabbing change and a clearer description, but keep the same mapping. ��.n��������+%������w��{.n������_���v��z����n�r������&��z�ޗ�zf���h���~����������_��+v���)ߣ�
