[Qemu-devel] Pipe key broken on US keyboards

[Qemu-devel] Pipe key broken on US keyboards

[Phillip Susi]

[-- Attachment #1: Type: text/plain, Size: 932 bytes --]

Hello, I recently upgraded my Xen server from Ubuntu 16.04 to 18.04 and
am no longer able to type a | over vnc to the xen vms.  When I press \
it works, but when I hold down shift and press \ which should generate a
|, the vm sees the scan code for some key that the keymap thinks should
sit between left shift and Z, but does not exist on US keyboards, and
that scan code produces a > when combined with shift.  I'm betting it
was this commit that broke it:

commit ab8f9d49d62c82a12409475547e4420a46da56ed
Author: Daniel P. Berrange <berrange@redhat.com>
Date:   Wed Jan 17 16:41:15 2018 +0000

    hw: convert ps2 device to keycodemapdb

    Replace the qcode_to_keycode_set1, qcode_to_keycode_set2,
    and qcode_to_keycode_set3 tables with automatically
    generated tables.

Any ideas?

According to xev in the vm, they scan code for \ is 51, and when I hold
down shift, it changes to scan code 94.



[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 473 bytes --]

Re: [Qemu-devel] Pipe key broken on US keyboards

[Daniel P. Berrangé]

On Thu, Aug 16, 2018 at 01:11:05PM -0400, Phillip Susi wrote:
> Hello, I recently upgraded my Xen server from Ubuntu 16.04 to 18.04 and
> am no longer able to type a | over vnc to the xen vms.  When I press \
> it works, but when I hold down shift and press \ which should generate a
> |, the vm sees the scan code for some key that the keymap thinks should
> sit between left shift and Z, but does not exist on US keyboards, and
> that scan code produces a > when combined with shift.  I'm betting it
> was this commit that broke it:
> 
> commit ab8f9d49d62c82a12409475547e4420a46da56ed
> Author: Daniel P. Berrange <berrange@redhat.com>
> Date:   Wed Jan 17 16:41:15 2018 +0000
> 
>     hw: convert ps2 device to keycodemapdb
> 
>     Replace the qcode_to_keycode_set1, qcode_to_keycode_set2,
>     and qcode_to_keycode_set3 tables with automatically
>     generated tables.
> 
> Any ideas?

Did you actually 'git bisect' to that commit, or is that just a guess ?

If not, could you 'git bisect' to confirm the actual commit, as there
have been lots of changes in this area.


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

Re: [Qemu-devel] Pipe key broken on US keyboards

[Phillip Susi]

[-- Attachment #1: Type: text/plain, Size: 813 bytes --]

On 8/16/2018 1:27 PM, Daniel P. Berrangé wrote:
> Did you actually 'git bisect' to that commit, or is that just a guess ?

No, I haven't actually tried to build it from sources myself yet so I
just found the source file that handles the keyboard, saw a bunch of
scancode translation stuff in it, did a git log on that file and that
first commit sticks out like a sore thumb; it changes the way scancodes
are translated in a big way and the timing of it seems about right.  The
other commits talk about fixing specific key codes that are unrelated to
pipe, and it looks like this commit threw out the code those commits
touched anyhow and refactored the whole thing.

> If not, could you 'git bisect' to confirm the actual commit, as there
> have been lots of changes in this area.

I'll try.



[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 473 bytes --]

Re: [Qemu-devel] Pipe key broken on US keyboards

[Daniel P. Berrangé]

On Thu, Aug 16, 2018 at 03:44:54PM -0400, Phillip Susi wrote:
> On 8/16/2018 1:27 PM, Daniel P. Berrangé wrote:
> > Did you actually 'git bisect' to that commit, or is that just a guess ?
> 
> No, I haven't actually tried to build it from sources myself yet so I
> just found the source file that handles the keyboard, saw a bunch of
> scancode translation stuff in it, did a git log on that file and that
> first commit sticks out like a sore thumb; it changes the way scancodes
> are translated in a big way and the timing of it seems about right.  The
> other commits talk about fixing specific key codes that are unrelated to
> pipe, and it looks like this commit threw out the code those commits
> touched anyhow and refactored the whole thing.

Oh one other thing, is whether your QEMU process has an explicit keymap
configured (this is the -k arg to QEMU), as when that it set, it
completely changes the way keyboard input is handled in VNC. That code
has also been massively refactored recently.

> > If not, could you 'git bisect' to confirm the actual commit, as there
> > have been lots of changes in this area.
> 
> I'll try.

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

Re: [Qemu-devel] Pipe key broken on US keyboards

[Phillip Susi]

[-- Attachment #1: Type: text/plain, Size: 440 bytes --]

On 8/17/2018 4:56 AM, Daniel P. Berrangé wrote:
> Oh one other thing, is whether your QEMU process has an explicit keymap
> configured (this is the -k arg to QEMU), as when that it set, it
> completely changes the way keyboard input is handled in VNC. That code
> has also been massively refactored recently.

I'm not using that argument.  I just checked the man page and it says it
defaults to en-us, which should be correct.



[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 473 bytes --]

Re: [Qemu-devel] Pipe key broken on US keyboards

[Daniel P. Berrangé]

On Thu, Aug 16, 2018 at 01:11:05PM -0400, Phillip Susi wrote:
> Hello, I recently upgraded my Xen server from Ubuntu 16.04 to 18.04 and
> am no longer able to type a | over vnc to the xen vms.  When I press \
> it works, but when I hold down shift and press \ which should generate a
> |, the vm sees the scan code for some key that the keymap thinks should
> sit between left shift and Z, but does not exist on US keyboards, and
> that scan code produces a > when combined with shift.  I'm betting it
> was this commit that broke it:
> 
> commit ab8f9d49d62c82a12409475547e4420a46da56ed
> Author: Daniel P. Berrange <berrange@redhat.com>
> Date:   Wed Jan 17 16:41:15 2018 +0000
> 
>     hw: convert ps2 device to keycodemapdb
> 
>     Replace the qcode_to_keycode_set1, qcode_to_keycode_set2,
>     and qcode_to_keycode_set3 tables with automatically
>     generated tables.
> 
> Any ideas?

Ubuntu 18.04 apparently has QEMU 2.11.0:

   https://packages.ubuntu.com/source/bionic/qemu

The commit you mention above is from the 2.12.0 release, so that can't
be the cause.  Ubuntu 16.04 was on QEMU 2.5.0, so that's a huge  range
of possible changes.

My suggestion would be to try with the very latest QEMU 3.0.0 to see
if that fixes the problem first.

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

Re: [Qemu-devel] Pipe key broken on US keyboards

[Daniel P. Berrangé]

On Fri, Aug 17, 2018 at 08:44:36AM -0400, Phillip Susi wrote:
> On 8/17/2018 4:56 AM, Daniel P. Berrangé wrote:
> > Oh one other thing, is whether your QEMU process has an explicit keymap
> > configured (this is the -k arg to QEMU), as when that it set, it
> > completely changes the way keyboard input is handled in VNC. That code
> > has also been massively refactored recently.
> 
> I'm not using that argument.  I just checked the man page and it says it
> defaults to en-us, which should be correct.

Actually for QEMU there is no default localized keymap. This is desirable
because it allows VNC to activate its raw scancode extension which is more
reliable than passing translated X11 key symbols.

I guess there's a chance that Xen might secretly pass a '-k' arg anyway,
but hopefully it doesn't...


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

Re: [Qemu-devel] Pipe key broken on US keyboards

[Phillip Susi]

[-- Attachment #1: Type: text/plain, Size: 483 bytes --]

On 8/17/2018 8:58 AM, Daniel P. Berrangé wrote:
> Actually for QEMU there is no default localized keymap. This is desirable
> because it allows VNC to activate its raw scancode extension which is more
> reliable than passing translated X11 key symbols.
> 
> I guess there's a chance that Xen might secretly pass a '-k' arg anyway,
> but hopefully it doesn't...

It also happens when I just run qemu.  How can I check to see if it is
using raw scancodes or keycodes?




[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 473 bytes --]

Re: [Qemu-devel] Pipe key broken on US keyboards

[Daniel P. Berrangé]

On Fri, Aug 17, 2018 at 09:10:54AM -0400, Phillip Susi wrote:
> On 8/17/2018 8:58 AM, Daniel P. Berrangé wrote:
> > Actually for QEMU there is no default localized keymap. This is desirable
> > because it allows VNC to activate its raw scancode extension which is more
> > reliable than passing translated X11 key symbols.
> > 
> > I guess there's a chance that Xen might secretly pass a '-k' arg anyway,
> > but hopefully it doesn't...
> 
> It also happens when I just run qemu.  How can I check to see if it is
> using raw scancodes or keycodes?

It depends on what the VNC client asks for too. With no '-k' arg, if the
VNC client asks for raw scancodes it'll get that, otherwise QEMU will
fallback to en-US.    GTK-VNC based clients (remote-viewer, virt-viewer,
vinagre, virt-manager, GNOME boxes) use the raw scancodes. Most other
clients do not.


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

Re: [Qemu-devel] Pipe key broken on US keyboards

[Phillip Susi]

[-- Attachment #1: Type: text/plain, Size: 599 bytes --]

On 8/17/2018 9:12 AM, Daniel P. Berrangé wrote:
> It depends on what the VNC client asks for too. With no '-k' arg, if the
> VNC client asks for raw scancodes it'll get that, otherwise QEMU will
> fallback to en-US.    GTK-VNC based clients (remote-viewer, virt-viewer,
> vinagre, virt-manager, GNOME boxes) use the raw scancodes. Most other
> clients do not.

I'm using "tightvnc" from my Windows computer at work and it says it is
using keyboard layout 00000409 ( whatever that means ), so it sounds
like it is sending a keycode and qemu is translating it into the wrong
scancode.



[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 473 bytes --]

Re: [Qemu-devel] Pipe key broken on US keyboards

[Phillip Susi]

[-- Attachment #1: Type: text/plain, Size: 762 bytes --]

I've been reading up here:
http://www.win.tue.nl/~aeb/linux/kbd/scancodes-1.html

And man, what a mess keyboards are!  Worse than floppy controllers.
According to that site, the scan code for \ should be 0x2b, so why does
xev say the keycode is 51?  Is keycode something else entirely from scan
codes and keysyms?  If so how can I see the scan code?

On 8/17/2018 9:12 AM, Daniel P. Berrangé wrote:
> It depends on what the VNC client asks for too. With no '-k' arg, if the
> VNC client asks for raw scancodes it'll get that, otherwise QEMU will
> fallback to en-US.    GTK-VNC based clients (remote-viewer, virt-viewer,
> vinagre, virt-manager, GNOME boxes) use the raw scancodes. Most other
> clients do not.
> 
> 
> Regards,
> Daniel
> 


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 473 bytes --]

Re: [Qemu-devel] Pipe key broken on US keyboards

[Daniel P. Berrangé]

On Fri, Aug 17, 2018 at 10:36:14AM -0400, Phillip Susi wrote:
> I've been reading up here:
> http://www.win.tue.nl/~aeb/linux/kbd/scancodes-1.html
> 
> And man, what a mess keyboards are!  Worse than floppy controllers.
> According to that site, the scan code for \ should be 0x2b, so why does
> xev say the keycode is 51?  Is keycode something else entirely from scan
> codes and keysyms?  If so how can I see the scan code?

0x2b is 43 in hex.

xev reports the Xorg scancode, which is the same as the XT/AT-set1
scancodes, with an offset of 8 added

IOW, 51 from xev does actually match 0x2b from XT scancode set

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

Re: [Qemu-devel] Pipe key broken on US keyboards

[Phillip Susi]

[-- Attachment #1: Type: text/plain, Size: 578 bytes --]

On 8/17/2018 10:44 AM, Daniel P. Berrangé wrote:
> 0x2b is 43 in hex.
> 
> xev reports the Xorg scancode, which is the same as the XT/AT-set1
> scancodes, with an offset of 8 added
> 
> IOW, 51 from xev does actually match 0x2b from XT scancode set

Oy vey!  Just for fun they decided to add 8 eh?  Which set does linux
configure the keyboard controller for?  I guess I need to find the code
that is translating the key code to the scan code in whatever set that
is, and it should be using a 0x56 that needs changed to 0x2b ( assuming
linux is using set 1? ).



[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 473 bytes --]

Re: [Qemu-devel] Pipe key broken on US keyboards

[Daniel P. Berrangé]

On Thu, Aug 16, 2018 at 01:11:05PM -0400, Phillip Susi wrote:
> Hello, I recently upgraded my Xen server from Ubuntu 16.04 to 18.04 and
> am no longer able to type a | over vnc to the xen vms.  When I press \
> it works, but when I hold down shift and press \ which should generate a
> |, the vm sees the scan code for some key that the keymap thinks should
> sit between left shift and Z, but does not exist on US keyboards, and
> that scan code produces a > when combined with shift.  I'm betting it
> was this commit that broke it:
> 
> commit ab8f9d49d62c82a12409475547e4420a46da56ed
> Author: Daniel P. Berrange <berrange@redhat.com>
> Date:   Wed Jan 17 16:41:15 2018 +0000
> 
>     hw: convert ps2 device to keycodemapdb
> 
>     Replace the qcode_to_keycode_set1, qcode_to_keycode_set2,
>     and qcode_to_keycode_set3 tables with automatically
>     generated tables.
> 
> Any ideas?
> 
> According to xev in the vm, they scan code for \ is 51, and when I hold
> down shift, it changes to scan code 94.

Reading again, this is a bit odd. On most keyboards, holding down shift
key generally would NOT change the scan code that is reported (there are a
few keys which are exceptions - sysrq/printscr). The scancode is associated
with the physical key location, and holding down shift doesn't change that.
The intepretation of the shift should (mostly) only take place when the
scancode is changed to a key symbol by the kernel/xorg.


Scancode 94 from xev, once the offset is removed, this corresponds
to scancdoe 0x56 in XT and key 86 in Linux key codes.

Scancode 51 from xev, once the offset is removed, this corresponds
to scancdoe 0x2b in XT and key 43 in Linux key codes.

On my US layout keyboard the '\' key will emit XT scancode 86 regardless
of whether the shift key is held or not

On my UK layout keyboard the '\' key will emit XT scancode 43 regardless
of whether the shift key is held or not


The QEMU guest I tested will correctly interpret this *if* I load the
correct matching keymap in the guest.

ie if using my US layout keyboard I must

  loadkeys /lib/kbd/keymaps/kegacy/i386/qwerty/us.map.gz

while for my UK layout keyboard I must use

  loadkeys /lib/kbd/keymaps/kegacy/i386/qwerty/uk.map.gz

NB, I'm using QEMU 2.12.0 which has the complete rewrite of the key
handling, while it looks like you have 2.11.0 from Ubuntu. 


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

Re: [Qemu-devel] Pipe key broken on US keyboards

[Daniel P. Berrangé]

On Fri, Aug 17, 2018 at 03:44:21PM +0100, Daniel P. Berrangé wrote:
> On Fri, Aug 17, 2018 at 10:36:14AM -0400, Phillip Susi wrote:
> > I've been reading up here:
> > http://www.win.tue.nl/~aeb/linux/kbd/scancodes-1.html
> > 
> > And man, what a mess keyboards are!  Worse than floppy controllers.
> > According to that site, the scan code for \ should be 0x2b, so why does
> > xev say the keycode is 51?  Is keycode something else entirely from scan
> > codes and keysyms?  If so how can I see the scan code?
> 
> 0x2b is 43 in hex.
> 
> xev reports the Xorg scancode, which is the same as the XT/AT-set1
> scancodes, with an offset of 8 added
> 
> IOW, 51 from xev does actually match 0x2b from XT scancode set

Opps, slight mistake there.  On *old* Xorg using the 'kbd' driver it
would correspond to XT/AT-set1 scancodes. On *new* Xorg using the 'evdev'
driver it would correspond to Linux keycodes.

Fortunately in this particular case the Linux keycode is the same as
the XT scancode so the conversion I illustrate was still correct :-)

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

Re: [Qemu-devel] Pipe key broken on US keyboards

[Phillip Susi]

[-- Attachment #1: Type: text/plain, Size: 858 bytes --]

On 8/17/2018 11:05 AM, Daniel P. Berrangé wrote:
> Reading again, this is a bit odd. On most keyboards, holding down shift
> key generally would NOT change the scan code that is reported (there are a

Right; a real keyboard won't change the scan code, but it seems that
European keyboards have this extra key that can also produce a |, so
when qemu gets the key code for |, it has to pick one scan code or the
other to translate the | into, and it picks the wrong one.

Looking at the code it looks like qemu has its own qcode set and
translates between that and all of these other sets.  I'm guessing
either input-keymap-linux-to-qcode.c or input-keymap-x11-to-qcode.c is
where the error is, but these do not exist so I guess they must be auto
generated somehow by the build process?

Actually, which one of those code sets is vnc using?


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 473 bytes --]

Re: [Qemu-devel] Pipe key broken on US keyboards

[Daniel P. Berrangé]

On Fri, Aug 17, 2018 at 11:16:29AM -0400, Phillip Susi wrote:
> On 8/17/2018 11:05 AM, Daniel P. Berrangé wrote:
> > Reading again, this is a bit odd. On most keyboards, holding down shift
> > key generally would NOT change the scan code that is reported (there are a
> 
> Right; a real keyboard won't change the scan code, but it seems that
> European keyboards have this extra key that can also produce a |, so
> when qemu gets the key code for |, it has to pick one scan code or the
> other to translate the | into, and it picks the wrong one.
> 
> Looking at the code it looks like qemu has its own qcode set and
> translates between that and all of these other sets.  I'm guessing
> either input-keymap-linux-to-qcode.c or input-keymap-x11-to-qcode.c is
> where the error is, but these do not exist so I guess they must be auto
> generated somehow by the build process?
> 
> Actually, which one of those code sets is vnc using?

Since you're using tightvnc on Windows, it won't be using the raw scancode
extension to RFB, so it'll be sending X keysyms across the wire eg 

  "|" has X11 keysym 0x7c  (XK_bar)
  "\" has X11 keysym 0x5c  (XK_backslash)

First thing is the converting keysym number to a name, which
uses name2keysym[] data table.  This gives 'bar' and 'backslash'
as names, respectively

The names are now looked up in the keymap (pc-bios/keymaps/en-us)
which says

  backslash 0x2b
  bar 0x2b shift

QEMU now has a Qcode that it can pass to the ps2 frontend
which converts to the AT set 1/2 scancode for injection to
the guest.

Any one of those many steps could be going wrong and its hard
to see which, without being able to reproduce it myself

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

Re: [Qemu-devel] Pipe key broken on US keyboards

[Gerd Hoffmann]

On Fri, Aug 17, 2018 at 11:16:29AM -0400, Phillip Susi wrote:
> On 8/17/2018 11:05 AM, Daniel P. Berrangé wrote:
> > Reading again, this is a bit odd. On most keyboards, holding down shift
> > key generally would NOT change the scan code that is reported (there are a
> 
> Right; a real keyboard won't change the scan code, but it seems that
> European keyboards have this extra key that can also produce a |, so
> when qemu gets the key code for |, it has to pick one scan code or the
> other to translate the | into, and it picks the wrong one.

There have been fixes for that one, specifically recent qemu will look
at modifier state in addition to the keysym when looking up the keycode,
because some keymaps can generate the same keysym with different key
combinations, and most of the time they have different modifier state.

In this specific case the us kbd key generates '|' with shift while the
105th key of i18n kbds generates '|' with altgr, so it should actually
improve things.

So, try upgrade qemu.

> Looking at the code it looks like qemu has its own qcode set and
> translates between that and all of these other sets.  I'm guessing
> either input-keymap-linux-to-qcode.c or input-keymap-x11-to-qcode.c is
> where the error is, but these do not exist so I guess they must be auto
> generated somehow by the build process?

No.  It's ui/keymaps.c.  Keymaps are in pc-bios/keymaps/, generated by
qemu-keymap.c.

HTH,
  Gerd

Re: [Qemu-devel] Pipe key broken on US keyboards

[Phillip Susi]

[-- Attachment #1: Type: text/plain, Size: 612 bytes --]

On 8/20/2018 4:43 AM, Gerd Hoffmann wrote:
> There have been fixes for that one, specifically recent qemu will look
> at modifier state in addition to the keysym when looking up the keycode,
> because some keymaps can generate the same keysym with different key
> combinations, and most of the time they have different modifier state.

Yea, I saw that code, so the new version probably works if I could
figure out how to get the package to build.  I'm not sure why Ubuntu is
on such an old version.  I just cloned the debain git repo to start
poking around and assumed that was what was in Ubuntu.



[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 473 bytes --]

Re: [Qemu-devel] Pipe key broken on US keyboards

[Christian Ehrhardt]

On Mon, Aug 20, 2018 at 4:32 PM Phillip Susi <psusi@ubuntu.com> wrote:

> On 8/20/2018 4:43 AM, Gerd Hoffmann wrote:
> > There have been fixes for that one, specifically recent qemu will look
> > at modifier state in addition to the keysym when looking up the keycode,
> > because some keymaps can generate the same keysym with different key
> > combinations, and most of the time they have different modifier state.
>
> Yea, I saw that code, so the new version probably works if I could
> figure out how to get the package to build.  I'm not sure why Ubuntu is
> on such an old version.  I just cloned the debain git repo to start
> poking around and assumed that was what was in Ubuntu.
>

What exactly would you need in Ubuntu Phillp?
Latest qemu would atm be on 2.12 with the git available here [1].
Unfortunately mostly nobody cares about the git branches so I forgot to
push this one - shame on me :-/, it is ready now thou.

I couldn't follow all of the thread, do you need something else than qemu
code to be updated, if so which package would that be?

[1]: https://salsa.debian.org/qemu-team/qemu/commits/ubuntu-cosmic-2.12

Re: [Qemu-devel] Pipe key broken on US keyboards

[Phillip Susi]

[-- Attachment #1: Type: text/plain, Size: 1224 bytes --]

On 8/20/2018 11:07 AM, Christian Ehrhardt wrote:
> What exactly would you need in Ubuntu Phillp?

It *looks* like this is fixed in 2.12, but Ubuntu has 2.11.

> Latest qemu would atm be on 2.12 with the git available here [1].
> Unfortunately mostly nobody cares about the git branches so I forgot to
> push this one - shame on me :-/, it is ready now thou.

What did you forget to push?  Because the debian git repo already seemd
to have 2.12 last week.

> I couldn't follow all of the thread, do you need something else than qemu
> code to be updated, if so which package would that be?

Nope; it's just qemu 2.11 seems to have had this bug.  It seems there
has been massive refactoring of the keyboard code since then so likely
this bug will forever remain in 18.04 unless someone wants to go through
the 2.11 code and figure out how to surgically fix it.  At this point I
think the path of least resistance for me is to get the newer version in
the debian git repo to build and install that.

What I can't figure out is how to get the pristine-tar for
dpkg-buildpackage.  The git repo doesn't contain the pristine-tar branch
that was required for pristine-tar to check out the original tar.



[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 473 bytes --]

Re: [Qemu-devel] Pipe key broken on US keyboards

[Christian Ehrhardt]

On Mon, Aug 20, 2018 at 9:51 PM Phillip Susi <psusi@ubuntu.com> wrote:

> On 8/20/2018 11:07 AM, Christian Ehrhardt wrote:
> > What exactly would you need in Ubuntu Phillp?
>
> It *looks* like this is fixed in 2.12, but Ubuntu has 2.11.
>
> > Latest qemu would atm be on 2.12 with the git available here [1].
> > Unfortunately mostly nobody cares about the git branches so I forgot to
> > push this one - shame on me :-/, it is ready now thou.
>
> What did you forget to push?  Because the debian git repo already seemd
> to have 2.12 last week.
>

I forgot to push the git branch for 2.12 when I uploaded the package itself
on 2018-07-20

Ubuntu cosmic (18.10) has qemu 2.12 as of ~4 weeks ago as well.
Once Cosmic is released there will be a 2.12 via the Ubuntu Cloud Archive
[1] available into Bionic as well.

[1]: https://wiki.ubuntu.com/OpenStack/CloudArchive


> > I couldn't follow all of the thread, do you need something else than qemu
> > code to be updated, if so which package would that be?
>
> Nope; it's just qemu 2.11 seems to have had this bug.  It seems there
> has been massive refactoring of the keyboard code since then so likely
> this bug will forever remain in 18.04 unless someone wants to go through
> the 2.11 code and figure out how to surgically fix it.  At this point I
> think the path of least resistance for me is to get the newer version in
> the debian git repo to build and install that.
>

Yeah unless one does volunteer to identify the single change or it becomes
a problem for more of the community it is unlikely to be changed in the
2.11 in Ubuntu Bionic.


> What I can't figure out is how to get the pristine-tar for
> dpkg-buildpackage.  The git repo doesn't contain the pristine-tar branch
> that was required for pristine-tar to check out the original tar.
>

I thought the salsa repo should have the pristine-tar branch which is valid
for Debian and Ubuntu.
But you are right it doesn't, any Ubuntu package in main will have a repo
per package following this scheme
  git://git.launchpad.net/~usd-import-team/ubuntu/+source/qemu
including pristine-tar branches for Debian as well as Ubuntu.

Worst case run a "pull-lp-source" and you'll get all you need (but without
git history)

-- 
Christian Ehrhardt
Software Engineer, Ubuntu Server
Canonical Ltd

Re: [Qemu-devel] Pipe key broken on US keyboards

[Phillip Susi]

[-- Attachment #1: Type: text/plain, Size: 1345 bytes --]

On 8/17/2018 11:51 AM, Daniel P. Berrangé wrote:
> Since you're using tightvnc on Windows, it won't be using the raw scancode
> extension to RFB, so it'll be sending X keysyms across the wire eg 
> 
>   "|" has X11 keysym 0x7c  (XK_bar)
>   "\" has X11 keysym 0x5c  (XK_backslash)
> 
> First thing is the converting keysym number to a name, which
> uses name2keysym[] data table.  This gives 'bar' and 'backslash'
> as names, respectively
> 
> The names are now looked up in the keymap (pc-bios/keymaps/en-us)
> which says
> 
>   backslash 0x2b
>   bar 0x2b shift

Thanks.  I checked out the 2.11 version that Ubuntu 18.04 shipped and
found the problem:

commit a7815faffb2bd594b92aa3542d7b799cc89c5414
Author: Gerd Hoffmann <kraxel@redhat.com>
Date:   Thu Oct 5 17:33:30 2017 +0200

    pc-bios/keymaps: keymaps update

    Update the keymaps with the ones generated by qemu-keymap

    Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
    Message-id: 20171005153330.19210-4-kraxel@redhat.com

Prior to this commit, this file said it was generated from XKB, and was
much smaller, not including the scan code for that other key.  This
commit added the 0x56 bar translation with altgr, and it wasn't until
after 2.12 those smarts were inserted to pick the scancode that matches
the current modifier keys.



[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 473 bytes --]