qemu-commits
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Qemu-commits] [qemu/qemu] 241676: input: add mouse side buttons to virt


From: GitHub
Subject: [Qemu-commits] [qemu/qemu] 241676: input: add mouse side buttons to virtio input
Date: Mon, 29 Jan 2018 09:17:08 -0800

  Branch: refs/heads/master
  Home:   https://github.com/qemu/qemu
  Commit: 2416760fa6728813e1446736e9be55e07b5030b0
      
https://github.com/qemu/qemu/commit/2416760fa6728813e1446736e9be55e07b5030b0
  Author: Miika S <address@hidden>
  Date:   2018-01-29 (Mon, 29 Jan 2018)

  Changed paths:
    M hw/input/virtio-input-hid.c

  Log Message:
  -----------
  input: add mouse side buttons to virtio input

Signed-off-by: Miika S <address@hidden>
Message-Id: <address@hidden>
Signed-off-by: Gerd Hoffmann <address@hidden>


  Commit: a5f99be41ee8d874ab63c4abf733c91a483a28d4
      
https://github.com/qemu/qemu/commit/a5f99be41ee8d874ab63c4abf733c91a483a28d4
  Author: Miika S <address@hidden>
  Date:   2018-01-29 (Mon, 29 Jan 2018)

  Changed paths:
    M hw/input/virtio-input-hid.c

  Log Message:
  -----------
  input: virtio: don't send mouse wheel event twice

On Linux, a mouse event is generated for both down and up when mouse
wheel is used. This caused virtio_input_send() to be called twice each
time the wheel was used.

This commit adds a check for the button down state and only calls
virtio_input_send() when it is true.

Signed-off-by: Miika S <address@hidden>
Message-Id: <address@hidden>
Signed-off-by: Gerd Hoffmann <address@hidden>


  Commit: 802cbcb73002b92e6ddc8464d39b668a71b78d74
      
https://github.com/qemu/qemu/commit/802cbcb73002b92e6ddc8464d39b668a71b78d74
  Author: Prasad J Pandit <address@hidden>
  Date:   2018-01-29 (Mon, 29 Jan 2018)

  Changed paths:
    M hw/input/ps2.c

  Log Message:
  -----------
  ps2: check PS2Queue pointers in post_load routine

During Qemu guest migration, a destination process invokes ps2
post_load function. In that, if 'rptr' and 'count' values were
invalid, it could lead to OOB access or infinite loop issue.
Add check to avoid it.

Reported-by: Cyrille Chatras <address@hidden>
Signed-off-by: Prasad J Pandit <address@hidden>
Message-id: address@hidden
Signed-off-by: Gerd Hoffmann <address@hidden>


  Commit: ab8f9d49d62c82a12409475547e4420a46da56ed
      
https://github.com/qemu/qemu/commit/ab8f9d49d62c82a12409475547e4420a46da56ed
  Author: Daniel P. Berrange <address@hidden>
  Date:   2018-01-29 (Mon, 29 Jan 2018)

  Changed paths:
    M Makefile
    M hw/input/ps2.c
    M include/ui/input.h
    M ui/input-keymap.c

  Log Message:
  -----------
  hw: convert ps2 device to keycodemapdb

Replace the qcode_to_keycode_set1, qcode_to_keycode_set2,
and qcode_to_keycode_set3 tables with automatically
generated tables.

Missing entries in qcode_to_keycode_set1 now fixed:

 - Q_KEY_CODE_SYSRQ -> 0x54
 - Q_KEY_CODE_PRINT -> 0x54 (NB ignored due to special case)
 - Q_KEY_CODE_AGAIN -> 0xe005
 - Q_KEY_CODE_PROPS -> 0xe006
 - Q_KEY_CODE_UNDO -> 0xe007
 - Q_KEY_CODE_FRONT -> 0xe00c
 - Q_KEY_CODE_COPY -> 0xe078
 - Q_KEY_CODE_OPEN -> 0x64
 - Q_KEY_CODE_PASTE -> 0x65
 - Q_KEY_CODE_CUT -> 0xe03c
 - Q_KEY_CODE_LF -> 0x5b
 - Q_KEY_CODE_HELP -> 0xe075
 - Q_KEY_CODE_COMPOSE -> 0xe05d
 - Q_KEY_CODE_PAUSE -> 0xe046
 - Q_KEY_CODE_KP_EQUALS -> 0x59

