On Wed, Jul 27, 2016 at 06:05:57PM +0200, Pali Rohár wrote:
> On Wednesday 27 July 2016 17:55:09 mario_limoncie...@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?
>
> 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 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?
>
> > 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 suggest not worrying too much about unknown future platforms when it comes to
things like key names, we cannot predict this, and can address it when/if it
becomes a problem.
--
Darren Hart
Intel Open Source Technology Center
