Spice and AltGr

Latest response



I'm having trouble with AltGR in the spice protocol and linux desktops.


On a danish keyboard, characters such as "@", "|" and "\" are all invoked using AltGr, but this is ignored on linux desktops.


I've tried on Rhel6-client, Fedora16, Ubuntu, Linuxmint and all have this problem.


Windows7 desktops are fine, though.


Any advice would be appreciated.


Regards, Brian



Hi Brian,


Let me get this straight, you are using a Linux desktop with spice, but what about the client - it is also Linux, or Windows?

What versions of Spice client (on the client machine) and xorg-x11-qxl (in the guest) are you using?







The situation is, Im using Windows XP (32bit) to connect with spice to a virtual linux desktop. Connecting envoked through rhevmanager admin.


Spice client, is rhevm-spice-client-x86-msi-3.0-21.el6.noarch (I guess - found on rhev manager). The executable is version

On remote rhel6-desktop, its xorg-x11-drv-qxl-0.0.14-10.el6.x86_64


Thanks, Brian

Hi Brian,


Sorry about the delay, but I'm back with more questions:

1. Is the k/b layout set up correctly in the VM?

2. We have tested AltGr with a German keyboard, some time ago, would be interesting to see if the german variant of altgr works in your case - would you be able to try to switch layouts and see what happens?






I tested with the german layout and the uk-english. I found that with all three, about half the keys works with altgr and the other half doesn't. I have no problems with danish characters, and uppercase chars.


When I manually set 3rd key to right alt in keyboard layout, everything seems to work on my Redhat client6. But this doesn't work on all systems, eg not in LinuxMint. In mint I have to assign something else the 3rd key to make it work.


And as I mentioned, on windows client everythings works out of the box.


Regards, Brian






Just making sure I understand correctly:


Client OS: Linux (layout set); Guest OS: Linux (layout set) --> OK


Client OS: Linux (layout not set); Guest OS: Linux (layout not set) --> not OK


Client OS: Windows ; Guest OS: Windows --> OK


Client OS: Windows; Guest OS: Linux (layout set) --> OK

Is this correct? Or are there additional combinations that work or don't work?

No, Im probably being unclear


Only windows clients, so:


Client OS: Windows ; Rhev Guest OS: Windows --> OK

Client OS: Windows; Rhev Guest OS: Linux (layout set) --> OK (On rhel-desktop, at least)

Client OS: Windows; Rhev Guest OS: Linux (layout not set) --> not OK


/Regards, Brian

Ah, ok, now I get it. So what you're asking is really for Spice to set the layout according to the client's, right? 

Well, I don't normally have to tinker with these things. Putty, vnc etc just work out of the box, I kind of expect the same behavior from spice

They are slightly different - putty uses the hosts' layout and VNC has a layout setting in the server, which the client respects. Spice simply passes the kbd of the client to the guest, and if the layouts are not the same, this might be an issue.


Anyhow, I was afraid this might be a bug, but it really is a feature, for Spice to detect the VM's layout and use it (like VNC does), or for Spice to change the VM's layout to the clients' layout (not sure if this will be useful).


If you have a support entitlement, you could file a feature request through a support case - this is the best way to do that, and such a request will get escalated to engineering right away.

If not, you can also post here - https://access.redhat.com/discussion/rhev-wishlist-feature-requests - we scrub the topic for useful feature requests and ideas daily.




Sorry, but I still dont get it. The keybord layout of the host and client are the same. Some of the keys like £ and $ (altgr+3 & altgr+4) works as expected. If spice just parses the keyboard through, why doesn't @ (altgr+2) work as well?



this issue is also happening with a LATAM layout ,  is there a bug report already open for this ??

Hi Andres,


There is no bug report open, we could not reproduce the issue in house so far. Still working on it

Brian, Andres, I do have some good news. The BZ has been opened, and a patch is being tested. 


The BZ is internal for now, so watch out for updates, and if possible, I'll also post something here when a fix is released

Hi Dan,


Any new info regarding this issue?


Thanks, Brian

As I understand, the fix is ready, and it has passed quality tests, should be released with the next major release. If you need it sooner, you have to opena support case and request a hotfix