Keyboard layout set to us at VM startup

[Olivier Médoc]

Hello,

The keyboard layouts are not propagated to the appvm (I user azerty
keyboard, but when I start a VM, the keyboard is set to qwertz). This
problem only appears for fedora-18 appvms but not for the fedora-18
template.

1/ It is not possible to define default keyboard layout once the user
selected one from the qubes manager. I attached a patch to the qubes-gui
repo in order to allow selection of a 'none' layout (Qubes default layout).

2/ I finally found the real culprit:
/etc/xdg/autostart/gnome-settings-daemon.desktop, which ends with
OnlyShowIn=GNOME;AppVM;

As a consequence, when running an appvm, gnome-settings starts (after
/etc/X11/xinit/xinitrc.d/qubes-keyboard.sh). If not specific keyboard
settings are found (which is the case if the user want to use default
qubes keymap), gnome-settings apparently set the keyboard layout to 'us'.

You can just remove AppVM from gnome-settings-daemon.desktop to fix this.


Is gnome-settings-daemon really necessary in our case ? What is the
correct way to fix this problem ?


Thanks in advance for your help,
Olivier

[Marek Marczykowski]

On 07.03.2013 13:32, Olivier Médoc wrote:
> Hello,
>
> The keyboard layouts are not propagated to the appvm (I user azerty keyboard,
> but when I start a VM, the keyboard is set to qwertz). This problem only
> appears for fedora-18 appvms but not for the fedora-18 template.
>
> 1/ It is not possible to define default keyboard layout once the user selected
> one from the qubes manager. I attached a patch to the qubes-gui repo in order
> to allow selection of a 'none' layout (Qubes default layout).

setxkbmap -v -print should also work instead of plain "setxkbmap -v". IMO
getting current setting from GNOME specific application isn't the right option
(especially if gnome-settings-daemon isn't running).

> 2/ I finally found the real culprit:
> /etc/xdg/autostart/gnome-settings-daemon.desktop, which ends with
> OnlyShowIn=GNOME;AppVM;
>
> As a consequence, when running an appvm, gnome-settings starts (after
> /etc/X11/xinit/xinitrc.d/qubes-keyboard.sh). If not specific keyboard settings
> are found (which is the case if the user want to use default qubes keymap),
> gnome-settings apparently set the keyboard layout to 'us'.
>
> You can just remove AppVM from gnome-settings-daemon.desktop to fix this.
>
>
> Is gnome-settings-daemon really necessary in our case ? What is the correct
> way to fix this problem ?

It isn't but it will be started by some application anyway (e.g.
gnome-terminal). I'd like to disable setting keyboard layout by gsd, but I
don't know how. KDE equivalent have "use system default" option, but gnome
hasn't... Do you have some idea? Perhaps qubes_keyboard.sh script should set
it according to layout received from dom0?

--
Best Regards / Pozdrawiam,
Marek Marczykowski
Invisible Things Lab

[Olivier Médoc]

On 03/08/13 14:53, Marek Marczykowski wrote:
> On 07.03.2013 13:32, Olivier Médoc wrote:
>> Hello,
>>
>> The keyboard layouts are not propagated to the appvm (I user azerty keyboard,
>> but when I start a VM, the keyboard is set to qwertz). This problem only
>> appears for fedora-18 appvms but not for the fedora-18 template.
>>
>> 1/ It is not possible to define default keyboard layout once the user selected
>> one from the qubes manager. I attached a patch to the qubes-gui repo in order
>> to allow selection of a 'none' layout (Qubes default layout).
> setxkbmap -v -print should also work instead of plain "setxkbmap -v". IMO
> getting current setting from GNOME specific application isn't the right option
> (especially if gnome-settings-daemon isn't running).

Ok, I have 4 values:
- The value coming from xenstore
- The value coming from xkbmap
- The value coming from xkbcomp (X11 display :0)
- The value coming from gsettings

If the keyboard from xkbmap is us (which is the default):
1/if xkbcomp and xenstore layout are matching and are different
than us, it means that the user didn't selected any specific keymap
2/if xkbcomp and xenstore layout are matching and are us, the user
probably doesn't care about the keymap.

So if xkbcomp and xenstore layout are matching, and xkbmap layout is us,
it means that the user use the default keymap ?

I can modify the patch following this rule...

>
>> 2/ I finally found the real culprit:
>> /etc/xdg/autostart/gnome-settings-daemon.desktop, which ends with
>> OnlyShowIn=GNOME;AppVM;
>>
>> As a consequence, when running an appvm, gnome-settings starts (after
>> /etc/X11/xinit/xinitrc.d/qubes-keyboard.sh). If not specific keyboard settings
>> are found (which is the case if the user want to use default qubes keymap),
>> gnome-settings apparently set the keyboard layout to 'us'.
>>
>> You can just remove AppVM from gnome-settings-daemon.desktop to fix this.
>>
>>
>> Is gnome-settings-daemon really necessary in our case ? What is the correct
>> way to fix this problem ?
> It isn't but it will be started by some application anyway (e.g.
> gnome-terminal). I'd like to disable setting keyboard layout by gsd, but I
> don't know how. KDE equivalent have "use system default" option, but gnome
> hasn't... Do you have some idea? Perhaps qubes_keyboard.sh script should set
> it according to layout received from dom0?

