Re: [gtk-vnc-devel] [PATCH][RFC] Support for ExtendedKeyEvent client message

[Markus Armbruster <armbru redhat com>]

Anthony Liguori <anthony codemonkey ws> writes:

> Markus Armbruster wrote:
[...]
>> In the Xen PVFB framebuffer, we need to convert the key we read from
>> the wire to a Linux input layer key code.  Easy enough for PC key
>> codes, just reuse the code that does that for a real keyboard.
>>
>> But let's look at the bigger picture.  Extending the VNC's RFB
>> protocol to pass some kind of key code is a good idea.  I'd consider
>> it a protocol bug fix, in fact.  However, I'd like us to use a
>> reasonably well-defined, reasonably universal wire key encoding.
>>
>> What's a key code?  It's an identification of a key on a keyboard.
>> The are many different keyboards in use, and almost as many encodings.
>> The ol' PC key encoding is merely the most common one.
>>
>> Mapping between different encodings is straightforward (if tedious),
>> until you encounter a key that doesn't exist in the target key code.
>> Try mapping one of those fancy workstation keyboards of old to PC key
>> encoding.
>>
>> Mapping from a real keyboard's key code to Linux input layer key code
>> should be particularly easy, as you can just steal that code from
>> Linux[*].
>>
>> Therefore, my first choice would be Linux input layer key codes.  It's
>> reasonably universal, because it supports a wide range of real
>> keyboards, and it's reasonably well-defined.
>>   
>
> The Linux input layer key codes are unique.  That is, KEY_A should
> alway represent an 'a' key press regardless of the keyboard.  Since
> VNC's key codes are also unique you should be able to create a static
> 1-1 mapping between them and it should Just Work.
>
> On the other hand, PC key codes are not unique.  Some keyboards will
> generate a 65 for the 'a' key while others will generate a 65 for the
> k' key (not really, but bear with me).  The only way to translate from
> VNC key codes (which are unique) to PC key codes (which aren't) is to
> use a mapping based on what the actual keyboard is.
>
> The whole point of this patch is to pass PC key codes directly through
> such that the above mapping isn't needed.  Unless I'm not
> understanding what you're suggesting, I'm not sure that I see how it
> would be helpful.
>
> Regards,
>
> Anthony Liguori

Excuse me if I talk utter nonsense (got a nasty headache, can't think
straight).

If I understand you correctly, we both want an encoding for *physical*
keys.  These get transferred through RFB to the remote peer, which
then maps them to key events according to its own keymapping.

I believe that Linux input layer key codes encode physical keys.
Quote showkey(1):

    Keycodes are numbers assigned by the kernel to each individual
    physical key.  Every key has always only one associated keycode
    number, whether the keyboard sends single or multiple scan codes
    when pressing it.

You can easily check that the keycodes shown by showkey are exactly
the KEY_* codes from linux/input.h.

Consider the key labelled Y on US keyboards.  That key is identified
by input layer key code 21 (KEY_Y), no matter what keymapping or
actual keyboard I use.  The kernel's default translation tables map it
to y, Y, Ctrl-Y and so forth.  If I load German translation tables, it
gets mapped to z, Z, Ctrl-Z and so forth, but the key code is still
21.

PC key codes are an encoding for the physical keys of one particular
kind of keyboard.

Linux input layer key codes are an encoding for the physical keys of
any keyboard supported by Linux.

It's easy to map from PC key codes to Linux input layer key codes and
back.  The map doesn't depend on what keymap the user configured,
because both encodings identify physical keys.  But Linux input layer
key codes are a richer encoding.  What's the PC key code for
KEY_POWER?

Again, please excuse me if I talk nonsense, and try to use simple,
short sentences in your reply %-}