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: NEric Blake <eblake@redhat.com>
Message-Id: <1445898903-12082-20-git-send-email-eblake@redhat.com>
[Commit message tweaked slightly]
Signed-off-by: NMarkus Armbruster <armbru@redhat.com>

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: NGerd Hoffmann <kraxel@redhat.com>
Reviewed-by: NMarkus Armbruster <armbru@redhat.com>
Reviewed-by: NDaniel P. Berrange <berrange@redhat.com>
Reviewed-by: NMichael Tokarev <mjt@tls.msk.ru>

Signed-off-by: NGerd Hoffmann <kraxel@redhat.com>

Signed-off-by: NGerd Hoffmann <kraxel@redhat.com>

With sparc keyboard going directly from QKeyValue to sparc keycodes
this should not be needed any more.
Signed-off-by: NGerd Hoffmann <kraxel@redhat.com>

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: NGerd Hoffmann <kraxel@redhat.com>