keyboard switching is broken in guest VM

[Gannet]

Usually I'm using three languages: English, Russian, Ukrainian. So, after Xubuntu was installed in my VM I went to keyboard settings and added Russian. After that I found that when I'm switching from first layout to second - it works, but when I'm pressing Alt+Shift again nothing happens. So it stays on second layout.

I added keyboard switching element to tray and this is the only way I can switch layouts normally - by mouse.

It seems it is Xubuntu specific bug because in my host system, Kubuntu, there is no such issue.

ProblemType: Bug
DistroRelease: Ubuntu 16.04
Package: xubuntu-desktop 2.206
ProcVersionSignature: Ubuntu 4.4.0-22.39-generic 4.4.8
Uname: Linux 4.4.0-22-generic x86_64
ApportVersion: 2.20.1-0ubuntu2
Architecture: amd64
CurrentDesktop: XFCE
Date: Sat May 14 00:55:33 2016
InstallationDate: Installed on 2016-04-27 (16 days ago)
InstallationMedia: Xubuntu 16.04 LTS "Xenial Xerus" - Release amd64 (20160420.1)
SourcePackage: xubuntu-meta
UpgradeStatus: No upgrade log present (probably fresh install)
---
ApportVersion: 2.20.1-0ubuntu2.5
Architecture: amd64
DistroRelease: Ubuntu 16.04
InstallationDate: Installed on 2016-09-16 (180 days ago)
InstallationMedia: Kubuntu 16.04.1 LTS "Xenial Xerus" - Release amd64 (20160719)
Package: xubuntu-meta
PackageArchitecture: amd64
ProcEnviron:
 LANGUAGE=
 TERM=xterm
 PATH=(custom, no user)
 LANG=uk_UA.UTF-8
 SHELL=/bin/bash
ProcVersionSignature: Ubuntu 4.8.0-42.45~16.04.1-generic 4.8.17
Tags: third-party-packages xenial
Uname: Linux 4.8.0-42-generic x86_64
UnreportableReason: This is not an official Ubuntu package. Please remove any third party package and try again.
UpgradeStatus: No upgrade log present (probably fresh install)
UserGroups:

_MarkForUpload: True

[Launchpad Janitor (janitor)]

Status changed to 'Confirmed' because the bug affects multiple users.

[Gannet (ken20001)]

Just an update. I found that this bug affected only in VM but not on real hardware. So, I don't really now what component caused it: virt-manager, libvirt-bin (?)

[Launchpad Janitor (janitor)]

Status changed to 'Confirmed' because the bug affects multiple users.

[RussianNeuroMancer (russianneuromancer)]

Spot same issue with Kubuntu 17.04 host and Kubuntu 17.04 guest: https://bugs.launchpad.net/ubuntu/+source/kubuntu-meta/+bug/1672614

[Gannet (ken20001)]

Note, please, I found, that bug is not distrospecific. So the source of issue is most likely in virtual environment.

[Christian Ehrhardt  (paelzer)]

Hi,
I'd assume it might have something to do with the mouse pointer catching. You often have all sorts of key combos to exit those, maybe one of those blocks it.

I have a Host Kubuntu as well and tried unity in guest first.
There the language switch is "meta+space" that worked well for me.
I switched the hotkey to "alt+shiftL" as you said but that works well still.

Yet I have the setup in a way to allow no mouse capturing, so no need for qemu to catch some of my keys (using the "new" default being usbtablet as input device).

