Ping? Any feedback? Anything else needed? Original patch is here: http://patchwork.ozlabs.org/patch/688469/
On Fri, Oct 28, 2016 at 4:51 PM, Peter Korsgaard <[email protected]> wrote: > The printscreen/sysrq and pause/break keys currently don't work for guests > using -usbdevice keyboard when accessed through vnc with a gtk-vnc based > client. > > The reason for this is a mismatch between gtk-vnc and qemu in how these > keys > should be mapped to XT keycodes. > > On the original IBM XT these keys behaved differently than other keys. > > Quoting from https://www.win.tue.nl/~aeb/linux/kbd/scancodes-1.html: > > The keys PrtSc/SysRq and Pause/Break are special. The former produces > scancode e0 2a e0 37 when no modifier key is pressed simultaneously, e0 37 > together with Shift or Ctrl, but 54 together with (left or right) Alt. > (And > one gets the expected sequences upon release. But see below.) The latter > produces scancode sequence e1 1d 45 e1 9d c5 when pressed (without > modifier) > and nothing at all upon release. However, together with (left or right) > Ctrl, one gets e0 46 e0 c6, and again nothing at release. It does not > repeat. > > Gtk-vnc supports the 'QEMU Extended Key Event Message' RFB extension to > send > raw XT keycodes directly to qemu, but the specification doesn't explicitly > specify how to map such long/complicated keycode sequences. From the spec > (https://github.com/rfbproto/rfbproto/blob/master/rfbproto. > rst#qemu-extended-key-event-message) > > The keycode is the XT keycode that produced the keysym. An XT keycode is an > XT make scancode sequence encoded to fit in a single U32 quantity. Single > byte XT scancodes with a byte value less than 0x7f are encoded as is. > 2-byte XT scancodes whose first byte is 0xe0 and second byte is less than > 0x7f are encoded with the high bit of the first byte set > > hid.c currently expects the keycode sequence with shift/ctl for sysrq (e0 > 37 > -> 0xb7 in RFB), whereas gtk-vnc uses the sequence with alt (0x54). > Likewise, hid.c expects the code without modifiers (e1 1d 45 -> 0xc5 in > RFB), whereas gtk-vnc sends the keycode sequence with ctrl for pause (e0 46 > -> 0xc6 in RFB). > > See keymaps.cvs in gtk-vnc for the mapping used: > https://git.gnome.org/browse/gtk-vnc/tree/src/keymaps.csv#n150 > > Now, it isn't obvious to me which sequence is really "right", but as the > 0x54/0xc6 keycodes are currently unused in hid.c, supporting both seems > like > the pragmatic solution to me. The USB HID keyboard boot protocol used by > hid.c doesn't have any other mapping applicable to these keys. > > The other guest keyboard interfaces (ps/2, virtio, ..) are not affected, > because they handle these keys differently. > > Signed-off-by: Peter Korsgaard <[email protected]> > --- > hw/input/hid.c | 4 ++-- > 1 file changed, 2 insertions(+), 2 deletions(-) > > diff --git a/hw/input/hid.c b/hw/input/hid.c > index 5e2850e..fa9cc4c 100644 > --- a/hw/input/hid.c > +++ b/hw/input/hid.c > @@ -46,7 +46,7 @@ static const uint8_t hid_usage_keys[0x100] = { > 0xe2, 0x2c, 0x39, 0x3a, 0x3b, 0x3c, 0x3d, 0x3e, > 0x3f, 0x40, 0x41, 0x42, 0x43, 0x53, 0x47, 0x5f, > 0x60, 0x61, 0x56, 0x5c, 0x5d, 0x5e, 0x57, 0x59, > - 0x5a, 0x5b, 0x62, 0x63, 0x00, 0x00, 0x64, 0x44, > + 0x5a, 0x5b, 0x62, 0x63, 0x46, 0x00, 0x64, 0x44, > 0x45, 0x68, 0x69, 0x6a, 0x6b, 0x6c, 0x6d, 0x6e, > 0xe8, 0xe9, 0x71, 0x72, 0x73, 0x00, 0x00, 0x00, > 0x00, 0x00, 0x00, 0x85, 0x00, 0x00, 0x00, 0x00, > @@ -61,7 +61,7 @@ static const uint8_t hid_usage_keys[0x100] = { > 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, > 0x00, 0x00, 0x00, 0x00, 0x00, 0x54, 0x00, 0x46, > 0xe6, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, > - 0x00, 0x00, 0x00, 0x00, 0x00, 0x48, 0x00, 0x4a, > + 0x00, 0x00, 0x00, 0x00, 0x00, 0x48, 0x48, 0x4a, > 0x52, 0x4b, 0x00, 0x50, 0x00, 0x4f, 0x00, 0x4d, > 0x51, 0x4e, 0x49, 0x4c, 0x00, 0x00, 0x00, 0x00, > 0x00, 0x00, 0x00, 0xe3, 0xe7, 0x65, 0x00, 0x00, > -- > 2.9.3 > > -- Bye, Peter Korsgaard
