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:
>>
>>   
>>> Markus Armbruster wrote:
>>>     
>>>> Anthony Liguori <anthony codemonkey ws> writes:
>>>>
>>>>         
>>>>> Not really.  PC key codes are well defined for one type of keyboard,
>>>>> but are used by every keyboard.  I guess there's a 1-1 mapping of
>>>>> Linux keycodes to PC keycodes.  I don't believe Linux keycodes are
>>>>> richer than PC key codes though because PC key codes are what are
>>>>> being generated from the actual keyboard.  By definition, there has to
>>>>> be a PC key code for any given key while this isn't necessarily true
>>>>> for Linux keycodes.
>>>>>             
>>>> There has to be a PC key code for every physical key on a PC keyboard.
>>>>
>>>> However, not every keyboard is a PC keyboard, and some of them have
>>>> keys that that don't exist on PC keyboards.
>>>>         
>>> Well, I think this is our problem.  When I say, PC key code, I don't
>>> mean the codes assigned to keys on a PC101 keycode.  I mean any
>>> hardware keycode that is delivered through a PS/2 port.
>>>
>>> GDK calls this a "hardware keycode" which is perhaps a better nomenclature.
>>>
>>> Regards,
>>>
>>> Anthony Liguori
>>>     
>>
>> Is this code at least as rich as the Linux input layer code?  If not,
>> is it rich enough for all practical purposes?
>>   
>
> Anything that comes in through the keyboard should be supported.
> Linux may turn some other things into input events (perhaps some ACPI
> events)?  It may be useful to provide some mechanism to support these
> sort of things but I think it's outside of the scope of this
> particular encoding.
>
>> Where is this code defined?
>>   
>
> Codes aren't defined.  That's really the point.  Whatever comes in
> from your keyboard is immediately sent to the server.  In the case of
> QEMU, this is then immediately sent through the guest's PS/2.
>
> In a lot of respects, this is really PS/2 pass-through support.
>
> Regards,
>
> Anthony Liguori

The question is: do we want PS/2 pass-through, or do we want a
well-defined virtual keyboard?

Consider: several people access the same guest's PVFB through VNC from
their own computers, each with his own keyboard.

Their local keyboard drivers know how to map whatever their keyboards
send to their system's common keyboard event encoding.  In the case of
Linux: the kernel keyboard driver maps to Linux input layer codes, and
the X keyboard driver maps those to X events.

With your PS/2 pass-through proposal, whatever each keyboard sends
gets passed on to the (remote) guest, without any indication of what
kind of keyboard generated them.  PVFB has to ultimately map them to
Linux input layer codes.  Because it has no idea what keyboard made
these codes, it has arbitrarily assume one particular keyboard.

Some users' funny keys will just work, others won't.  And we'll have
no sane way to fix that in PVFB.

Putting something on the wire without a clear definition of its
encoding seems very wrong to me.  Perhaps an identification of the
keyboard could make the "whatever the keyboard sends" encoding fly.
We'd still have to replicate local smarts on interpreting the local
keyboard codes in the remote PVFB, but we'd have a fighting chance.

For PVFB, I'd still prefer a single (near-)universal code.