[Spice-devel] SPICE_INTERFACE_KEYBOARD - scancodes vs. utf8

[Daniel P. Berrange]

On Tue, Aug 06, 2013 at 03:42:29PM +0000, Dietmar Maurer wrote:
> > > Having utf8 input was discussed a few weeks ago, it is needed for html
> > > and android clients for ex.
> > 
> > Note that this is a completely different problem.
> > 
> > When running a virtual machine you need the scancodes, so you can feed the
> > guest with the correct virtual keystrokes.  Translating those keystrokes into
> > characters is the job of the guest operating system.
> > There is no meaningful way to pass a utf-8 character stream into a virtual
> > machine.
> > 
> > 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? 

Yes, but that code is broken by design, which is why we invented the raw
scancode extension to VNC, and why SPICE uses scancodes from the start.
It is not possible to round-trip from a character/key symbol, to a hw 
cancode back to a character/key symbol without irretrievably loosing
information. eg the key sym you put in from the client will not match
the one Xorg eventually gets in the guest.

It also requires that you manually configure a keycode mapping table
in the QEMU binary itself at startup, to match the keycode mapping in
the guest and the mapping in the client. This obviously means that all
clients must use the same keycode map that was chosen at the time QEMU
started.

I wrote a bit about this awfulness here

  https://www.berrange.com/posts/2010/07/04/more-than-you-or-i-ever-wanted-to-know-about-virtual-keyboard-handling/
  https://www.berrange.com/posts/2010/07/04/a-summary-of-scan-code-key-codes-sets-used-in-the-pc-virtualization-stack/

Perhaps this brokenness is unavoidable with spice android/html5 clients,
but you should be aware that if you go down that route, you are picking
a solution which is unfixably broken.

The only other option you'd have is to take QEMU's keyboard emulation
out of the picture entirely. Define a spice guest agent extension that
lets you pass key symbols straight to the guest agent, which can give
them to the windowing system without any translation steps involved.
Obviously this wouldn't be much help during intial VM bootup, but maybe
that's an acceptable tradeoff ?

Daniel
-- 
|: http://berrange.com      -o-    http://www.flickr.com/photos/dberrange/ :|
|: http://libvirt.org              -o-             http://virt-manager.org :|
|: http://autobuild.org       -o-         http://search.cpan.org/~danberr/ :|
|: http://entangle-photo.org       -o-       http://live.gnome.org/gtk-vnc :|