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:
>>>>
>>>>         
>>>>> 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.
>>   
>
> But the Linux input codes are equally undefined.  While KEY_Q may be
> symbolic and defined to a certain value, it's all but meaningless on
> the wire.  It may correspond to any number of physical key presses.
> What you're proposing is Linux input layer pass through.
>
>> 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.
>>   
>
> Linux already has to make PS/2 keycodes to input events.  It should be
> the same thing.
>
>> 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.
>>   
>
> 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.

The mappings are "defined" operationally: whatever the driver does.

> The problem we're solving is this: if a host and guest have the same
> keyboard configured, then PS/2 pass through will Just Work.  The same
> logic applies already today with QEMU's SDL support (you don't need to
> use -k when using SDL).

There's a bug in your problem statement.  We don't have two entities
(host and guest), we have three: guest (running PVFB frontend), host
(running PVFB backend) and client (running VNC client).

PS/2 pass-through works if *client* and guest have the same keyboard
configured.  You can't assume that client always equals host!

Moreover, there may be any number of clients with any number of
keyboards, and PS/2 pass-through can make only those that match the
keyboard configured in the guest work.

In other words, pick one kind of keyboard for everyone.  Without
doubt, that's an improvement over what we have now (pick one kind of
*keymap* for everyone).

But we can do better easily.  The problem we *should* solve is this:
regardless of what keyboard client and guest have configured, map
*keys* (not key sequences, not key events) as faithfully between them
as possible.

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.

I further propose we steal the virtual keyboard instead of defining it
ourselves.  I don't care where we steal it.  First thing I found was
the virtual keyboard defined by the Linux input layer, so I proposed
that.

> I still think we're somehow misunderstanding each other because I
> still don't see why Linux input layer codes are any more well defined
> than PS/2 scan codes except there's a bunch of symbolic defines that
> have no real meaning for the Linux input layer codes.
>
> Regards,
>
> Anthony Liguori

Yes, I agree we've done a fine job talking past each other ;)