From: "Daniel P. Berrange" <berrange@redhat.com>
To: Gerd Hoffmann <kraxel@redhat.com>
Cc: "Hervé Poussineau" <hpoussin@reactos.org>, qemu-devel@nongnu.org
Subject: Re: [Qemu-devel] [PATCH for 2.10] ps2: fix sending of PAUSE/BREAK scancodes
Date: Thu, 27 Jul 2017 10:50:33 +0100 [thread overview]
Message-ID: <20170727095033.GD2555@redhat.com> (raw)
In-Reply-To: <20170726124551.GK7620@redhat.com>
On Wed, Jul 26, 2017 at 01:45:51PM +0100, Daniel P. Berrange wrote:
> On Wed, Jul 26, 2017 at 02:33:10PM +0200, Gerd Hoffmann wrote:
> > Hi,
> >
> > > FYI, after adding qcodes to the keycodemapdb, (but not having picked
> > > your branch),
> >
> > I don't think this is a good idea. qkeycode numbers are a qemu-private
> > thing, they can (and did in the past) change. The names are api and
> > must not change.
>
> Sorry, yes, I meant only adding the names - libvirt needs to know the
> qcode names and what they map to in other key maps, to use the send-key
> command.
>
> > > I was actually just going add an entry for QKeyCode names to the
> > > keycodemapdb, so we can convert straight to that, and also let
> > > us auto-generate the qemu_input_linux_to_qcode() table.
> >
> > Ok, with the names it should work.
> >
> > > Strangely there is no Linux key code defined for AltGr, so if we
> > > map via Linux key codes, we would loose ability to send AltGr
> >
> > KEY_RIGHTALT?
>
> It seems KEY_RIGHTALT is different from AltGr - it maps to AT set 1
> extended scancode 0xe0 0x38, where as AltGr generates 0x64 on my
> keyboard
Opps, no I was mis-interpreting the evdev output.
Physical key AltGr *does* produce KEY_RIGHTALT, Linux keycode 100,
AT set1 scan code 0xe0 0x38, QEMU qcode alt_r, QEMU scancode 0xb8
What is confusing is that QEMU defines qcodes for alt, alt_r *and*
altgr and altgr_r.
QEMU's altgr scancode is 0x64 (qcode_to_number). The only Linux
keycode that produces that AT set1 scancode is KEY_OPEN. There is
no mapping in qcode_to_keycode_set1 for this, which is odd given
that the set1 mapping should be the same as qcode_to_number mapping
except different high bit handling. There is a mapping in
qcode_to_keycode_set2 which corresponds to 0x08 and afaik that
should not exist as there's no set2 scancode 0x08
QEMU's altgr_r scan code is 0xe4 (qcode_to_number), which is equiv
to at set1 0xe0 0x64, and that should not exist afaik. There is
no mapping in qcode_to_keycode_set1, which is again odd given that
this should be the same as qcode_to_number. There is a mapping
in qcode_to_keycode_set2 which corresponds to 0xe0 0x08 and afaik
that's not defined for set2 scancode.
So afaict, the altgr & altgr_r qcodes are just broken and should
not even exist.
Regards,
Daniel
--
|: https://berrange.com -o- https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org -o- https://fstop138.berrange.com :|
|: https://entangle-photo.org -o- https://www.instagram.com/dberrange :|
prev parent reply other threads:[~2017-07-27 9:50 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-07-24 16:46 [Qemu-devel] [PATCH for 2.10] ps2: fix sending of PAUSE/BREAK scancodes Daniel P. Berrange
2017-07-24 19:55 ` Hervé Poussineau
2017-07-25 8:32 ` Daniel P. Berrange
2017-07-25 11:53 ` Gerd Hoffmann
2017-07-26 11:28 ` Daniel P. Berrange
2017-07-26 11:44 ` Gerd Hoffmann
2017-07-26 12:05 ` Daniel P. Berrange
2017-07-26 12:33 ` Gerd Hoffmann
2017-07-26 12:45 ` Daniel P. Berrange
2017-07-27 9:50 ` Daniel P. Berrange [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20170727095033.GD2555@redhat.com \
--to=berrange@redhat.com \
--cc=hpoussin@reactos.org \
--cc=kraxel@redhat.com \
--cc=qemu-devel@nongnu.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).