qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] [PATCH 6/9] spice: add keyboard


From: Daniel P. Berrange
Subject: Re: [Qemu-devel] [PATCH 6/9] spice: add keyboard
Date: Fri, 20 Aug 2010 15:15:09 +0100
User-agent: Mutt/1.4.1i

On Fri, Aug 20, 2010 at 03:56:52PM +0200, Gerd Hoffmann wrote:
>   Hi,
> 
> >It's not actually ps/2 data. It's AT scan codes plus an internal
> >encoding to indicate press vs. release using the high bit. Additionally,
> >some special keys are encoded with two calls to kbd_put_keycode using
> >the 0xe0 prefix (the grey code).
> 
> Wheee.  From a brief look at the code it seems this *is* the spice wire 
> protocol.  One more place where spice uses knowledge about qemu 
> internals.  Unfortunaly this one escaped my attention until now, so it 
> didn't got fixed :-(
> 
> >So what I'm proposing is that we modify kbd_put_keycode to also reflect
> >this:
> >
> >// normal keys
> >kbd_keycode_press(at_keycode); // PS/2 at2raw(at_keycode)
> >kbd_keycode_release(at_keycode); // PS/2 0xf0, at2raw(at_keycode)
> >
> >// grey keys; PS/2 0xe0, at2raw(at_keycode)
> >kbd_keycode_press(0x80 | at_keycode); // PS/2 0xe0, 0xf0,
> >at2raw(at_keycode)
> >kbd_keycode_release(0x80 | at_keycode); // PS/2 0xe0, 0xf0,
> >at2raw(at_keycode)
> >
> >If it's not already too late, I'd suggest making this the Spice protocol
> >interface.
> 
> No.  I think for now I have to deal with the mess in case qemu decides 
> to change the internal interface.  And when ever touching the spice wire 
> protocol to fixup this mess I will *not* use AT keycodes.  Handling 
> anything with extra internet / multimedia / whatever keys in a sane way 
> is simply impossible with AT keycodes.  linux input layer key codes 
> should do.  maybe usb hid is usable too, need to check.

AT (well XT) keycodes aren't that bad a choice, at least if you go for the
extended mapping used by the Linux keyboard driver. This supports pretty
much all of the internet/multimedia keys, AFAICT, more than USB hid
does (at least in the Linux USB HID driver). In order to properly support
the VNC keycode extension with GTK-VNC under  Xorg + Win32, OS-X and Linux,
as well as native OS-X & Win32, I've created a giant CSV mapping file for
all keycode sets that I've encountered so far.

The master mapping is from Linux keycodes to other sets:

  http://git.gnome.org/browse/gtk-vnc/tree/src/keymaps.csv

And a tool that can then create you C arrays for mapping between
arbitrary keycode sets in any direction (potentially lossy
of course, depending on choice of keycode sets):

  http://git.gnome.org/browse/gtk-vnc/tree/src/keymap-gen.pl

Regards,
Daniel
-- 
|: Red Hat, Engineering, London    -o-   http://people.redhat.com/berrange/ :|
|: http://libvirt.org -o- http://virt-manager.org -o- http://deltacloud.org :|
|: http://autobuild.org        -o-         http://search.cpan.org/~danberr/ :|
|: GnuPG: 7D3B9505  -o-   F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 :|



reply via email to

[Prev in Thread] Current Thread [Next in Thread]