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 :|