Apparently, gnome-terminal doesn't really care about the gsettings
daemon and doesn't start it. Also if gnome-settings isn't running, I can
still use the gsettings command and that won't start
gnome-settings-daemon (or gsd). So I don't really know if this deamon is
required or if it just initialize things for the gnome desktop (not the
apps).

qubes_keyboard.sh is started before xdg applications, which make this
not so easy to solve. Also qubes_keyboard actually set the layout
received from dom0 using xkbcomp.

My point is still that gsettings-daemon should be disabled as it doesn't
seems necessary (at least I never had problems running gnome
applications without gsd running). But maybe I missed something.

[Marek Marczykowski]

On 13.03.2013 11:04, Olivier Médoc wrote:
> On 03/08/13 14:53, Marek Marczykowski wrote:
>> On 07.03.2013 13:32, Olivier Médoc wrote:
>>> Hello,
>>>
>>> The keyboard layouts are not propagated to the appvm (I user azerty keyboard,
>>> but when I start a VM, the keyboard is set to qwertz). This problem only
>>> appears for fedora-18 appvms but not for the fedora-18 template.
>>>
>>> 1/ It is not possible to define default keyboard layout once the user selected
>>> one from the qubes manager. I attached a patch to the qubes-gui repo in order
>>> to allow selection of a 'none' layout (Qubes default layout).
>> setxkbmap -v -print should also work instead of plain "setxkbmap -v". IMO
>> getting current setting from GNOME specific application isn't the right option
>> (especially if gnome-settings-daemon isn't running).
> Ok, I have 4 values:
> - The value coming from xenstore
> - The value coming from xkbmap
> - The value coming from xkbcomp (X11 display :0)
> - The value coming from gsettings

And the fifth:
- The value coming from ~/.config/qubes-keyboard-layout.rc (see below)

> If the keyboard from xkbmap is us (which is the default):
> 1/if xkbcomp and xenstore layout are matching and are different than us,
> it means that the user didn't selected any specific keymap
> 2/if xkbcomp and xenstore layout are matching and are us, the user
> probably doesn't care about the keymap.
>
> So if xkbcomp and xenstore layout are matching, and xkbmap layout is us, it
> means that the user use the default keymap ?

I think the better idea is to always save custom layout in
qubes-keyboard-layout.rc. If the file doesn't exists - it means "default
layout". Also setting layout to default should result in removing the file.


There is one more problem: keyboard layout can specify multiple groups
(multiple layout with possibility to switch between them). Example:
xkb_keymap {
xkb_keycodes { include "evdev+aliases(qwerty)" };
xkb_types { include "complete" };
xkb_compat { include "complete" };
xkb_symbols { include
"pc+pl+us(colemak):2+inet(evdev)+terminate(ctrl_alt_bksp)" };
xkb_geometry { include "pc(pc105)" };
};

Same can be obtained from xkbcomp.
I don't know how to get (or set) currently used group from script (i.e. not
from keyboard layout tray icon). So currently setting more than one layout
causes problems. It's okay for now (just one more point on Known Issues
list...), but it will be nice to solve it some day.

