X and KVM - an unhappy love story

[Soren Hansen]

Hey guys.

I've been encouraged to explain the problems here.

Those of you fortunate enough to own KVM capable hardware and who've
tried to use Intrepid either as a guest or host have no doubt run into
some issues. Most of them revolve around X. One bug in particular is
causing grief, namely the unfortunate loss of ability to use arrow keys,
function keys, and any other sort of extended keys.

I'll explain the issue briefly:

First a bit of history (if you don't care about this, skip down some
paragraphs to the place with all the explamation points):

KVM does full virtualisation, so it emulates a keyboard of some flavour.
This means that it has a virtual keyboard that sends scan codes to the
guest os like a regular keyboard would do (this is key (har har)). E.g
it doesn't send "f", if you press the f button.  It sends scancode 41.

Let's rewind about a year..  Back then, the way this was accomplished in
kvm (and qemu), you had to pass "-k da" to kvm if you had a Danish
keymapping on your host.  That way, kvm could look at the keysym it got
when you pressed a key, look it up in the Danish keymap it had, map that
to a scan code, and send that to the guest.

This was annoying for many reasons, most importantly: You had to know
which keymap you'd be using on your client already when you're firing up
KVM, since this applies to VNC connections as well (since they send
keysyms rather than keycodes). This made it annoyingly difficult for two
people to have different keymaps, but connect to the same KVM instance,
and it was just generally a pain.

Fast forward to January of this year.  I got fed up with this and
started looking for a way to properly fix this, and talked to Anthony
Liguori (vnc and kvm hacker (very, very convenient combination)) about
it. The result was that Anthony extended the VNC protocol to be able to
send keycodes instead of keysyms. The world was a much happier place,
since keycodes mapped (AFAIUI) exactly to scancodes, if you were using
the xfree86 keyboard driver. No more need to pass "-k <keymap>" to kvm,
because we just dealt directly in scan codes. Very, very convenient.

!!!! Continue here, if you skipped from the top !!!!

Fast forward to Intrepid and the days of evdev. Evdev leaves it to the
kernel to do the mapping from scancodes to keysyms. The correspondence
between scancodes and keycodes is no more, and we're back to having to
provide "-k <something>" to kvm. gtk-vnc currently has no idea that the
keycodes it's receiving don't match scan codes, so it enables the VNC
extension and everybody loses, because extended key events are simply
represented differently, and any kind of exotic stuff you used to be
doing is not possible anymore.

The options I see are currently:

1) Disable this new VNC extension in KVM. It's something we carry as a
patch, as it's not in kvm proper (for some reason that escapes me).
Please note that this means that the kvm experience on Ubuntu was vastly
superior for anyone who is not on a US keymap (which is the default in
kvm) compared to what you get on any other distro, so it'd be quite a
shame. Additionally, I have no actually tested this, and it's not
unthinkable that the full extent of the issues evdev brings upon us has
been understood yet, so this might not actually fix everything.

2) Stop using evdev. I frankly have little idea of what the impact of
this would be.

3) Fix gtkvnc and sdl (the two frontends that are responsible for doing
the mapping). It seems that it's possible to detect the presence of
evdev (sekxkbmap -print knows it), and input-kbd seems to be able to
give me the mapping from scan-codes to keycodes (and keysyms, but that's
less interesting), so I *think* the data is available to fix it, but I
don't have the time to fix it, and I'm not convinced upstream (kvm) has
enough interest in fixing it in time for our release.

What to do?

-- 
Soren Hansen               | 
Virtualisation specialist  | Ubuntu Server Team
Canonical Ltd.             | http://www.ubuntu.com/
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 315 bytes
Desc: Digital signature
Url : https://lists.ubuntu.com/archives/ubuntu-devel/attachments/20080815/d60d9a33/attachment-0001.pgp