2014-04-01 10:06:29 +02:00
|
|
|
/*
|
|
|
|
* This work is licensed under the terms of the GNU GPL, version 2 or
|
|
|
|
* (at your option) any later version. See the COPYING file in the
|
|
|
|
* top-level directory.
|
|
|
|
*/
|
|
|
|
|
2016-01-26 19:17:07 +01:00
|
|
|
#include "qemu/osdep.h"
|
2014-04-01 10:06:29 +02:00
|
|
|
#include "qemu/iov.h"
|
|
|
|
|
|
|
|
#include "hw/qdev.h"
|
|
|
|
#include "hw/virtio/virtio.h"
|
|
|
|
#include "hw/virtio/virtio-input.h"
|
|
|
|
|
|
|
|
#undef CONFIG_CURSES
|
|
|
|
#include "ui/console.h"
|
|
|
|
|
|
|
|
#include "standard-headers/linux/input.h"
|
|
|
|
|
|
|
|
#define VIRTIO_ID_NAME_KEYBOARD "QEMU Virtio Keyboard"
|
|
|
|
#define VIRTIO_ID_NAME_MOUSE "QEMU Virtio Mouse"
|
|
|
|
#define VIRTIO_ID_NAME_TABLET "QEMU Virtio Tablet"
|
|
|
|
|
|
|
|
/* ----------------------------------------------------------------- */
|
|
|
|
|
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 <berrange@redhat.com>
Message-id: 20180117164118.8510-5-berrange@redhat.com
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
2018-01-17 17:41:18 +01:00
|
|
|
static const unsigned short keymap_button[INPUT_BUTTON__MAX] = {
|
2014-04-01 10:06:29 +02:00
|
|
|
[INPUT_BUTTON_LEFT] = BTN_LEFT,
|
|
|
|
[INPUT_BUTTON_RIGHT] = BTN_RIGHT,
|
|
|
|
[INPUT_BUTTON_MIDDLE] = BTN_MIDDLE,
|
2016-01-12 12:14:12 +01:00
|
|
|
[INPUT_BUTTON_WHEEL_UP] = BTN_GEAR_UP,
|
|
|
|
[INPUT_BUTTON_WHEEL_DOWN] = BTN_GEAR_DOWN,
|
2017-12-22 16:25:30 +01:00
|
|
|
[INPUT_BUTTON_SIDE] = BTN_SIDE,
|
|
|
|
[INPUT_BUTTON_EXTRA] = BTN_EXTRA,
|
2014-04-01 10:06:29 +02:00
|
|
|
};
|
|
|
|
|
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 <berrange@redhat.com>
Message-id: 20180117164118.8510-5-berrange@redhat.com
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
2018-01-17 17:41:18 +01:00
|
|
|
static const unsigned short axismap_rel[INPUT_AXIS__MAX] = {
|
2014-04-01 10:06:29 +02:00
|
|
|
[INPUT_AXIS_X] = REL_X,
|
|
|
|
[INPUT_AXIS_Y] = REL_Y,
|
|
|
|
};
|
|
|
|
|
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 <berrange@redhat.com>
Message-id: 20180117164118.8510-5-berrange@redhat.com
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
2018-01-17 17:41:18 +01:00
|
|
|
static const unsigned short axismap_abs[INPUT_AXIS__MAX] = {
|
2014-04-01 10:06:29 +02:00
|
|
|
[INPUT_AXIS_X] = ABS_X,
|
|
|
|
[INPUT_AXIS_Y] = ABS_Y,
|
|
|
|
};
|
|
|
|
|
|
|
|
/* ----------------------------------------------------------------- */
|
|
|
|
|
|
|
|
static void virtio_input_key_config(VirtIOInput *vinput,
|
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 <berrange@redhat.com>
Message-id: 20180117164118.8510-5-berrange@redhat.com
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
2018-01-17 17:41:18 +01:00
|
|
|
const unsigned short *keymap,
|
2014-04-01 10:06:29 +02:00
|
|
|
size_t mapsize)
|
|
|
|
{
|
|
|
|
virtio_input_config keys;
|
|
|
|
int i, bit, byte, bmax = 0;
|
|
|
|
|
|
|
|
memset(&keys, 0, sizeof(keys));
|
|
|
|
for (i = 0; i < mapsize; i++) {
|
|
|
|
bit = keymap[i];
|
|
|
|
if (!bit) {
|
|
|
|
continue;
|
|
|
|
}
|
|
|
|
byte = bit / 8;
|
|
|
|
bit = bit % 8;
|
|
|
|
keys.u.bitmap[byte] |= (1 << bit);
|
|
|
|
if (bmax < byte+1) {
|
|
|
|
bmax = byte+1;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
keys.select = VIRTIO_INPUT_CFG_EV_BITS;
|
|
|
|
keys.subsel = EV_KEY;
|
|
|
|
keys.size = bmax;
|
|
|
|
virtio_input_add_config(vinput, &keys);
|
|
|
|
}
|
|
|
|
|
|
|
|
static void virtio_input_handle_event(DeviceState *dev, QemuConsole *src,
|
|
|
|
InputEvent *evt)
|
|
|
|
{
|
2017-09-26 13:32:43 +02:00
|
|
|
VirtIOInputHID *vhid = VIRTIO_INPUT_HID(dev);
|
2014-04-01 10:06:29 +02:00
|
|
|
VirtIOInput *vinput = VIRTIO_INPUT(dev);
|
|
|
|
virtio_input_event event;
|
|
|
|
int qcode;
|
2016-03-03 17:16:49 +01:00
|
|
|
InputKeyEvent *key;
|
|
|
|
InputMoveEvent *move;
|
|
|
|
InputBtnEvent *btn;
|
2014-04-01 10:06:29 +02:00
|
|
|
|
2015-10-26 23:34:58 +01:00
|
|
|
switch (evt->type) {
|
2014-04-01 10:06:29 +02:00
|
|
|
case INPUT_EVENT_KIND_KEY:
|
qapi: Don't special-case simple union wrappers
Simple unions were carrying a special case that hid their 'data'
QMP member from the resulting C struct, via the hack method
QAPISchemaObjectTypeVariant.simple_union_type(). But by using
the work we started by unboxing flat union and alternate
branches, coupled with the ability to visit the members of an
implicit type, we can now expose the simple union's implicit
type in qapi-types.h:
| struct q_obj_ImageInfoSpecificQCow2_wrapper {
| ImageInfoSpecificQCow2 *data;
| };
|
| struct q_obj_ImageInfoSpecificVmdk_wrapper {
| ImageInfoSpecificVmdk *data;
| };
...
| struct ImageInfoSpecific {
| ImageInfoSpecificKind type;
| union { /* union tag is @type */
| void *data;
|- ImageInfoSpecificQCow2 *qcow2;
|- ImageInfoSpecificVmdk *vmdk;
|+ q_obj_ImageInfoSpecificQCow2_wrapper qcow2;
|+ q_obj_ImageInfoSpecificVmdk_wrapper vmdk;
| } u;
| };
Doing this removes asymmetry between QAPI's QMP side and its
C side (both sides now expose 'data'), and means that the
treatment of a simple union as sugar for a flat union is now
equivalent in both languages (previously the two approaches used
a different layer of dereferencing, where the simple union could
be converted to a flat union with equivalent C layout but
different {} on the wire, or to an equivalent QMP wire form
but with different C representation). Using the implicit type
also lets us get rid of the simple_union_type() hack.
Of course, now all clients of simple unions have to adjust from
using su->u.member to using su->u.member.data; while this touches
a number of files in the tree, some earlier cleanup patches
helped minimize the change to the initialization of a temporary
variable rather than every single member access. The generated
qapi-visit.c code is also affected by the layout change:
|@@ -7393,10 +7393,10 @@ void visit_type_ImageInfoSpecific_member
| }
| switch (obj->type) {
| case IMAGE_INFO_SPECIFIC_KIND_QCOW2:
|- visit_type_ImageInfoSpecificQCow2(v, "data", &obj->u.qcow2, &err);
|+ visit_type_q_obj_ImageInfoSpecificQCow2_wrapper_members(v, &obj->u.qcow2, &err);
| break;
| case IMAGE_INFO_SPECIFIC_KIND_VMDK:
|- visit_type_ImageInfoSpecificVmdk(v, "data", &obj->u.vmdk, &err);
|+ visit_type_q_obj_ImageInfoSpecificVmdk_wrapper_members(v, &obj->u.vmdk, &err);
| break;
| default:
| abort();
Signed-off-by: Eric Blake <eblake@redhat.com>
Message-Id: <1458254921-17042-13-git-send-email-eblake@redhat.com>
Signed-off-by: Markus Armbruster <armbru@redhat.com>
2016-03-17 23:48:37 +01:00
|
|
|
key = evt->u.key.data;
|
2016-03-03 17:16:49 +01:00
|
|
|
qcode = qemu_input_key_value_to_qcode(key->key);
|
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 <berrange@redhat.com>
Message-id: 20180117164118.8510-5-berrange@redhat.com
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
2018-01-17 17:41:18 +01:00
|
|
|
if (qcode < qemu_input_map_qcode_to_linux_len &&
|
|
|
|
qemu_input_map_qcode_to_linux[qcode]) {
|
2014-04-01 10:06:29 +02:00
|
|
|
event.type = cpu_to_le16(EV_KEY);
|
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 <berrange@redhat.com>
Message-id: 20180117164118.8510-5-berrange@redhat.com
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
2018-01-17 17:41:18 +01:00
|
|
|
event.code = cpu_to_le16(qemu_input_map_qcode_to_linux[qcode]);
|
2016-03-03 17:16:49 +01:00
|
|
|
event.value = cpu_to_le32(key->down ? 1 : 0);
|
2014-04-01 10:06:29 +02:00
|
|
|
virtio_input_send(vinput, &event);
|
|
|
|
} else {
|
2016-03-03 17:16:49 +01:00
|
|
|
if (key->down) {
|
2014-04-01 10:06:29 +02:00
|
|
|
fprintf(stderr, "%s: unmapped key: %d [%s]\n", __func__,
|
2017-08-24 10:46:08 +02:00
|
|
|
qcode, QKeyCode_str(qcode));
|
2014-04-01 10:06:29 +02:00
|
|
|
}
|
|
|
|
}
|
|
|
|
break;
|
|
|
|
case INPUT_EVENT_KIND_BTN:
|
qapi: Don't special-case simple union wrappers
Simple unions were carrying a special case that hid their 'data'
QMP member from the resulting C struct, via the hack method
QAPISchemaObjectTypeVariant.simple_union_type(). But by using
the work we started by unboxing flat union and alternate
branches, coupled with the ability to visit the members of an
implicit type, we can now expose the simple union's implicit
type in qapi-types.h:
| struct q_obj_ImageInfoSpecificQCow2_wrapper {
| ImageInfoSpecificQCow2 *data;
| };
|
| struct q_obj_ImageInfoSpecificVmdk_wrapper {
| ImageInfoSpecificVmdk *data;
| };
...
| struct ImageInfoSpecific {
| ImageInfoSpecificKind type;
| union { /* union tag is @type */
| void *data;
|- ImageInfoSpecificQCow2 *qcow2;
|- ImageInfoSpecificVmdk *vmdk;
|+ q_obj_ImageInfoSpecificQCow2_wrapper qcow2;
|+ q_obj_ImageInfoSpecificVmdk_wrapper vmdk;
| } u;
| };
Doing this removes asymmetry between QAPI's QMP side and its
C side (both sides now expose 'data'), and means that the
treatment of a simple union as sugar for a flat union is now
equivalent in both languages (previously the two approaches used
a different layer of dereferencing, where the simple union could
be converted to a flat union with equivalent C layout but
different {} on the wire, or to an equivalent QMP wire form
but with different C representation). Using the implicit type
also lets us get rid of the simple_union_type() hack.
Of course, now all clients of simple unions have to adjust from
using su->u.member to using su->u.member.data; while this touches
a number of files in the tree, some earlier cleanup patches
helped minimize the change to the initialization of a temporary
variable rather than every single member access. The generated
qapi-visit.c code is also affected by the layout change:
|@@ -7393,10 +7393,10 @@ void visit_type_ImageInfoSpecific_member
| }
| switch (obj->type) {
| case IMAGE_INFO_SPECIFIC_KIND_QCOW2:
|- visit_type_ImageInfoSpecificQCow2(v, "data", &obj->u.qcow2, &err);
|+ visit_type_q_obj_ImageInfoSpecificQCow2_wrapper_members(v, &obj->u.qcow2, &err);
| break;
| case IMAGE_INFO_SPECIFIC_KIND_VMDK:
|- visit_type_ImageInfoSpecificVmdk(v, "data", &obj->u.vmdk, &err);
|+ visit_type_q_obj_ImageInfoSpecificVmdk_wrapper_members(v, &obj->u.vmdk, &err);
| break;
| default:
| abort();
Signed-off-by: Eric Blake <eblake@redhat.com>
Message-Id: <1458254921-17042-13-git-send-email-eblake@redhat.com>
Signed-off-by: Markus Armbruster <armbru@redhat.com>
2016-03-17 23:48:37 +01:00
|
|
|
btn = evt->u.btn.data;
|
2017-12-22 16:25:31 +01:00
|
|
|
if (vhid->wheel_axis &&
|
|
|
|
(btn->button == INPUT_BUTTON_WHEEL_UP ||
|
|
|
|
btn->button == INPUT_BUTTON_WHEEL_DOWN) &&
|
|
|
|
btn->down) {
|
2017-09-26 13:32:43 +02:00
|
|
|
event.type = cpu_to_le16(EV_REL);
|
|
|
|
event.code = cpu_to_le16(REL_WHEEL);
|
|
|
|
event.value = cpu_to_le32(btn->button == INPUT_BUTTON_WHEEL_UP
|
|
|
|
? 1 : -1);
|
|
|
|
virtio_input_send(vinput, &event);
|
|
|
|
} else if (keymap_button[btn->button]) {
|
2014-04-01 10:06:29 +02:00
|
|
|
event.type = cpu_to_le16(EV_KEY);
|
2016-03-03 17:16:49 +01:00
|
|
|
event.code = cpu_to_le16(keymap_button[btn->button]);
|
|
|
|
event.value = cpu_to_le32(btn->down ? 1 : 0);
|
2014-04-01 10:06:29 +02:00
|
|
|
virtio_input_send(vinput, &event);
|
|
|
|
} else {
|
2016-03-03 17:16:49 +01:00
|
|
|
if (btn->down) {
|
2014-04-01 10:06:29 +02:00
|
|
|
fprintf(stderr, "%s: unmapped button: %d [%s]\n", __func__,
|
2016-03-03 17:16:49 +01:00
|
|
|
btn->button,
|
2017-08-24 10:46:08 +02:00
|
|
|
InputButton_str(btn->button));
|
2014-04-01 10:06:29 +02:00
|
|
|
}
|
|
|
|
}
|
|
|
|
break;
|
|
|
|
case INPUT_EVENT_KIND_REL:
|
qapi: Don't special-case simple union wrappers
Simple unions were carrying a special case that hid their 'data'
QMP member from the resulting C struct, via the hack method
QAPISchemaObjectTypeVariant.simple_union_type(). But by using
the work we started by unboxing flat union and alternate
branches, coupled with the ability to visit the members of an
implicit type, we can now expose the simple union's implicit
type in qapi-types.h:
| struct q_obj_ImageInfoSpecificQCow2_wrapper {
| ImageInfoSpecificQCow2 *data;
| };
|
| struct q_obj_ImageInfoSpecificVmdk_wrapper {
| ImageInfoSpecificVmdk *data;
| };
...
| struct ImageInfoSpecific {
| ImageInfoSpecificKind type;
| union { /* union tag is @type */
| void *data;
|- ImageInfoSpecificQCow2 *qcow2;
|- ImageInfoSpecificVmdk *vmdk;
|+ q_obj_ImageInfoSpecificQCow2_wrapper qcow2;
|+ q_obj_ImageInfoSpecificVmdk_wrapper vmdk;
| } u;
| };
Doing this removes asymmetry between QAPI's QMP side and its
C side (both sides now expose 'data'), and means that the
treatment of a simple union as sugar for a flat union is now
equivalent in both languages (previously the two approaches used
a different layer of dereferencing, where the simple union could
be converted to a flat union with equivalent C layout but
different {} on the wire, or to an equivalent QMP wire form
but with different C representation). Using the implicit type
also lets us get rid of the simple_union_type() hack.
Of course, now all clients of simple unions have to adjust from
using su->u.member to using su->u.member.data; while this touches
a number of files in the tree, some earlier cleanup patches
helped minimize the change to the initialization of a temporary
variable rather than every single member access. The generated
qapi-visit.c code is also affected by the layout change:
|@@ -7393,10 +7393,10 @@ void visit_type_ImageInfoSpecific_member
| }
| switch (obj->type) {
| case IMAGE_INFO_SPECIFIC_KIND_QCOW2:
|- visit_type_ImageInfoSpecificQCow2(v, "data", &obj->u.qcow2, &err);
|+ visit_type_q_obj_ImageInfoSpecificQCow2_wrapper_members(v, &obj->u.qcow2, &err);
| break;
| case IMAGE_INFO_SPECIFIC_KIND_VMDK:
|- visit_type_ImageInfoSpecificVmdk(v, "data", &obj->u.vmdk, &err);
|+ visit_type_q_obj_ImageInfoSpecificVmdk_wrapper_members(v, &obj->u.vmdk, &err);
| break;
| default:
| abort();
Signed-off-by: Eric Blake <eblake@redhat.com>
Message-Id: <1458254921-17042-13-git-send-email-eblake@redhat.com>
Signed-off-by: Markus Armbruster <armbru@redhat.com>
2016-03-17 23:48:37 +01:00
|
|
|
move = evt->u.rel.data;
|
2014-04-01 10:06:29 +02:00
|
|
|
event.type = cpu_to_le16(EV_REL);
|
2016-03-03 17:16:49 +01:00
|
|
|
event.code = cpu_to_le16(axismap_rel[move->axis]);
|
|
|
|
event.value = cpu_to_le32(move->value);
|
2014-04-01 10:06:29 +02:00
|
|
|
virtio_input_send(vinput, &event);
|
|
|
|
break;
|
|
|
|
case INPUT_EVENT_KIND_ABS:
|
qapi: Don't special-case simple union wrappers
Simple unions were carrying a special case that hid their 'data'
QMP member from the resulting C struct, via the hack method
QAPISchemaObjectTypeVariant.simple_union_type(). But by using
the work we started by unboxing flat union and alternate
branches, coupled with the ability to visit the members of an
implicit type, we can now expose the simple union's implicit
type in qapi-types.h:
| struct q_obj_ImageInfoSpecificQCow2_wrapper {
| ImageInfoSpecificQCow2 *data;
| };
|
| struct q_obj_ImageInfoSpecificVmdk_wrapper {
| ImageInfoSpecificVmdk *data;
| };
...
| struct ImageInfoSpecific {
| ImageInfoSpecificKind type;
| union { /* union tag is @type */
| void *data;
|- ImageInfoSpecificQCow2 *qcow2;
|- ImageInfoSpecificVmdk *vmdk;
|+ q_obj_ImageInfoSpecificQCow2_wrapper qcow2;
|+ q_obj_ImageInfoSpecificVmdk_wrapper vmdk;
| } u;
| };
Doing this removes asymmetry between QAPI's QMP side and its
C side (both sides now expose 'data'), and means that the
treatment of a simple union as sugar for a flat union is now
equivalent in both languages (previously the two approaches used
a different layer of dereferencing, where the simple union could
be converted to a flat union with equivalent C layout but
different {} on the wire, or to an equivalent QMP wire form
but with different C representation). Using the implicit type
also lets us get rid of the simple_union_type() hack.
Of course, now all clients of simple unions have to adjust from
using su->u.member to using su->u.member.data; while this touches
a number of files in the tree, some earlier cleanup patches
helped minimize the change to the initialization of a temporary
variable rather than every single member access. The generated
qapi-visit.c code is also affected by the layout change:
|@@ -7393,10 +7393,10 @@ void visit_type_ImageInfoSpecific_member
| }
| switch (obj->type) {
| case IMAGE_INFO_SPECIFIC_KIND_QCOW2:
|- visit_type_ImageInfoSpecificQCow2(v, "data", &obj->u.qcow2, &err);
|+ visit_type_q_obj_ImageInfoSpecificQCow2_wrapper_members(v, &obj->u.qcow2, &err);
| break;
| case IMAGE_INFO_SPECIFIC_KIND_VMDK:
|- visit_type_ImageInfoSpecificVmdk(v, "data", &obj->u.vmdk, &err);
|+ visit_type_q_obj_ImageInfoSpecificVmdk_wrapper_members(v, &obj->u.vmdk, &err);
| break;
| default:
| abort();
Signed-off-by: Eric Blake <eblake@redhat.com>
Message-Id: <1458254921-17042-13-git-send-email-eblake@redhat.com>
Signed-off-by: Markus Armbruster <armbru@redhat.com>
2016-03-17 23:48:37 +01:00
|
|
|
move = evt->u.abs.data;
|
2014-04-01 10:06:29 +02:00
|
|
|
event.type = cpu_to_le16(EV_ABS);
|
2016-03-03 17:16:49 +01:00
|
|
|
event.code = cpu_to_le16(axismap_abs[move->axis]);
|
|
|
|
event.value = cpu_to_le32(move->value);
|
2014-04-01 10:06:29 +02:00
|
|
|
virtio_input_send(vinput, &event);
|
|
|
|
break;
|
|
|
|
default:
|
|
|
|
/* keep gcc happy */
|
|
|
|
break;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
static void virtio_input_handle_sync(DeviceState *dev)
|
|
|
|
{
|
|
|
|
VirtIOInput *vinput = VIRTIO_INPUT(dev);
|
|
|
|
virtio_input_event event = {
|
|
|
|
.type = cpu_to_le16(EV_SYN),
|
|
|
|
.code = cpu_to_le16(SYN_REPORT),
|
|
|
|
.value = 0,
|
|
|
|
};
|
|
|
|
|
|
|
|
virtio_input_send(vinput, &event);
|
|
|
|
}
|
|
|
|
|
|
|
|
static void virtio_input_hid_realize(DeviceState *dev, Error **errp)
|
|
|
|
{
|
|
|
|
VirtIOInputHID *vhid = VIRTIO_INPUT_HID(dev);
|
2015-06-24 11:59:16 +02:00
|
|
|
|
2014-04-01 10:06:29 +02:00
|
|
|
vhid->hs = qemu_input_handler_register(dev, vhid->handler);
|
2015-06-24 11:59:16 +02:00
|
|
|
if (vhid->display && vhid->hs) {
|
|
|
|
qemu_input_handler_bind(vhid->hs, vhid->display, vhid->head, NULL);
|
|
|
|
}
|
2014-04-01 10:06:29 +02:00
|
|
|
}
|
|
|
|
|
|
|
|
static void virtio_input_hid_unrealize(DeviceState *dev, Error **errp)
|
|
|
|
{
|
|
|
|
VirtIOInputHID *vhid = VIRTIO_INPUT_HID(dev);
|
|
|
|
qemu_input_handler_unregister(vhid->hs);
|
|
|
|
}
|
|
|
|
|
|
|
|
static void virtio_input_hid_change_active(VirtIOInput *vinput)
|
|
|
|
{
|
|
|
|
VirtIOInputHID *vhid = VIRTIO_INPUT_HID(vinput);
|
|
|
|
|
|
|
|
if (vinput->active) {
|
|
|
|
qemu_input_handler_activate(vhid->hs);
|
|
|
|
} else {
|
|
|
|
qemu_input_handler_deactivate(vhid->hs);
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
static void virtio_input_hid_handle_status(VirtIOInput *vinput,
|
|
|
|
virtio_input_event *event)
|
|
|
|
{
|
|
|
|
VirtIOInputHID *vhid = VIRTIO_INPUT_HID(vinput);
|
|
|
|
int ledbit = 0;
|
|
|
|
|
|
|
|
switch (le16_to_cpu(event->type)) {
|
|
|
|
case EV_LED:
|
|
|
|
if (event->code == LED_NUML) {
|
|
|
|
ledbit = QEMU_NUM_LOCK_LED;
|
|
|
|
} else if (event->code == LED_CAPSL) {
|
|
|
|
ledbit = QEMU_CAPS_LOCK_LED;
|
|
|
|
} else if (event->code == LED_SCROLLL) {
|
|
|
|
ledbit = QEMU_SCROLL_LOCK_LED;
|
|
|
|
}
|
|
|
|
if (event->value) {
|
|
|
|
vhid->ledstate |= ledbit;
|
|
|
|
} else {
|
|
|
|
vhid->ledstate &= ~ledbit;
|
|
|
|
}
|
|
|
|
kbd_put_ledstate(vhid->ledstate);
|
|
|
|
break;
|
|
|
|
default:
|
|
|
|
fprintf(stderr, "%s: unknown type %d\n", __func__,
|
|
|
|
le16_to_cpu(event->type));
|
|
|
|
break;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2015-06-24 11:59:16 +02:00
|
|
|
static Property virtio_input_hid_properties[] = {
|
|
|
|
DEFINE_PROP_STRING("display", VirtIOInputHID, display),
|
|
|
|
DEFINE_PROP_UINT32("head", VirtIOInputHID, head, 0),
|
2015-07-14 13:27:30 +02:00
|
|
|
DEFINE_PROP_END_OF_LIST(),
|
2015-06-24 11:59:16 +02:00
|
|
|
};
|
|
|
|
|
2014-04-01 10:06:29 +02:00
|
|
|
static void virtio_input_hid_class_init(ObjectClass *klass, void *data)
|
|
|
|
{
|
2015-06-24 11:59:16 +02:00
|
|
|
DeviceClass *dc = DEVICE_CLASS(klass);
|
2014-04-01 10:06:29 +02:00
|
|
|
VirtIOInputClass *vic = VIRTIO_INPUT_CLASS(klass);
|
|
|
|
|
2015-06-24 11:59:16 +02:00
|
|
|
dc->props = virtio_input_hid_properties;
|
2014-04-01 10:06:29 +02:00
|
|
|
vic->realize = virtio_input_hid_realize;
|
|
|
|
vic->unrealize = virtio_input_hid_unrealize;
|
|
|
|
vic->change_active = virtio_input_hid_change_active;
|
|
|
|
vic->handle_status = virtio_input_hid_handle_status;
|
|
|
|
}
|
|
|
|
|
|
|
|
static const TypeInfo virtio_input_hid_info = {
|
|
|
|
.name = TYPE_VIRTIO_INPUT_HID,
|
|
|
|
.parent = TYPE_VIRTIO_INPUT,
|
|
|
|
.instance_size = sizeof(VirtIOInputHID),
|
|
|
|
.class_init = virtio_input_hid_class_init,
|
|
|
|
.abstract = true,
|
|
|
|
};
|
|
|
|
|
|
|
|
/* ----------------------------------------------------------------- */
|
|
|
|
|
|
|
|
static QemuInputHandler virtio_keyboard_handler = {
|
|
|
|
.name = VIRTIO_ID_NAME_KEYBOARD,
|
|
|
|
.mask = INPUT_EVENT_MASK_KEY,
|
|
|
|
.event = virtio_input_handle_event,
|
|
|
|
.sync = virtio_input_handle_sync,
|
|
|
|
};
|
|
|
|
|
|
|
|
static struct virtio_input_config virtio_keyboard_config[] = {
|
|
|
|
{
|
|
|
|
.select = VIRTIO_INPUT_CFG_ID_NAME,
|
|
|
|
.size = sizeof(VIRTIO_ID_NAME_KEYBOARD),
|
|
|
|
.u.string = VIRTIO_ID_NAME_KEYBOARD,
|
|
|
|
},{
|
|
|
|
.select = VIRTIO_INPUT_CFG_ID_DEVIDS,
|
|
|
|
.size = sizeof(struct virtio_input_devids),
|
|
|
|
.u.ids = {
|
|
|
|
.bustype = const_le16(BUS_VIRTUAL),
|
|
|
|
.vendor = const_le16(0x0627), /* same we use for usb hid devices */
|
|
|
|
.product = const_le16(0x0001),
|
|
|
|
.version = const_le16(0x0001),
|
|
|
|
},
|
|
|
|
},{
|
|
|
|
.select = VIRTIO_INPUT_CFG_EV_BITS,
|
|
|
|
.subsel = EV_REP,
|
|
|
|
.size = 1,
|
|
|
|
},{
|
|
|
|
.select = VIRTIO_INPUT_CFG_EV_BITS,
|
|
|
|
.subsel = EV_LED,
|
|
|
|
.size = 1,
|
|
|
|
.u.bitmap = {
|
|
|
|
(1 << LED_NUML) | (1 << LED_CAPSL) | (1 << LED_SCROLLL),
|
|
|
|
},
|
|
|
|
},
|
|
|
|
{ /* end of list */ },
|
|
|
|
};
|
|
|
|
|
|
|
|
static void virtio_keyboard_init(Object *obj)
|
|
|
|
{
|
|
|
|
VirtIOInputHID *vhid = VIRTIO_INPUT_HID(obj);
|
|
|
|
VirtIOInput *vinput = VIRTIO_INPUT(obj);
|
|
|
|
|
|
|
|
vhid->handler = &virtio_keyboard_handler;
|
|
|
|
virtio_input_init_config(vinput, virtio_keyboard_config);
|
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 <berrange@redhat.com>
Message-id: 20180117164118.8510-5-berrange@redhat.com
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
2018-01-17 17:41:18 +01:00
|
|
|
virtio_input_key_config(vinput, qemu_input_map_qcode_to_linux,
|
|
|
|
qemu_input_map_qcode_to_linux_len);
|
2014-04-01 10:06:29 +02:00
|
|
|
}
|
|
|
|
|
|
|
|
static const TypeInfo virtio_keyboard_info = {
|
|
|
|
.name = TYPE_VIRTIO_KEYBOARD,
|
|
|
|
.parent = TYPE_VIRTIO_INPUT_HID,
|
|
|
|
.instance_size = sizeof(VirtIOInputHID),
|
|
|
|
.instance_init = virtio_keyboard_init,
|
|
|
|
};
|
|
|
|
|
|
|
|
/* ----------------------------------------------------------------- */
|
|
|
|
|
|
|
|
static QemuInputHandler virtio_mouse_handler = {
|
|
|
|
.name = VIRTIO_ID_NAME_MOUSE,
|
|
|
|
.mask = INPUT_EVENT_MASK_BTN | INPUT_EVENT_MASK_REL,
|
|
|
|
.event = virtio_input_handle_event,
|
|
|
|
.sync = virtio_input_handle_sync,
|
|
|
|
};
|
|
|
|
|
2017-09-26 13:32:43 +02:00
|
|
|
static struct virtio_input_config virtio_mouse_config_v1[] = {
|
2014-04-01 10:06:29 +02:00
|
|
|
{
|
|
|
|
.select = VIRTIO_INPUT_CFG_ID_NAME,
|
|
|
|
.size = sizeof(VIRTIO_ID_NAME_MOUSE),
|
|
|
|
.u.string = VIRTIO_ID_NAME_MOUSE,
|
|
|
|
},{
|
|
|
|
.select = VIRTIO_INPUT_CFG_ID_DEVIDS,
|
|
|
|
.size = sizeof(struct virtio_input_devids),
|
|
|
|
.u.ids = {
|
|
|
|
.bustype = const_le16(BUS_VIRTUAL),
|
|
|
|
.vendor = const_le16(0x0627), /* same we use for usb hid devices */
|
|
|
|
.product = const_le16(0x0002),
|
|
|
|
.version = const_le16(0x0001),
|
|
|
|
},
|
|
|
|
},{
|
|
|
|
.select = VIRTIO_INPUT_CFG_EV_BITS,
|
|
|
|
.subsel = EV_REL,
|
|
|
|
.size = 1,
|
|
|
|
.u.bitmap = {
|
|
|
|
(1 << REL_X) | (1 << REL_Y),
|
|
|
|
},
|
|
|
|
},
|
|
|
|
{ /* end of list */ },
|
|
|
|
};
|
|
|
|
|
2017-09-26 13:32:43 +02:00
|
|
|
static struct virtio_input_config virtio_mouse_config_v2[] = {
|
|
|
|
{
|
|
|
|
.select = VIRTIO_INPUT_CFG_ID_NAME,
|
|
|
|
.size = sizeof(VIRTIO_ID_NAME_MOUSE),
|
|
|
|
.u.string = VIRTIO_ID_NAME_MOUSE,
|
|
|
|
},{
|
|
|
|
.select = VIRTIO_INPUT_CFG_ID_DEVIDS,
|
|
|
|
.size = sizeof(struct virtio_input_devids),
|
|
|
|
.u.ids = {
|
|
|
|
.bustype = const_le16(BUS_VIRTUAL),
|
|
|
|
.vendor = const_le16(0x0627), /* same we use for usb hid devices */
|
|
|
|
.product = const_le16(0x0002),
|
|
|
|
.version = const_le16(0x0002),
|
|
|
|
},
|
|
|
|
},{
|
|
|
|
.select = VIRTIO_INPUT_CFG_EV_BITS,
|
|
|
|
.subsel = EV_REL,
|
|
|
|
.size = 2,
|
|
|
|
.u.bitmap = {
|
|
|
|
(1 << REL_X) | (1 << REL_Y),
|
|
|
|
(1 << (REL_WHEEL - 8))
|
|
|
|
},
|
|
|
|
},
|
|
|
|
{ /* end of list */ },
|
|
|
|
};
|
|
|
|
|
|
|
|
static Property virtio_mouse_properties[] = {
|
|
|
|
DEFINE_PROP_BOOL("wheel-axis", VirtIOInputHID, wheel_axis, true),
|
|
|
|
DEFINE_PROP_END_OF_LIST(),
|
|
|
|
};
|
|
|
|
|
|
|
|
static void virtio_mouse_class_init(ObjectClass *klass, void *data)
|
|
|
|
{
|
|
|
|
DeviceClass *dc = DEVICE_CLASS(klass);
|
|
|
|
|
|
|
|
dc->props = virtio_mouse_properties;
|
|
|
|
}
|
|
|
|
|
2014-04-01 10:06:29 +02:00
|
|
|
static void virtio_mouse_init(Object *obj)
|
|
|
|
{
|
|
|
|
VirtIOInputHID *vhid = VIRTIO_INPUT_HID(obj);
|
|
|
|
VirtIOInput *vinput = VIRTIO_INPUT(obj);
|
|
|
|
|
|
|
|
vhid->handler = &virtio_mouse_handler;
|
2017-09-26 13:32:43 +02:00
|
|
|
virtio_input_init_config(vinput, vhid->wheel_axis
|
|
|
|
? virtio_mouse_config_v2
|
|
|
|
: virtio_mouse_config_v1);
|
2014-04-01 10:06:29 +02:00
|
|
|
virtio_input_key_config(vinput, keymap_button,
|
|
|
|
ARRAY_SIZE(keymap_button));
|
|
|
|
}
|
|
|
|
|
|
|
|
static const TypeInfo virtio_mouse_info = {
|
|
|
|
.name = TYPE_VIRTIO_MOUSE,
|
|
|
|
.parent = TYPE_VIRTIO_INPUT_HID,
|
|
|
|
.instance_size = sizeof(VirtIOInputHID),
|
|
|
|
.instance_init = virtio_mouse_init,
|
2017-09-26 13:32:43 +02:00
|
|
|
.class_init = virtio_mouse_class_init,
|
2014-04-01 10:06:29 +02:00
|
|
|
};
|
|
|
|
|
|
|
|
/* ----------------------------------------------------------------- */
|
|
|
|
|
|
|
|
static QemuInputHandler virtio_tablet_handler = {
|
|
|
|
.name = VIRTIO_ID_NAME_TABLET,
|
|
|
|
.mask = INPUT_EVENT_MASK_BTN | INPUT_EVENT_MASK_ABS,
|
|
|
|
.event = virtio_input_handle_event,
|
|
|
|
.sync = virtio_input_handle_sync,
|
|
|
|
};
|
|
|
|
|
2017-09-26 13:32:43 +02:00
|
|
|
static struct virtio_input_config virtio_tablet_config_v1[] = {
|
2014-04-01 10:06:29 +02:00
|
|
|
{
|
|
|
|
.select = VIRTIO_INPUT_CFG_ID_NAME,
|
|
|
|
.size = sizeof(VIRTIO_ID_NAME_TABLET),
|
|
|
|
.u.string = VIRTIO_ID_NAME_TABLET,
|
|
|
|
},{
|
|
|
|
.select = VIRTIO_INPUT_CFG_ID_DEVIDS,
|
|
|
|
.size = sizeof(struct virtio_input_devids),
|
|
|
|
.u.ids = {
|
|
|
|
.bustype = const_le16(BUS_VIRTUAL),
|
|
|
|
.vendor = const_le16(0x0627), /* same we use for usb hid devices */
|
|
|
|
.product = const_le16(0x0003),
|
|
|
|
.version = const_le16(0x0001),
|
|
|
|
},
|
|
|
|
},{
|
|
|
|
.select = VIRTIO_INPUT_CFG_EV_BITS,
|
|
|
|
.subsel = EV_ABS,
|
|
|
|
.size = 1,
|
|
|
|
.u.bitmap = {
|
|
|
|
(1 << ABS_X) | (1 << ABS_Y),
|
|
|
|
},
|
|
|
|
},{
|
|
|
|
.select = VIRTIO_INPUT_CFG_ABS_INFO,
|
|
|
|
.subsel = ABS_X,
|
|
|
|
.size = sizeof(virtio_input_absinfo),
|
2017-05-05 15:39:52 +02:00
|
|
|
.u.abs.min = const_le32(INPUT_EVENT_ABS_MIN),
|
|
|
|
.u.abs.max = const_le32(INPUT_EVENT_ABS_MAX),
|
2014-04-01 10:06:29 +02:00
|
|
|
},{
|
|
|
|
.select = VIRTIO_INPUT_CFG_ABS_INFO,
|
|
|
|
.subsel = ABS_Y,
|
|
|
|
.size = sizeof(virtio_input_absinfo),
|
2017-05-05 15:39:52 +02:00
|
|
|
.u.abs.min = const_le32(INPUT_EVENT_ABS_MIN),
|
|
|
|
.u.abs.max = const_le32(INPUT_EVENT_ABS_MAX),
|
2014-04-01 10:06:29 +02:00
|
|
|
},
|
|
|
|
{ /* end of list */ },
|
|
|
|
};
|
|
|
|
|
2017-09-26 13:32:43 +02:00
|
|
|
static struct virtio_input_config virtio_tablet_config_v2[] = {
|
|
|
|
{
|
|
|
|
.select = VIRTIO_INPUT_CFG_ID_NAME,
|
|
|
|
.size = sizeof(VIRTIO_ID_NAME_TABLET),
|
|
|
|
.u.string = VIRTIO_ID_NAME_TABLET,
|
|
|
|
},{
|
|
|
|
.select = VIRTIO_INPUT_CFG_ID_DEVIDS,
|
|
|
|
.size = sizeof(struct virtio_input_devids),
|
|
|
|
.u.ids = {
|
|
|
|
.bustype = const_le16(BUS_VIRTUAL),
|
|
|
|
.vendor = const_le16(0x0627), /* same we use for usb hid devices */
|
|
|
|
.product = const_le16(0x0003),
|
|
|
|
.version = const_le16(0x0002),
|
|
|
|
},
|
|
|
|
},{
|
|
|
|
.select = VIRTIO_INPUT_CFG_EV_BITS,
|
|
|
|
.subsel = EV_ABS,
|
|
|
|
.size = 1,
|
|
|
|
.u.bitmap = {
|
|
|
|
(1 << ABS_X) | (1 << ABS_Y),
|
|
|
|
},
|
|
|
|
},{
|
|
|
|
.select = VIRTIO_INPUT_CFG_EV_BITS,
|
|
|
|
.subsel = EV_REL,
|
|
|
|
.size = 2,
|
|
|
|
.u.bitmap = {
|
|
|
|
0,
|
|
|
|
(1 << (REL_WHEEL - 8))
|
|
|
|
},
|
|
|
|
},{
|
|
|
|
.select = VIRTIO_INPUT_CFG_ABS_INFO,
|
|
|
|
.subsel = ABS_X,
|
|
|
|
.size = sizeof(virtio_input_absinfo),
|
|
|
|
.u.abs.min = const_le32(INPUT_EVENT_ABS_MIN),
|
|
|
|
.u.abs.max = const_le32(INPUT_EVENT_ABS_MAX),
|
|
|
|
},{
|
|
|
|
.select = VIRTIO_INPUT_CFG_ABS_INFO,
|
|
|
|
.subsel = ABS_Y,
|
|
|
|
.size = sizeof(virtio_input_absinfo),
|
|
|
|
.u.abs.min = const_le32(INPUT_EVENT_ABS_MIN),
|
|
|
|
.u.abs.max = const_le32(INPUT_EVENT_ABS_MAX),
|
|
|
|
},
|
|
|
|
{ /* end of list */ },
|
|
|
|
};
|
|
|
|
|
|
|
|
static Property virtio_tablet_properties[] = {
|
|
|
|
DEFINE_PROP_BOOL("wheel-axis", VirtIOInputHID, wheel_axis, true),
|
|
|
|
DEFINE_PROP_END_OF_LIST(),
|
|
|
|
};
|
|
|
|
|
|
|
|
static void virtio_tablet_class_init(ObjectClass *klass, void *data)
|
|
|
|
{
|
|
|
|
DeviceClass *dc = DEVICE_CLASS(klass);
|
|
|
|
|
|
|
|
dc->props = virtio_tablet_properties;
|
|
|
|
}
|
|
|
|
|
2014-04-01 10:06:29 +02:00
|
|
|
static void virtio_tablet_init(Object *obj)
|
|
|
|
{
|
|
|
|
VirtIOInputHID *vhid = VIRTIO_INPUT_HID(obj);
|
|
|
|
VirtIOInput *vinput = VIRTIO_INPUT(obj);
|
|
|
|
|
|
|
|
vhid->handler = &virtio_tablet_handler;
|
2017-09-26 13:32:43 +02:00
|
|
|
virtio_input_init_config(vinput, vhid->wheel_axis
|
|
|
|
? virtio_tablet_config_v2
|
|
|
|
: virtio_tablet_config_v1);
|
2014-04-01 10:06:29 +02:00
|
|
|
virtio_input_key_config(vinput, keymap_button,
|
|
|
|
ARRAY_SIZE(keymap_button));
|
|
|
|
}
|
|
|
|
|
|
|
|
static const TypeInfo virtio_tablet_info = {
|
|
|
|
.name = TYPE_VIRTIO_TABLET,
|
|
|
|
.parent = TYPE_VIRTIO_INPUT_HID,
|
|
|
|
.instance_size = sizeof(VirtIOInputHID),
|
|
|
|
.instance_init = virtio_tablet_init,
|
2017-09-26 13:32:43 +02:00
|
|
|
.class_init = virtio_tablet_class_init,
|
2014-04-01 10:06:29 +02:00
|
|
|
};
|
|
|
|
|
|
|
|
/* ----------------------------------------------------------------- */
|
|
|
|
|
|
|
|
static void virtio_register_types(void)
|
|
|
|
{
|
|
|
|
type_register_static(&virtio_input_hid_info);
|
|
|
|
type_register_static(&virtio_keyboard_info);
|
|
|
|
type_register_static(&virtio_mouse_info);
|
|
|
|
type_register_static(&virtio_tablet_info);
|
|
|
|
}
|
|
|
|
|
|
|
|
type_init(virtio_register_types)
|