[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Qemu-devel] [PATCH] hw/input/hid: support alternative sysrq/break s
From: |
Peter Korsgaard |
Subject: |
Re: [Qemu-devel] [PATCH] hw/input/hid: support alternative sysrq/break scancodes for gtk-vnc |
Date: |
Mon, 7 Nov 2016 13:06:26 +0100 |
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 <address@hidden>
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 <address@hidden>
> ---
> 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
- Re: [Qemu-devel] [PATCH] hw/input/hid: support alternative sysrq/break scancodes for gtk-vnc,
Peter Korsgaard <=