I shut the guest down and switched to pointer device (was defaulting to relative movement on Generic PS2 Mouse, now trying EvTouch USB Tablet, but I could still switch just fine with that device.

I have found a few times that it stopped working, what got me working again is to go to the key shortcut setup and set "alt+shiftL" again. I actually did that to see if the key event still gets there, but it did and after that it continued to work (I no longer lost the ability to switch langauages).

While we got an update about 17.04 I was focusing on 16.04 for the initial report.

That was odd already, I installed kubuntu-desktop in the guest to check that (closer to your case). But there as well I can switch just fine.
Config looks like this (see attached png)

So far in my case I tried English/German since that would be my combo. I wondered it it might be a coincidence that both reporters have Russian settings, so I tried that next.
German/English/Russion as well as "English/Russian/Ukranian" work well for me.
Maybe a silly question, but I found that KDE has shortcuts for toggling layouts (top right) and a per language shortcut - I only set the global toggling one.

Along all that I installed the tool "key-mon" to make it always visible to me if my keys are recognized by the guest system. Because IMHO there is the split - if the keys get seen by the guest then libvirt/qemu is out of the equation here and we have to search in the desktop suites. But if the keys are not arriving we have to look where/why.

Sorry - I'm not really a graphical/desktop guy, and this issue still puzzles me - I noted some questions for you.

@Gannet:
- While I don't understand yet what is happening exactly, could you try to go to key bindings again and re-bind "alt+shiftL" to it?
- Please report if that fixes the issue permanently for you as it did for me, or if not at least if the "alt+shiftL" does come to the guest when you try to refresh the binding.
- Does your KDE key layout config look like the image I attached

@RussianNeuroMancer:
- just to confirm in your case this "started" with the qemu/libvirt/virt-manager of 17.04 but worked before?

@Both:
- could you install key-mon as well and tell me if in the faulty case you still see Alt+Shift reported as being pressed?
- Could you post a screenshot of your language setting key binds (like the one I attached, but matching your desktop/config).

[Christian Ehrhardt  (paelzer)]

Since I can't reproduce incomplete until further Detail provided.

[Gannet (ken20001)]

Hello, Christian. Please, watch this video I've recorded for you. As you will see re-bindind "alt+shiftL" combination doesn't help. The same issue I'm discovering in Xubuntu. So, as I said this is not distrospecific.

[Gannet (ken20001)]

https://youtu.be/rP_u8RsUYmo

[Gannet (ken20001)]

And here is my test video with test with key-mon: https://youtu.be/nBgdBbynnr0

[Christian Ehrhardt  (paelzer)]

Hi,
thanks that video really helped to see your case.
First video 1:26 top right the shortcut is set to "None" I believe. Translate gives me "Никто" which does not fully match, but it seems unset at least. This is the setting that I set to Alt+ShiftL to work at all for me - maybe worth a try.

The second video with keymon is even better, I can see:
0:14 - Keys get to the Guest, Guest & Host switch language
>0.18 - Keys still get to the Guest but only the Host switches.

Thanks for the confirmation of this, but despite being non Desktop-specific after the keycodes get to the guest then the virtualization layer is kind of out of the equation. The Qemu around can't do more than deliver the keys, and it seems they are there.

Unfortunately IMHO that means going back to file against whatever desktop components apply.
I'd keep qemu but set it to opinion (as it is a discussion about, but not likely in qemu) and stay subscribed personally, but since the keys get there as I said I don't see much qemu could do.

For me in Desktop environments it is always a bit hard to spot where to file the bug against.
I was following [1] and [2] for the KDE case, one could do the same for the Xubunutu case.
The config for the Keyboard is via /usr/bin/systemsettings5 which is package systemsettings.
I'll set that now.
You could auto-add the right versions and such via `apport-collect 1581687`, maybe the KDE/Desktop folks would want that. Actually you should run that in Guest AND Host just to have all available.

Things I'd consider worth to try for you until there is a response from Desktop people:
- Set an explicit hotkey at "Main shortcuts" in the guest - if possible try a different one than on the Host (see my png)
- I have no reason why I assume that, but gut feeling tells me you could also try disabling the language selector in the Host to see if then the one in the guest suddenly works.

Let me know if these trial and errors turn out to be a workaround.

[1]: https://wiki.kubuntu.org/Kubuntu/Bugs/Reporting
[2]: https://wiki.kubuntu.org/Bugs/FindRightPackage

[Gannet (ken20001)]

apport information

[Gannet (ken20001)]

apport information

[Gannet (ken20001)]

Those is from guest.

[Gannet (ken20001)]

But in host it is not working for some reason:

$ LC_ALL=C sudo apport-collect 1581687
Package kubuntu-meta not installed and no hook available, ignoring
Package xubuntu-meta not installed and no hook available, ignoring
Traceback (most recent call last):
  File "/usr/share/apport/apport-kde", line 532, in <module>
    sys.exit(UserInterface.run_argv())
  File "/usr/lib/python2.7/dist-packages/apport/ui.py", line 664, in run_argv
    return self.run_update_report()
  File "/usr/lib/python2.7/dist-packages/apport/ui.py", line 580, in run_update_report
    response = self.ui_present_report_details(allowed_to_report)
  File "/usr/share/apport/apport-kde", line 368, in ui_present_report_details
    desktop_info)
  File "/usr/share/apport/apport-kde", line 185, in __init__
    self.ui.ui_update_view(self)
  File "/usr/share/apport/apport-kde", line 359, in ui_update_view
    QTreeWidgetItem(keyitem, [str(line)])
UnicodeEncodeError: 'ascii' codec can't encode characters in position 73-77: ordinal not in range(128)

[Theo Linkspfeifer (lastonestanding)]

Any news on this issue? The Xfce settings daemon can be run in debug mode to obtain a detailed log output:

XFSETTINGSD_DEBUG=1 xfsettingsd --replace --no-daemon

[Launchpad Janitor (janitor)]

Status changed to 'Confirmed' because the bug affects multiple users.

[Gannet (ken20001)]

Now I am not experiencing this issue on my system.
Host: Kubuntu 18.04
Guest: Xubuntu 16.04