And some mistakes corrected:

 - Q_KEY_CODE_HIRAGANA was mapped to 0x70 (Katakanahiragana)
   instead of of 0x77 (Hirigana)
 - Q_KEY_CODE_MENU was incorrectly mapped to the compose
   scancode (0xe05d) and is now mapped to 0xe01e
 - Q_KEY_CODE_FIND was mapped to 0xe065 (Search) instead
   of to 0xe041 (Find)
 - Q_KEY_CODE_POWER, SLEEP & WAKE had 0x0e instead of 0xe0
   as the prefix

Missing entries in qcode_to_keycode_set2 now fixed:

 - Q_KEY_CODE_PRINT -> 0x7f (NB ignored due to special case)
 - Q_KEY_CODE_COMPOSE -> 0xe02f
 - Q_KEY_CODE_PAUSE -> 0xe077
 - Q_KEY_CODE_KP_EQUALS -> 0x0f

And some mistakes corrected:

 - Q_KEY_CODE_HIRAGANA was mapped to 0x13 (Katakanahiragana)
   instead of of 0x62 (Hirigana)
 - Q_KEY_CODE_MENU was incorrectly mapped to the compose
   scancode (0xe02f) and is now not mapped
 - Q_KEY_CODE_FIND was mapped to 0xe010 (Search) and is now
   not mapped.
 - Q_KEY_CODE_POWER, SLEEP & WAKE had 0x0e instead of 0xe0
   as the prefix

Missing entries in qcode_to_keycode_set3 now fixed:

 - Q_KEY_CODE_ASTERISK -> 0x7e
 - Q_KEY_CODE_SYSRQ -> 0x57
 - Q_KEY_CODE_LESS -> 0x13
 - Q_KEY_CODE_STOP -> 0x0a
 - Q_KEY_CODE_AGAIN -> 0x0b
 - Q_KEY_CODE_PROPS -> 0x0c
 - Q_KEY_CODE_UNDO -> 0x10
 - Q_KEY_CODE_COPY -> 0x18
 - Q_KEY_CODE_OPEN -> 0x20
 - Q_KEY_CODE_PASTE -> 0x28
 - Q_KEY_CODE_FIND -> 0x30
 - Q_KEY_CODE_CUT -> 0x38
 - Q_KEY_CODE_HELP -> 0x09
 - Q_KEY_CODE_COMPOSE -> 0x8d
 - Q_KEY_CODE_AUDIONEXT -> 0x93
 - Q_KEY_CODE_AUDIOPREV -> 0x94
 - Q_KEY_CODE_AUDIOSTOP -> 0x98
 - Q_KEY_CODE_AUDIOMUTE -> 0x9c
 - Q_KEY_CODE_VOLUMEUP -> 0x95
 - Q_KEY_CODE_VOLUMEDOWN -> 0x9d
 - Q_KEY_CODE_CALCULATOR -> 0xa3
 - Q_KEY_CODE_AC_HOME -> 0x97

And some mistakes corrected:

 - Q_KEY_CODE_MENU was incorrectly mapped to the compose
   scancode (0x8d) and is now 0x91

Signed-off-by: Daniel P. Berrange <address@hidden>
Message-id: address@hidden
Signed-off-by: Gerd Hoffmann <address@hidden>


  Commit: e709a61a8fe1076a487376fd657544418a38ba06
      
https://github.com/qemu/qemu/commit/e709a61a8fe1076a487376fd657544418a38ba06
  Author: Daniel P. Berrange <address@hidden>
  Date:   2018-01-29 (Mon, 29 Jan 2018)

  Changed paths:
    M Makefile
    M hw/char/escc.c
    M include/ui/input.h
    M ui/input-keymap.c

  Log Message:
  -----------
  hw: convert the escc device to keycodemapdb

Replace the qcode_to_keycode table with automatically
generated tables.

Missing entries in qcode_to_keycode now fixed:

 - Q_KEY_CODE_KP_COMMA -> 0x2d

Signed-off-by: Daniel P. Berrange <address@hidden>
Message-id: address@hidden
Signed-off-by: Gerd Hoffmann <address@hidden>


  Commit: 5a15e6b1cafb89a2c931195634a4908a69160278
      
