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.
cheers, Gerd