> I can modify the patch following this rule...
>>
>>> 2/ I finally found the real culprit:
>>> /etc/xdg/autostart/gnome-settings-daemon.desktop, which ends with
>>> OnlyShowIn=GNOME;AppVM;
>>>
>>> As a consequence, when running an appvm, gnome-settings starts (after
>>> /etc/X11/xinit/xinitrc.d/qubes-keyboard.sh). If not specific keyboard settings
>>> are found (which is the case if the user want to use default qubes keymap),
>>> gnome-settings apparently set the keyboard layout to 'us'.
>>>
>>> You can just remove AppVM from gnome-settings-daemon.desktop to fix this.
>>>
>>>
>>> Is gnome-settings-daemon really necessary in our case ? What is the correct
>>> way to fix this problem ?
>> It isn't but it will be started by some application anyway (e.g.
>> gnome-terminal). I'd like to disable setting keyboard layout by gsd, but I
>> don't know how. KDE equivalent have "use system default" option, but gnome
>> hasn't... Do you have some idea? Perhaps qubes_keyboard.sh script should set
>> it according to layout received from dom0?
> Apparently, gnome-terminal doesn't really care about the gsettings daemon and
> doesn't start it. Also if gnome-settings isn't running, I can still use the
> gsettings command and that won't start gnome-settings-daemon (or gsd). So I
> don't really know if this deamon is required or if it just initialize things
> for the gnome desktop (not the apps).
>
> qubes_keyboard.sh is started before xdg applications, which make this not so
> easy to solve. Also qubes_keyboard actually set the layout received from dom0
> using xkbcomp.

If gnome-settings-daemon will not be running we can ignore gsettings.
qubes-change-keyboard-layout currently uses gsettings as primary source and
config file as fallback. Without gsettings it can use config file as primary
config (perhaps still saving layout additionally in gsettings - to not break
keyboard layout if anyone start gsd manually). This should be easy to handle
from qubes_keyboard (which already uses config file, but as fallback to
gsettings).

> My point is still that gsettings-daemon should be disabled as it doesn't seems
> necessary (at least I never had problems running gnome applications without
> gsd running). But maybe I missed something.

Ok, can try. So you can change OnlyShowIn line in
/etc/xdg/autostart/gnome-settings-daemon.desktop in template (remove AppVM
from there). I will do the same on my system. If nothing will break, then will
make it default.

First thing I see: settings from gnome-control-center aren't applied anymore
(not surprised). But it should be a problem, because I don't there any useful
things besides keyboard layout.

[Olivier Médoc]

OK, I will change the patch to match this behavior.

Apparently, the window style is slighly modified when gsettings is
running. You can check by starting a window and then starting gsettings
daemon manually.

Good, news. I found a way to disable gsettings keyboard loading:
gsettings set org.gnome.settings-daemon.plugins.keyboard active false