https://github.com/qemu/qemu/commit/5a15e6b1cafb89a2c931195634a4908a69160278
  Author: Daniel P. Berrange <address@hidden>
  Date:   2018-01-29 (Mon, 29 Jan 2018)

  Changed paths:
    M Makefile
    M include/ui/input.h
    M ui/input-keymap.c

  Log Message:
  -----------
  ui: fix alphabetical ordering of keymaps

The qcode-to-linux keymaps was accidentally added in the wrong place
by

  commit de80d78594b4c3767a12d8d42debcf12cbf85a5b
  Author: Owen Smith <address@hidden>
  Date:   Fri Nov 3 11:56:28 2017 +0000

    ui: generate qcode to linux mappings

breaking the alphabetical ordering of keymaps

Signed-off-by: Daniel P. Berrange <address@hidden>
Reviewed-by: Philippe Mathieu-Daudé <address@hidden>
Message-id: address@hidden
Signed-off-by: Gerd Hoffmann <address@hidden>


  Commit: ae6b06ab655b21c19b234ce3422f694d11a013e0
      
https://github.com/qemu/qemu/commit/ae6b06ab655b21c19b234ce3422f694d11a013e0
  Author: Daniel P. Berrange <address@hidden>
  Date:   2018-01-29 (Mon, 29 Jan 2018)

  Changed paths:
    M hw/input/virtio-input-hid.c

  Log Message:
  -----------
  hw: convert virtio-input-hid device to keycodemapdb

Replace the keymap_qcode table with automatically generated
tables.

Missing entries in keymap_qcode now fixed:

  Q_KEY_CODE_ASTERISK -> KEY_KPASTERISK
  Q_KEY_CODE_KP_MULTIPLY -> KEY_KPASTERISK
  Q_KEY_CODE_STOP -> KEY_STOP
  Q_KEY_CODE_AGAIN -> KEY_AGAIN
  Q_KEY_CODE_PROPS -> KEY_PROPS
  Q_KEY_CODE_UNDO -> KEY_UNDO
  Q_KEY_CODE_FRONT -> KEY_FRONT
  Q_KEY_CODE_COPY -> KEY_COPY
  Q_KEY_CODE_OPEN -> KEY_OPEN
  Q_KEY_CODE_PASTE -> KEY_PASTE
  Q_KEY_CODE_FIND -> KEY_FIND
  Q_KEY_CODE_CUT -> KEY_CUT
  Q_KEY_CODE_LF -> KEY_LINEFEED
  Q_KEY_CODE_HELP -> KEY_HELP
  Q_KEY_CODE_COMPOSE -> KEY_COMPOSE
  Q_KEY_CODE_RO -> KEY_RO
  Q_KEY_CODE_HIRAGANA -> KEY_HIRAGANA
  Q_KEY_CODE_HENKAN -> KEY_HENKAN
  Q_KEY_CODE_YEN -> KEY_YEN
  Q_KEY_CODE_KP_COMMA -> KEY_KPCOMMA
  Q_KEY_CODE_KP_EQUALS -> KEY_KPEQUAL
  Q_KEY_CODE_POWER -> KEY_POWER
  Q_KEY_CODE_SLEEP -> KEY_SLEEP
  Q_KEY_CODE_WAKE -> KEY_WAKEUP
  Q_KEY_CODE_AUDIONEXT -> KEY_NEXTSONG
  Q_KEY_CODE_AUDIOPREV -> KEY_PREVIOUSSONG
  Q_KEY_CODE_AUDIOSTOP -> KEY_STOPCD
  Q_KEY_CODE_AUDIOPLAY -> KEY_PLAYPAUSE
  Q_KEY_CODE_AUDIOMUTE -> KEY_MUTE
  Q_KEY_CODE_VOLUMEUP -> KEY_VOLUMEUP
  Q_KEY_CODE_VOLUMEDOWN -> KEY_VOLUMEDOWN
  Q_KEY_CODE_MEDIASELECT -> KEY_MEDIA
  Q_KEY_CODE_MAIL -> KEY_MAIL
  Q_KEY_CODE_CALCULATOR -> KEY_CALC
  Q_KEY_CODE_COMPUTER -> KEY_COMPUTER
  Q_KEY_CODE_AC_HOME -> KEY_HOMEPAGE
  Q_KEY_CODE_AC_BACK -> KEY_BACK
  Q_KEY_CODE_AC_FORWARD -> KEY_FORWARD
  Q_KEY_CODE_AC_REFRESH -> KEY_REFRESH
  Q_KEY_CODE_AC_BOOKMARKS -> KEY_BOOKMARKS

