)]}'
{
  "commit": "86f3bf0ebec1df6e7fd2dd5a4e76cbbcd2d1b01e",
  "tree": "3d42f66322f76d23d8af95218d6c2e2c189d93e2",
  "parents": [
    "204af15b04a448aa6e954e37613ac43467fd76c4"
  ],
  "author": {
    "name": "Peter Korsgaard",
    "email": "peter@korsgaard.com",
    "time": "Fri Oct 28 16:51:32 2016 +0200"
  },
  "committer": {
    "name": "Stefan Hajnoczi",
    "email": "stefanha@redhat.com",
    "time": "Thu Nov 10 15:29:58 2016 +0000"
  },
  "message": "hw/input/hid: support alternative sysrq/break scancodes for gtk-vnc\n\nThe printscreen/sysrq and pause/break keys currently don\u0027t work for guests\nusing -usbdevice keyboard when accessed through vnc with a gtk-vnc based\nclient.\n\nThe reason for this is a mismatch between gtk-vnc and qemu in how these keys\nshould be mapped to XT keycodes.\n\nOn the original IBM XT these keys behaved differently than other keys.\n\nQuoting from https://www.win.tue.nl/~aeb/linux/kbd/scancodes-1.html:\n\nThe keys PrtSc/SysRq and Pause/Break are special. The former produces\nscancode e0 2a e0 37 when no modifier key is pressed simultaneously, e0 37\ntogether with Shift or Ctrl, but 54 together with (left or right) Alt.  (And\none gets the expected sequences upon release.  But see below.) The latter\nproduces scancode sequence e1 1d 45 e1 9d c5 when pressed (without modifier)\nand nothing at all upon release.  However, together with (left or right)\nCtrl, one gets e0 46 e0 c6, and again nothing at release.  It does not\nrepeat.\n\nGtk-vnc supports the \u0027QEMU Extended Key Event Message\u0027 RFB extension to send\nraw XT keycodes directly to qemu, but the specification doesn\u0027t explicitly\nspecify how to map such long/complicated keycode sequences.  From the spec\n(https://github.com/rfbproto/rfbproto/blob/master/rfbproto.rst#qemu-extended-key-event-message)\n\nThe keycode is the XT keycode that produced the keysym. An XT keycode is an\nXT make scancode sequence encoded to fit in a single U32 quantity.  Single\nbyte XT scancodes with a byte value less than 0x7f are encoded as is.\n2-byte XT scancodes whose first byte is 0xe0 and second byte is less than\n0x7f are encoded with the high bit of the first byte set\n\nhid.c currently expects the keycode sequence with shift/ctl for sysrq (e0 37\n-\u003e 0xb7 in RFB), whereas gtk-vnc uses the sequence with alt (0x54).\nLikewise, hid.c expects the code without modifiers (e1 1d 45 -\u003e 0xc5 in\nRFB), whereas gtk-vnc sends the keycode sequence with ctrl for pause (e0 46\n-\u003e 0xc6 in RFB).\n\nSee keymaps.cvs in gtk-vnc for the mapping used:\nhttps://git.gnome.org/browse/gtk-vnc/tree/src/keymaps.csv#n150\n\nNow, it isn\u0027t obvious to me which sequence is really \"right\", but as the\n0x54/0xc6 keycodes are currently unused in hid.c, supporting both seems like\nthe pragmatic solution to me.  The USB HID keyboard boot protocol used by\nhid.c doesn\u0027t have any other mapping applicable to these keys.\n\nThe other guest keyboard interfaces (ps/2, virtio, ..) are not affected,\nbecause they handle these keys differently.\n\nSigned-off-by: Peter Korsgaard \u003cpeter@korsgaard.com\u003e\nMessage-id: 20161028145132.1702-1-peter@korsgaard.com\nSigned-off-by: Gerd Hoffmann \u003ckraxel@redhat.com\u003e\n",
  "tree_diff": [
    {
      "type": "modify",
      "old_id": "5e2850e655409f67e2e62df4a2ccc6a170adf538",
      "old_mode": 33188,
      "old_path": "hw/input/hid.c",
      "new_id": "fa9cc4c61630e0f562137081dae41a6f7db53b2b",
      "new_mode": 33188,
      "new_path": "hw/input/hid.c"
    }
  ]
}