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:
>> Anthony Liguori <anthony codemonkey ws> writes:
>>
>>   
>>> If it is true, that KEY_Q does not necessarily correspond to a 'Q' key
>>> press, then I fail to see how the Linux input layer codes are any more
>>> well defined the PS/2 scan codes.
>>>     
>>
>> Either you or I are mistaken about how the Linux input layer works for
>> keys :)
>>
>> As far as I can tell, Linux keyboard drivers map real keys to a common
>> encoding of keys (the input layer key codes), which they feed to the
>> input layer.  *Keys*, not key sequences, not what comes out of the
>> user's keymap.
>>   
>
> Okay, let's drive down on this one then.  If I type the 'Q' key on my
> physical keyboard, the question is, will an evdev device always, no
> matter what keyboard I use, give me a KEY_Q keycode?

Which key on your physical keyboard is labelled 'Q'?  That depends on
what language variant you got.

The key that is labelled 'Q' on the US English variant produces KEY_Q,
no matter what's actually printed on it.  And no matter what keymap
you configured.

> From what you write above, it sounds like the answer is "yes".  This
> is what I initial thought, but Gerd disagreed:
>
>> No.  The KEY_* input layer codes don't change when you change the
>> keyboard mapping.  KEY_Y means "the key between T and U", which actually
>> represents 'y' with an us keyboard mapping, but if I load a german one
>> it is 'z'.

Which is exactly what I've been trying to convey.

> So I'm confused.
>
>> For that purpose, I propose to define a virtual keyboard that has all
>> the keys of all the supported keyboards.  Client maps its own
>> idiosyncratic keys to that virtual keyboard.  Guest has a driver for
>> that virtual keyboard, just like it has drivers for real keyboards.
>>   
>
> VNC already provides this.  VNC keycodes provide you a keyboard that
> has every possible key and those keys are always unique.  Why would
> you need a new encoding to achieve this?  The point of the encoding
> I'm proposing is when you have a guest that doesn't know about this
> super keyboard and must contend with traditional keyboards.
>
> Regards,
>
> Anthony Liguori

No.  VNC doesn't give me keys, it gives me X key symbols, which is
what keys are mapped to.

The key labelled Y on my US English keyboard is identified by my Linux
keyboard driver as KEY_Y.

Since I'm using the US English keymap, X11 maps that to this event:

KeyPress event, serial 29, synthetic NO, window 0x4200001,
    root 0x65, subw 0x0, time 2727692562, (120,154), root:(130,219),
    state 0x0, keycode 29 (keysym 0x79, y), same_screen YES,
    XLookupString gives 1 bytes: (79) "y"
    XmbLookupString gives 1 bytes: (79) "y"
    XFilterEvent returns: False

Were I using a German keymap, I'd get:

KeyPress event, serial 47, synthetic NO, window 0x4200001,
    root 0x65, subw 0x0, time 2727895285, (69,175), root:(79,240),
    state 0x0, keycode 29 (keysym 0x7a, z), same_screen YES,
    XLookupString gives 1 bytes: (7a) "z"
    XmbLookupString gives 1 bytes: (7a) "z"
    XFilterEvent returns: False

VNC gives me the keysym without the keycode.  For the key above, it
either gives me XK_y on XK_z, depending on the client's keymap.

If I know that keymap, I can guess the key from the keysym most of the
time, but not always.  That's because the keymap need not be
injective.