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

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

 



On Wed, 30 May 2007, Dmitry Torokhov wrote:
> >1. Generate SOMETHING that has an undefined meaning or function, but which
> >is unique for that keyboard (KEY_PROG/KEY_HOSTSPECIFIC)
> 
> How do you guarantee that KEY_PROG* is unique for the keyboard? What
> do you do if you have 2 devices generating KEY_PROG1?

It is trivial to guarantee that KEY_PROG is unique for a single input device
(keyboard), but it certainly won't work across multiple devices.  Userspace
has to know what kind of input device it is talking to to map them to
something, but since the input layer already provides this information, I
was not going to raise a fuss about it.  I figure it is the price of not
increasing even more the keycode table.

> >2. Generate SOMETHING that has a non-specific function, but a well defined
> >meaning (KEY_FN_F1)
> 
> And we have plenty of those.

Yeah, but not enough of them or I would not have asked for five more :-)

> >3. Do nothing.
> 
> Well, probably not nothing. Map it to KEY_UNKNOWN and have userspace
> listen to such events and inform user when it presses such a key that
> such and such happened and tell him how to map it to something useful.

Not optimal, but certainly much better than "do nothing".  I will go with
this one, if I can't have my extra FN keys or PROG keys.

That said, how is one to know which hardware key was translated to
KEY_UNKNOWN, so that he can inform the user to remap that key?  Should I
send another event together with KEY_UNKNOWN that has the raw keycode? Which
one?

> >I *REALLY* do not like (3), and so far I have not seen a single good
> >technical reason to go with it.
> 
> Reasons: do not require expaning current keymap preserving space for
> more useful keycodes.

We should either reclaim space then (remove all of KEY_FN_* and make them
KEY_PROG* generic stuff), or double the entire keycode space (add one bit to
KEY_MAX) so that new keycodes can be added for a while.  Declaring a keycode
crunch on drivers when one gets close to exausting each bit of KEY_MAX is
not a solution IMHO.

> > From the technically sound ones, you need
> >to either have the keycodes you need for (2) (i.e. KEY_FN_BACKSPACE), or a
> >big enough set of keycodes to use (1) (i.e. KEY_PROG5..KEY_PROGn, where n
> >should probably be at least 8).
> 
> Why 8? Why not 16? Or 32 just to make sure?

Eight is a bare minimum (and enough for my needs if the KEY_FN already there
don't go away :p), but I already told you that if it were up to me, I'd
convert all of FN_ to such codes, and cover 0x1d0 to 0x1ef with them, which
gives us 32 generic codes.  We would have 36 KEY_PROG then, which hopefully
would be enough for a while.

> >> I really don't like KEY_FN_F1..KEY_FN_BACKSPACE either. What are they
> >> supposed to do? Just being an unique value to be mapped onto something
> >> useful? But why not use that useful keycode to begin with?
> >
> >Yes, just an unique value to be mapped onto something useful, by something
> >in userspace.  Just like KEY_PROG, actually.
> 
> In _every_ program that gets events directly?

Yes.  It is not nearly as nice as functional key codes (like KEY_WLAN), but
it is better than KEY_UNKONWN or wrong keys.   Of course, if you *know* a
key's function, you use that.

> >One can't use a "useful keycode" for two reasons:
> >
> >1.      Because the key has no set function (it is unmarked)
> >2.      Because it has, or could have, a set function, but we have no clue
> >which is it.
> 
> KEY_UNKNOWN then.

KEY_UNKNOWN requires that userspace remap it for it to be usable.

> >> I'd rather leave the keys unmapped and rely on initsripts (possibly
> >> with help from distributions vendors) to load proper keymap then add
> >> something that must be retranslated over and over again.
> >
> >I don't.  I can live with it, of course, but if we are going to go that 
> >way,
> >what IS the excuse for a big lot of the keys already in input.h?  We have
> >been adding the unique keycodes and functional keycodes because it is
> >*useful*.
> 
> Because they most of them describe an expected _action_ that would
> happend after keypress.

But why can't we get those that do NOT do that and are not around most
keyboards to be completely generic, then?

> [...skipped...]
> >
> >> And what are their intended functions would be? How KEY_VENDORHOMEPAGE
> >> is different from KEY_HOMEPAGE?
> >
> >KEY_VENDORHOMEPAGE is exactly that.  It is marked with the vendor's name.
> >KEY_HOMEPAGE has a defined function inherited from that other O.S. which is
> >to open up the default browser on the default "homepage".  I can easily see
> >both keys existing on a system.
> >
> 
> OK, right now we have:
> 
> KEY_WWW
> KEY_VENDOR
> KEY_HOMEPAGE
> 
> defines in input.h. Are you sayign that none of these would suit?

KEY_VENDOR would work for me.  I had not searched around for one yet, and I
would have found it out before sending you a patch asking for
KEY_VENDORHOMEPAGE.

KEY_PROG, on the other hand, looked to me like an function (like program
macro or whatever).

> >As for stuff like KEY_FN_BACKSPACE, well, I don't really care, as long as I
> >have *something* unique and not incorrect to use.  But if we are not going
> >to add extra KEY_FN_ keycodes, why don't we just convert them all to
> >KEY_PROG, so that they can be useful to all and not just to people who have
> >FN_<whatever> keys?
> 
> We could add aliases if you really want...

If you add aliases to the whole FN block, and add a few more KEY_PROG to
fill the holes so that the entire 0x1d0-0x1ef range is usable by
thinkpad-acpi, that would be enough for me.  I am not sure how that is any
better (or any worse) than the other possible solutions that change input.h,
though.

> Can you tell me on _your_ thinkpad what markings you have? I mean

http://www.thinkwiki.org/wiki/Default_meanings_of_special_keys

Mine is a T43.  That table is not 100% correct, the T43 doesn't label the
fn+f8 or fn+f9 keys.  And it is still very very much incomplete.

> there should be a common pattern on thinkpads and the rest may be
> guessed (you mentioned that FN-F5 is used to turn off radio quite
> often so if thinkpad driver detects radio switch it makes sence to
> just go ahead and mark FN-F5 as KEY_WLAN, doesn't it?)

For that particular key, yes... until we find out a thinkpad that has that
key elsewhere.

-- 
  "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