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

[Gerd Hoffmann <kraxel redhat com>]

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.

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