Re: [PATCH] ACPI: thinkpad-acpi: add thinkpad keys to input.h

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Sat, 26 May 2007, Dmitry Torokhov wrote:
> On Saturday 26 May 2007 13:31, Henrique de Moraes Holschuh wrote:
> > Add hotkeys available in almost all ThinkPads manufactured in the last five
> > years (more than one million machines given the ammount of batteries
> > recalled) to input.h, and make thinkpad-acpi use those instead of issuing
> > KEY_UNKNOWN.
> > 
> > KEY_FN_PAGEDOWN is not ever reported by the ThinkPad firmware due to random
> > bogon-induced stupidity at IBM some years ago, but it is provided because
> > it doesn't make sense to define KEY_FN_PAGEUP and not define
> > KEY_FN_PAGEDOWN at the same time.
> > 
> 
> I am unconvinced that we need new keycodes. Isn't there a better default
> keycodes for these keys? You mentioned that fn+f5 controls radio on many
> thinkpads, why don't you use KEY_WLAN in your keymap?

No can do the KEY-WLAN thing, sorry.  I *don't* have a way to know, unless I
add a model-specific map table to the kernel, and I have been told by
numerous people to don't even try, unless it is for quirks, etc.

Really, what are we to do with that input.h scancode map?  It *IS* supposed
to be absolute, i.e. one is not supposed to reuse keys in there if the
functionality *or* the generic description is not an exact match.  This is
extremely clear, and it makes complete sense from the point of view of
userland: HAL and others can properly assign functions to all scan codes and
it will be always correct.

But then, it is expensive memory-wise, so it is near the current KEY_MAX,
and people are very, very relutant to add another bit to it.

This is definately a ridiculous and aggravating situation, that deserves a
proper fix.  If increasing the scancode table cannot be done (why?), it is
time to stop denying reality, and remove everything after KEY_FN (0x1d0),
and instead give us a block of KEY_HOSTSPECIFIC_* scancodes, from 0x1d0 to
at least 0x1ef.

Given the way that scancode table is being used, it is one way or the other.
Either increase it to KEY_MAX=0x3ff, or do exactly what UNICODE did, give us
a decently sized block of host-specific scancodes, and shunt the problem to
userspace to clean up after.

-- 
  "One disk to rule them all, One disk to find them. One disk to bring
  them all and in the darkness grind them. In the Land of Redmond
  where the shadows lie." -- The Silicon Valley Tarot
  Henrique Holschuh
-
To unsubscribe from this list: send the line "unsubscribe linux-acpi" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[Index of Archives]     [Linux IBM ACPI]     [Linux Power Management]     [Linux Kernel]     [Linux Laptop]     [Kernel Newbies]     [Share Photos]     [Security]     [Netfilter]     [Bugtraq]     [Yosemite News]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Samba]     [Video 4 Linux]     [Device Mapper]     [Linux Resources]

  Powered by Linux