qemu-devel
[Top][All Lists]
Advanced

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

Re: [Qemu-devel] [PATCH for 2.10] ps2: fix sending of PAUSE/BREAK scanco


From: Daniel P. Berrange
Subject: Re: [Qemu-devel] [PATCH for 2.10] ps2: fix sending of PAUSE/BREAK scancodes
Date: Thu, 27 Jul 2017 10:50:33 +0100
User-agent: Mutt/1.8.3 (2017-05-23)

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 :|



reply via email to

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