In fact any gsetting plugin can be disabled like that, so you can
disable all things that may be inconsistent with qubes. Now the question
is, where should this setting be forced (because it's a user setting, it
should be done during each vm startup ? In some keyboard script started
before xdg ?

[Olivier Médoc]

On 03/17/13 10:29, Olivier M�doc wrote:
> On 03/13/13 13:55, Marek Marczykowski wrote:

>> On 13.03.2013 11:04, Olivier M�doc wrote:
>>> On 03/08/13 14:53, Marek Marczykowski wrote:

Here is my new patch proposal for the keyboard layout selection.

[Marek Marczykowski]

On 17.03.2013 11:12, Olivier Médoc wrote:

> On 03/17/13 10:29, Olivier Médoc wrote:
>> On 03/13/13 13:55, Marek Marczykowski wrote:

>>> On 13.03.2013 11:04, Olivier Médoc wrote:
>>>> Ok, I have 4 values:
>>>> - The value coming from xenstore
>>>> - The value coming from xkbmap
>>>> - The value coming from xkbcomp (X11 display :0)
>>>> - The value coming from gsettings
>>> And the fifth:
>>> - The value coming from ~/.config/qubes-keyboard-layout.rc (see below)
>>>
>>>> If the keyboard from xkbmap is us (which is the default):
>>>> 1/if xkbcomp and xenstore layout are matching and are different than us,
>>>> it means that the user didn't selected any specific keymap
>>>> 2/if xkbcomp and xenstore layout are matching and are us, the user
>>>> probably doesn't care about the keymap.
>>>>
>>>> So if xkbcomp and xenstore layout are matching, and xkbmap layout is us, it
>>>> means that the user use the default keymap ?
>>> I think the better idea is to always save custom layout in
>>> qubes-keyboard-layout.rc. If the file doesn't exists - it means "default
>>> layout". Also setting layout to default should result in removing the file.
>> OK, I will change the patch to match this behavior.
>>
> Here is my new patch proposal for the keyboard layout selection.

Applied. And also applied some fixes on it. Please use 4-spaces indent in
python code...

>>> There is one more problem: keyboard layout can specify multiple groups
>>> (multiple layout with possibility to switch between them). Example:
>>> xkb_keymap {
>>> xkb_keycodes { include "evdev+aliases(qwerty)" };
>>> xkb_types { include "complete" };
>>> xkb_compat { include "complete" };
>>> xkb_symbols { include
>>> "pc+pl+us(colemak):2+inet(evdev)+terminate(ctrl_alt_bksp)" };
>>> xkb_geometry { include "pc(pc105)" };
>>> };
>>>
>>> Same can be obtained from xkbcomp.
>>> I don't know how to get (or set) currently used group from script (i.e. not
>>> from keyboard layout tray icon). So currently setting more than one layout
>>> causes problems. It's okay for now (just one more point on Known Issues
>>> list...), but it will be nice to solve it some day.

Looking at xev output I've found current group in "state" field. It is also
confirmed from protocol documentation[3], section 2.1:
"As described in section 2.0, the current keyboard group is reported to
XKB-aware clients in bits 13-14 of the state field of many core protocol event"
This field is already passed to VM in msg_keypress event [1], but only basic
modifiers are used by gui-agent [2]. So if VM gui-agent would take care of
switching group, it will fully support multi-group layout setting. Some
protocol documentation here[3], but haven't digged through it. If anyone
interested in it, I'll be very happy to accept some patch.

[1] http://wiki.qubes-os.org/trac/wiki/GUIdocs#Dom0-AppVMmessages
[2]
http://git.qubes-os.org/gitweb/?p=marmarek/gui-agent-linux.git;a=blob;f=gui-agent/vmside.c;h=3e8ec7157785212fe4154671c81b317856530c73;hb=HEAD#l1005
[3] http://www.xfree86.org/current/XKBproto.pdf

(...)

