Debian Bug report logs - #878087
qemu-system-x86: xmodmap + qemu, keyboard settings is ignored

Reply or subscribe to this bug.

Toggle useless messages

Message #5 received at submit@bugs.debian.org (full text, mbox, reply):

From: Antonio <antdev66@gmail.com>

To: submit@bugs.debian.org

Subject: qemu-system-x86: xmodmap + qemu, keyboard settings is ignored

Date: Mon, 9 Oct 2017 19:34:44 +0200

[Message part 1 (text/plain, inline)]

Package: qemu-system-x86
Version: 1:2.10.0+dfsg-2

Dear Maintainer,

if you modify some keys with xmodmap (eg: xmodmap -e "keycode
91=Delete" -e "keycode 90=Insert" -e "keycode 79=Home" -e "keycode
87=End" -e "keycode 81=Prior" -e "keycode 89=Next")
and then run qemu-system-x86_64, keyboard setting (-k it) is ignored
and en-us keyboard is set as default.

With previous version 1:2.10.0+dfsg-1 there was no problem.

Thanks

-- System Information:
Debian Release: buster/sid
  APT prefers unstable
  APT policy: (550, 'unstable'), (520, 'testing'), (500,
'stable-updates'), (500, 'stable'), (100, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 4.13.5-custom (SMP w/8 CPU cores; PREEMPT)
Locale: LANG=it_IT.UTF-8, LC_CTYPE=it_IT.UTF-8 (charmap=UTF-8),
LANGUAGE=it (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages qemu depends on:
pn  qemu-system  <none>
pn  qemu-user    <none>
pn  qemu-utils   <none>

qemu recommends no packages.

Versions of packages qemu suggests:
pn  qemu-user-static  <none>

-- no debconf information

[Message part 2 (text/html, inline)]

Message #10 received at 878087@bugs.debian.org (full text, mbox, reply):

From: Michael Tokarev <mjt@tls.msk.ru>

To: Antonio <antdev66@gmail.com>, 878087@bugs.debian.org

Subject: Re: Bug#878087: qemu-system-x86: xmodmap + qemu, keyboard settings is ignored

Date: Mon, 9 Oct 2017 21:02:43 +0300

09.10.2017 20:34, Antonio wrote:
> Package: qemu-system-x86
> Version: 1:2.10.0+dfsg-2
> 
> Dear Maintainer,
> 
> if you modify some keys with xmodmap (eg: xmodmap -e "keycode 91=Delete" -e "keycode 90=Insert" -e "keycode 79=Home" -e "keycode 87=End" -e "keycode 81=Prior" -e "keycode 89=Next")
> and then run qemu-system-x86_64, keyboard setting (-k it) is ignored and en-us keyboard is set as default.
> 
> With previous version 1:2.10.0+dfsg-1 there was no problem.

It looks like this is a wontfix bug. The "problem" seems to be that
more recent ui frontends (sdl2 which is enabled in -2 compared to
obsolete sdl1 used before, and gtk to be enabled later), keyboard
handling has been reworked, and qemu now always uses raw keycodes,
not preprocessed by modmap and other tools, with guest being able
to see all keyboard keys.  You have to use xmodmap INSIDE the guest
to achieve what you want.

Thanks,

/mjt

Message #15 received at 878087@bugs.debian.org (full text, mbox, reply):

From: Michael Tokarev <mjt@tls.msk.ru>

To: Michael Gold <michael@bitplane.org>

Cc: 878087@bugs.debian.org

Subject: Re: Bug#878087: qemu-system-x86: xmodmap + qemu, keyboard settings is ignored

Date: Sun, 29 Oct 2017 18:59:56 +0300

29.10.2017 18:54, Michael Gold wrote:
[]
> CPU type/count, etc.  Is any workaround for this known?  And does the -k
> option have any effect now?  My preference is to have it work as before;
> but if it will have no effect, it should raise an error or be removed.

For all modern UI types (introduced in upstream qemu in recent years),
-k option is ignored because the way qemu now handles key mapping is
entirely different, it is like bypass mechanism, and the upstream says
it is THE ONLY sane way to handle this, so no workaround is intended.
For multiple years they've been telling us users to stop using -k.

I for one never used it at all so I've no idea, but each time I tried
to reproduce various bugreports with context of keyboard handling,
there has always been a solution - removing -k helped.

Yes I agree, usage of -k with UI types which does not support it should
give a warning (definitely not an error but that's just my opinion).

/mjt

Message #20 received at 878087@bugs.debian.org (full text, mbox, reply):

From: Michael Gold <michael@bitplane.org>

To: Michael Tokarev <mjt@tls.msk.ru>

Cc: 878087@bugs.debian.org

Subject: Re: Bug#878087: qemu-system-x86: xmodmap + qemu, keyboard settings is ignored

Date: Sun, 29 Oct 2017 11:54:12 -0400

[Message part 1 (text/plain, inline)]

On Mon, Oct 09, 2017 at 21:02:43 +0300, Michael Tokarev wrote:
> 09.10.2017 20:34, Antonio wrote:
> > Package: qemu-system-x86
> > Version: 1:2.10.0+dfsg-2
> > 
> > Dear Maintainer,
> > 
> > if you modify some keys with xmodmap (eg: xmodmap -e "keycode 91=Delete" -e "keycode 90=Insert" -e "keycode 79=Home" -e "keycode 87=End" -e "keycode 81=Prior" -e "keycode 89=Next")
> > and then run qemu-system-x86_64, keyboard setting (-k it) is ignored and en-us keyboard is set as default.
> > 
> > With previous version 1:2.10.0+dfsg-1 there was no problem.
> 
> It looks like this is a wontfix bug. The "problem" seems to be that
> more recent ui frontends (sdl2 which is enabled in -2 compared to
> obsolete sdl1 used before, and gtk to be enabled later), keyboard
> handling has been reworked, and qemu now always uses raw keycodes,
> not preprocessed by modmap and other tools, with guest being able
> to see all keyboard keys.  You have to use xmodmap INSIDE the guest
> to achieve what you want.

I've recently been affected by this as well, and don't find the proposed
solution practical.  It assumes the guest is also using X11 or otherwise
allows the desired remapping, but in many guest OSes the ability doesn't
exist or is restricted (only allowing for "popular" layouts/tweaks).  If
the ability is there, but there's no persistent or network-mounted disk,
the mapping will need to be redone at every boot, which may be difficult
with the "wrong" layout.  If I share an image with someone else, they'll
need to find some way to reset it to a more familiar layout.

The ability to "hide" host settings such that people can use a common OS
image is a very useful feature of qemu.  I'd like to see it work for the
keyboard layout, as it does for other things: network hardware/settings,
CPU type/count, etc.  Is any workaround for this known?  And does the -k
option have any effect now?  My preference is to have it work as before;
but if it will have no effect, it should raise an error or be removed.

-- Michael

[signature.asc (application/pgp-signature, inline)]

Send a report that this bug log contains spam.