summaryrefslogtreecommitdiffstats
path: root/ui/input-keymap.c
Commit message (Collapse)AuthorAgeFilesLines
* ui: Clean up includesPeter Maydell2019-11-291-0/+1
| | | | | | | | | | Clean up includes so that osdep.h is included first and headers which it implies are not included manually. This commit was created with scripts/clean-includes. Signed-off-by: Peter Maydell <peter.maydell@linaro.org> Message-id: 1454089805-5470-2-git-send-email-peter.maydell@linaro.org
* qapi: Don't let implicit enum MAX member collideEric Blake2019-11-291-2/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Now that we guarantee the user doesn't have any enum values beginning with a single underscore, we can use that for our own purposes. Renaming ENUM_MAX to ENUM__MAX makes it obvious that the sentinel is generated. This patch was mostly generated by applying a temporary patch: |diff --git a/scripts/qapi.py b/scripts/qapi.py |index e6d014b..b862ec9 100644 |--- a/scripts/qapi.py |+++ b/scripts/qapi.py |@@ -1570,6 +1570,7 @@ const char *const %(c_name)s_lookup[] = { | max_index = c_enum_const(name, 'MAX', prefix) | ret += mcgen(''' | [%(max_index)s] = NULL, |+// %(max_index)s | }; | ''', | max_index=max_index) then running: $ cat qapi-{types,event}.c tests/test-qapi-types.c | sed -n 's,^// \(.*\)MAX,s|\1MAX|\1_MAX|g,p' > list $ git grep -l _MAX | xargs sed -i -f list The only things not generated are the changes in scripts/qapi.py. Rejecting enum members named 'MAX' is now useless, and will be dropped in the next patch. Signed-off-by: Eric Blake <eblake@redhat.com> Message-Id: <1447836791-369-23-git-send-email-eblake@redhat.com> Reviewed-by: Juan Quintela <quintela@redhat.com> [Rebased to current master, commit message tweaked] Signed-off-by: Markus Armbruster <armbru@redhat.com>
* input: Convert to new qapi union layoutEric Blake2015-11-021-10/+10
| | | | | | | | | | | | | | | | | We have two issues with our qapi union layout: 1) Even though the QMP wire format spells the tag 'type', the C code spells it 'kind', requiring some hacks in the generator. 2) The C struct uses an anonymous union, which places all tag values in the same namespace as all non-variant members. This leads to spurious collisions if a tag value matches a non-variant member's name. Make the conversion to the new layout for input-related code. Signed-off-by: Eric Blake <eblake@redhat.com> Message-Id: <1445898903-12082-20-git-send-email-eblake@redhat.com> [Commit message tweaked slightly] Signed-off-by: Markus Armbruster <armbru@redhat.com>
* kbd: add brazil kbd keys to qemuGerd Hoffmann2015-05-291-0/+4
| | | | | | | | | | | | | | | | | | | | | | The brazilian computer keyboard layout has two extra keys (compared to the usual 105-key intl ps/2 keyboard). This patch makes these two keys known to qemu. For historic reasons qemu has two ways to specify a key: A QKeyCode (name-based) or a number (ps/2 scancode based). Therefore we have to update multiple places to make new keys known to qemu: (1) The QKeyCode definition in qapi-schema.json (2) The QKeyCode <-> number mapping table in ui/input-keymap.c This patch does just that. With this patch applied you can send those two keys to the guest using the send-key monitor command. Cc: qemu-stable@nongnu.org Signed-off-by: Gerd Hoffmann <kraxel@redhat.com> Reviewed-by: Markus Armbruster <armbru@redhat.com> Reviewed-by: Daniel P. Berrange <berrange@redhat.com> Reviewed-by: Michael Tokarev <mjt@tls.msk.ru>
* input: keymap: add meta keysGerd Hoffmann2014-05-261-0/+2
| | | | Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
* input: add qemu_input_key_number_to_qcodeGerd Hoffmann2014-05-261-3/+8
| | | | Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
* input: remove sparc keymap hackGerd Hoffmann2014-05-161-19/+0
| | | | | | | With sparc keyboard going directly from QKeyValue to sparc keycodes this should not be needed any more. Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
* input: key mapping helpersGerd Hoffmann2014-05-161-0/+210
Add helper functions to translate KeyValue (qapi key representation) into other representations: traditional qemu key numbers, qapi key codes (Q_KEY_CODE_*) and scancode sequences. Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
OpenPOWER on IntegriCloud