NB, the virtio-input device reports a bitmask to the guest driver that
has a bit set for each Linux keycode that the host is able to send to
the guest.

Thus by adding these extra key mappings we are technically changing the
host<->guest ABI. This would also happen any time we defined new mappings
for QEMU keycodes in future.

When a keycode is removed from the list of possible keycodes that host can
send to the guest, it means that the guest OS will think it is possible
to receive a key that in pratice can never be generated, which is harmless.

When a keycode is added to the list of possible keycodes that the host can
send to the guest, it means that the guest OS can see an unexpected event.
The Linux virtio_input.c driver code simply forwards this event to the
input_event() method in the Linux input subsystem. This in turn calls
input_handle_event(), which then calls input_get_disposition(). This method
checks if the input event is present in the permitted keys bitmap, and if
not returns INPUT_IGNORE_EVENT. Thus the unexpected event will get dropped,
which is harmless.

If the guest OS reboots, or otherwise re-initializes the virt-input device,
it will read the new keycode bitmap. No matter how many keys are defined,
the config space has a fixed 128 byte bitmap. There is, however, a size
field defiend which says how many bytes in the bitmap are used. So the guest
OS reads the size of the bitmap, and then it reads the data from bitmap upto
the designated size. So if the guest OS re-initializes at precisely the time
that QEMU is migrated across versions, in the worst case, it could conceivably
read the old size field, but then get the newly updated bitmap.  If a key were
added this is harmless, since it simply means it may not process the newly
added key. If a key were removed, then it could be readnig a byte from the
bitmap that was not initialized. Fortunately QEMU always memsets() the entire
bitmap to 0, prior to setting keybits. Thus the guest OS will simply read
zeros, which is again harmless.

Based on this analysis, it is believed that there is no need to preserve the
virtio-input-hid keymaps across migration, as the host<->guest ABI change is
harmless and self-resolving at time of guest reboot.

NB, this behaviour should perhaps be formalized in the virtio-input spec
to declare how guest OS drivers should be written to be robust in their
handling of the potentially changable key bitmaps.

Signed-off-by: Daniel P. Berrange <address@hidden>
Message-id: address@hidden
Signed-off-by: Gerd Hoffmann <address@hidden>


  Commit: 30d9fefe1aca1e92c785214aa9201fd7c2287d56
      
https://github.com/qemu/qemu/commit/30d9fefe1aca1e92c785214aa9201fd7c2287d56
  Author: Peter Maydell <address@hidden>
  Date:   2018-01-29 (Mon, 29 Jan 2018)

  Changed paths:
    M Makefile
    M hw/char/escc.c
    M hw/input/ps2.c
    M hw/input/virtio-input-hid.c
    M include/ui/input.h
    M ui/input-keymap.c

  Log Message:
  -----------
  Merge remote-tracking branch 
'remotes/kraxel/tags/input-20180129-v2-pull-request' into staging

input: switch devices to keycodemapdb, bugfixes.

# gpg: Signature made Mon 29 Jan 2018 10:23:00 GMT
# gpg:                using RSA key 0x4CB6D8EED3E87138
# gpg: Good signature from "Gerd Hoffmann (work) <address@hidden>"
# gpg:                 aka "Gerd Hoffmann <address@hidden>"
# gpg:                 aka "Gerd Hoffmann (private) <address@hidden>"
# Primary key fingerprint: A032 8CFF B93A 17A7 9901  FE7D 4CB6 D8EE D3E8 7138

* remotes/kraxel/tags/input-20180129-v2-pull-request:
  hw: convert virtio-input-hid device to keycodemapdb
  ui: fix alphabetical ordering of keymaps
  hw: convert the escc device to keycodemapdb
  hw: convert ps2 device to keycodemapdb
  ps2: check PS2Queue pointers in post_load routine
  input: virtio: don't send mouse wheel event twice
  input: add mouse side buttons to virtio input

Signed-off-by: Peter Maydell <address@hidden>


Compare: https://github.com/qemu/qemu/compare/0d1442912b3d...30d9fefe1aca

reply via email to

[Prev in Thread] Current Thread [Next in Thread]