>>>> My point is still that gsettings-daemon should be disabled as it doesn't
>>>> seems
>>>> necessary (at least I never had problems running gnome applications without
>>>> gsd running). But maybe I missed something.
>>> Ok, can try. So you can change OnlyShowIn line in
>>> /etc/xdg/autostart/gnome-settings-daemon.desktop in template (remove AppVM
>>> from there). I will do the same on my system. If nothing will break, then will
>>> make it default.
>>>
>>> First thing I see: settings from gnome-control-center aren't applied anymore
>>> (not surprised). But it should be a problem, because I don't there any useful
>>> things besides keyboard layout.
>>
>> Apparently, the window style is slighly modified when gsettings is running.
>> You can check by starting a window and then starting gsettings daemon manually.
>>
>> Good, news. I found a way to disable gsettings keyboard loading:
>> gsettings set org.gnome.settings-daemon.plugins.keyboard active false
>>
>> In fact any gsetting plugin can be disabled like that, so you can disable
>> all things that may be inconsistent with qubes. Now the question is, where
>> should this setting be forced (because it's a user setting, it should be
>> done during each vm startup ? In some keyboard script started before xdg ?

Now I remember, I've already done the same for another gnome-settings-daemon
plugin.
Official documentation:
https://developer.gnome.org/gio/2.33/GSettings.html#idp54291968
Qubes implementation:
http://git.qubes-os.org/gitweb/?p=marmarek/gui-agent-linux.git;a=commit;h=6af831e93678b4662bda39c08a4b8fe693876b47

[liska.v...@gmail.com]

Hi,

its more than three years later now, but it seems this problem is still unsolved.

I am unable to switch between keyboard layouts in personal VM. 

I am not programmer, I am just regular person who would love to be able to send email in different language using Qubes.

Could you, please, explain in layman terms how can I activate different layout so it really works?

Thank you very much for your exceptional work on this OS.

Solving this detail would make big difference in usability of Qubes for me and others who are not computer geeks.

With best regards

Martin

Dne čtvrtek 7. března 2013 13:32:12 UTC+1 Olivier Médoc napsal(a):

[Andrew David Wong]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

On 2016-08-25 03:49, liska.v...@gmail.com wrote:
> Hi, its more than three years later now, but it seems this problem
> is still unsolved. I am unable to switch between keyboard layouts
> in personal VM. I am not programmer, I am just regular person who
> would love to be able to send email in different language using
> Qubes. Could you, please, explain in layman terms how can I
> activate different layout so it really works? Thank you very much
> for your exceptional work on this OS. Solving this detail would
> make big difference in usability of Qubes for me and others who are
> not computer geeks. With best regards Martin
>

Please take a look at the tracking issue for this problem, since the
comments contain information on workarounds:

https://github.com/QubesOS/qubes-issues/issues/1396

Also, please note that we are actively looking for help with solving
this issue (see questions in comments).

P.S. - Please try to avoid top-posting.

> Dne čtvrtek 7. března 2013 13:32:12 UTC+1 Olivier Médoc napsal(a):
>>
>> Hello,
>>
>> The keyboard layouts are not propagated to the appvm (I user
>> azerty keyboard, but when I start a VM, the keyboard is set to
>> qwertz). This problem only appears for fedora-18 appvms but not
>> for the fedora-18 template.
>>
>> 1/ It is not possible to define default keyboard layout once the
>> user selected one from the qubes manager. I attached a patch to
>> the qubes-gui repo in order to allow selection of a 'none' layout
>> (Qubes default layout).
>>
>> 2/ I finally found the real culprit:
>> /etc/xdg/autostart/gnome-settings-daemon.desktop, which ends with
>> OnlyShowIn=GNOME;AppVM;
>>
>> As a consequence, when running an appvm, gnome-settings starts
>> (after /etc/X11/xinit/xinitrc.d/qubes-keyboard.sh). If not
>> specific keyboard settings are found (which is the case if the
>> user want to use default qubes keymap), gnome-settings apparently
>> set the keyboard layout to 'us'.
>>
>> You can just remove AppVM from gnome-settings-daemon.desktop to
>> fix this.
>>
>>
>> Is gnome-settings-daemon really necessary in our case ? What is
>> the correct way to fix this problem ?
>>
>>
>> Thanks in advance for your help, Olivier
>>
>

- --
Andrew David Wong (Axon)
Community Manager, Qubes OS
https://www.qubes-os.org
-----BEGIN PGP SIGNATURE-----

iQIcBAEBCgAGBQJXw8R/AAoJENtN07w5UDAwU+0QAJBO/OXZDRoEm8yYEYqKju4u
6nEBkg8uUtZjYW/2eX3cH5f2kRAyyIcOlWK6LTmLfFzXkw+avPVgQzNVhb8b5cU3
PeGiN24eLKmhSt+Ut/Ody1N1ZdLvpegpLhkzlCh60pkAhVhPRtBstmmzZhtXHObQ
Zvd4cqOaPKgRWWqUqGmxkF7ob7y8ntSUb5ZW66EceaGOWBdnJPyA8ZnzklLOqjDC
dhIfsV+jpXdD/USbjKOhPDFW7SysW/cBV7TnVAPs9Vkb7e85hT6EfsrlM64FdFSq
j2HL6av1YfH9GibyWOHK9geGJMMolH+9c+3ZOpdq7syYPjQOpxW/EfaX/GVRkSsn
EITJ9cffq3in9Irpxse2JohW8gmRZ3trx7oVQOnE+4zFVVXrp0beyTPy9YXEc3Rs
KszKx7/tZjmCcV25mVyu0srx4bFksef9EpURBDNU26GTu5offXktF3dqqNUro4BQ
H45yOYkVRF8Gefu3oxzv7fnu3Xe6Wv9raIUh7Yw6CG8PbOrtBSa1UoBpAQiQd7um
E8xJUWtaycoMNWySVsr2fvRHiBeYazDMJGoDhCVWFC0ju0tW/MKAsLdDfSB3gG51
I8mqp7sFSwzjqGbdoLcduFnidWF0DKkv3N85MdYfNgrls19OuSO2yoKRNSByqgpG
tMIawH9tcjJvpSPJPXL5
=G25x
-----END PGP SIGNATURE-----

[Ivan]

Hi,

On 08/25/2016 01:49 PM, liska.v...@gmail.com wrote:
> Hi,
> its more than three years later now, but it seems this problem is still
> unsolved.
> I am unable to switch between keyboard layouts in personal VM.
> I am not programmer, I am just regular person who would love to be able to
> send email in different language using Qubes.
> Could you, please, explain in layman terms how can I activate different
> layout so it really works?
> Thank you very much for your exceptional work on this OS.
> Solving this detail would make big difference in usability of Qubes for me
> and others who are not computer geeks.
> With best regards
> Martin

the following workaround has been working well for me for many years, in
stock fedora and now in Qubes: in a terminal in dom0, type the following
(obviously replace the bg(phonetic) version with whatever layout you're
using)

setxkbmap -layout "us,bg(phonetic)" -option "grp:shifts_toggle"

then you'll be able to press both shift keys to switch the layout in
specific VMs.

you can automate this by putting this line in a script called by the
window manager during startup.

caveats:
- no layout notification; not a problem for me, if you don't remember
which layout you've enabled, in the worst case you'll type a letter, see
that you're in the wrong layout, press both shift keys, and continue. It
takes 1 second.
- my biggest gripe: when the screensaver kicks in (xscreensaver here),
there's no way to know in which layout you're typing your password.
Typing your English password with - say - Cyrillic letters will
obviously fail, so you'll have to press both shift keys and try again.

hope this helps

ivan

PS: copy/pasted in issue #1396 (I wasn't even aware of that issue).

[Andrew David Wong]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

Thanks for sharing this, Ivan!

- --
Andrew David Wong (Axon)
Community Manager, Qubes OS
https://www.qubes-os.org
-----BEGIN PGP SIGNATURE-----

iQIcBAEBCgAGBQJXw9kUAAoJENtN07w5UDAwnEsP/3a+5jU1H+p3q7eX0lhG9rd7
tS9M4HbG9Gsj4JFmAJLMS23mhkLZCuJbG/N6JyuYyBKPDhVSlIdXbj2aIEZCLweA
NXKkyaR/1Wpt94MSFvzU1zOum4iKLrot3JT98rk7Lwj0k2Ye/VhIpLcUkv4PGGVQ
XU0CMMAQ2xJNIl0trHiXDSjM9VNcLLHbePZyaxveZiZa8AYiD91lXeP8Vi/Zro5T
86z02gFBKHgNIZvVDAddCpG7l38Lgup7G9uZOaCDNHQ1eKGRvTaM91ZOc9bXrDRq
Kn1kykEZSG+5WFQFEs5c14qm9BEmDJXERe8OtHYwknhBk3Btufxdsh3vA8AnZW5+
IxYbUbMMvhwqEqF85JRSgcItOfcLTIossRirtiZVQ1BQOcVS9Y1MhpoFDjkqCzKy
42FIvgTV+RPPxrUpwZQesLMilwCepYwkcylLL2SF/OC2mg0z8N5CEkvu2zphcbjr
jshz66yroHomhXNVz+AaCMqEVqNRyMtGwC0eu5/79Etnj9H7WbGnK9aEwF4RzfDu
dnp5xam/8r/BurJYACUK2mBOXwsOWQQ9h1SeqU03XCnVAC/7V2wA/jcxE9bNg+Qo
T8TKExRCYYQJeWN4FZM3DEdcEearf0eFNscJypda9DnztGHOHnIhMPH8pt7uE8O+
KprHx7KjfYsXRaPmaL0z
=nGRj
-----END PGP SIGNATURE-----