On Wed, 30 May 2007, Dmitry Torokhov wrote:

quoted

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.

quoted

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 :-)

quoted

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?

quoted

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.

quoted

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.

quoted

quoted

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.

quoted

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.

quoted

quoted

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...]

quoted

quoted

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).

quoted

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