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

[Markus Armbruster <armbru redhat com>]

Anthony Liguori <anthony codemonkey ws> writes:

> Gerd Hoffmann wrote:
>> Anthony Liguori wrote:
>>   
>>> Gerd Hoffmann wrote:
>>>     
>>>>   Hi,
>>>> I think they are when it comes to those fancy multimedia keyboards which
>>>> add certain keys for "play", "pause", "next track", "volume up" and so
>>>> on.  Linux has KEY_FOO defines for them.  For PS/2 those are not
>>>> standardized and thus differ from vendor to vendor as far I know.  At
>>>> least xorg comes with a bunch of different xkb keyboard definitions for
>>>> the different keyboards ...
>>>>       
>>> Right, but recall, we're passing this up through to the PS/2 layer so it
>>> will just appear like the local keyboard is connected to the server.
>>>     
>>
>> Yes for qemu-system-x86.  Not for pvfb.  Dunno how
>> qemu-system-{sparc,ppc} are handled ...
>>
>>   
>>> One problem with passing Linux input codes is that we have no way to
>>> make the information we get from GDK to Linux keycodes.  We're basically
>>> passing all the information we have (the symbolic value, and what GDK
>>> provides as the hardware keycode with some canonicalization).
>>>     
>>
>> For the standard 105-key-kbd keys it should be easy at least on pc
>> hardware (just a table lookup).  Just that should be good enougth for
>> starters.
>>
>> The other keys probably become a bit more tricky due to non-standardized
>> ps/2 keycodes for them.  Shouldn't be impossible though.  On the client
>> side we probably can map those XF86XK_AudioLowerVolume (+friends)
>> keysyms.  On the qemu side we probably have to pick one specific
>> multimedia keyboard (with lots of different keys) and emulate that one.
>>   
>
> Using the -k option in QEMU basically picks a particular keyboard and
> emulates that.  If we're willing to do that, then always launching
> qemu with -k en-us and using the existing VNC keysyms is a fine
> solution to the problem.  This is actually exactly what the current
> QEMU server does.  As long as you configure your guest with an en-us
> keyboard, everything Just Works regardless of your client's keyboard
> got most keysyms.  There aren't really keyboards you can emulate that
> have every possible character though so you'll always have some user
> who can't use a certain key.

There are applications of the protocol that don't have to emulate a
real keyboard, e.g. PVFB.  They can "emulate" a *virtual* keyboard
that *does* have all the keys.  Insisting on baking a particular
*real* keyboard into the protocol is not helpful for those
applications.

(1) -k works only if all your clients use the same keyboard layout, no
matter what the client keyboard is.

(2) Your proposed PS/2 pass-through works only if all your clients use
the same keyboard, no matter what the client keyboard layout is.

(3) Transmitting a suitable encoding that covers all the keys on all
the keyboards known to man[*] just works, no matter what keyboard or
layout the clients use.

Which of the three is most useful to users?  Note that the actual
encoding used by (3) is *irrelevant* for that question.  Forget I ever
mentioned Linux input layer codes!

> Regards,
>
> Anthony Liguori
>
>> I think we should avoid wiring PS/2 limitations into the protocol, even
>> if we don't do more than a simple PS/2 keyboard initially.
>>
>> cheers,
>>   Gerd

I agree with Gerd.


[*] Known to Linux is a useful approximation.