[Spice-devel] SPICE_INTERFACE_KEYBOARD - scancodes vs. utf8

[Gerd Hoffmann]

  Hi,

>> So a spice client must somehow figure how to translate the input it gets into
>> scancodes.  And IMO this should best be done on the client side so the client can
>> use all information it has to do it.  For gtk this is easy as the key events carry not
>> only the character but the keycode too.
>>  For android/html5 clients this is alot trickier ...
> 
> AFAIK, neither java nor javascript have access to scancodes. If you solve the problem
> on the server side (spice server library), you need to solve it only once. Else you need
> to implement that clumsy code on each client.
> 
> If I remember correctly, qemu already has some code to convert VNC input to
> scancodes? 

It tries to translate the keysyms back to scancodes, using a keymap
(specified via -k).  Which doesn't work perfectly and also has the
drawback that the server side needs to know which keymap the client is
using.  At least the later can be fixed by doing it on the client side.
 It will be clumpsy no matter what, but maybe that can't be avoided for
html5/android.

>> But, when the server side wants a utf8 stream this is a completely different
>> issue.  Maybe the easiest is to send the utf8 stream over a
>> SpiceCharDeviceInterface (if present).
> 
> Sorry, I am quite new to spice - please can you elaborate a bit more? I can see how 
> to create a SpiceCharDeviceInterface at server side, but AFAIK that is used for other things?

It is basically a transparent bytestream with a name tag, the name being
a reverse fqdn to avoid name clashes (see docs/spice-port-fqdn.txt).

The spice client then can do something sensible for names it recognises.
 For example it could wind up org.qemu.console.serial.0 to a vte widget.
 This way the guests serial console can be redirected over spice.  And
this would btw also be a possible approach to implement spiceterm.

You can define your own channel for utf8 keyboard input, then make
spiceterm and spice client use it to pass keyboard input.

cheers,
  Gerd