keymap unstable

Thank you for taking the time to report this bug and helping to make Ubuntu better. Please answer these questions:

* Is this reproducible?
* If so, what specific steps should we take to recreate this bug?

This will help us to find and resolve the problem.

yes, I think so.
but now I don't know how.
the keymap hasn't had this behaviour since the last 'apt update / upgrade' I did.
I hope it's solved by someone else, but if it doesn't I will describe better here.

P.S: even if I have one or two things about 'Onboard keyboard'. because it don't want my finger touch but only digital pen with the cursor close. Well,maybe this is not the topic.

Another time yesterday. Only some times it happens.
Maybe if the display has been reoriented with xrandr -o right, deactivate the keyboard because the laptop is being a tablet, and then xrandr -o normal, activate the keyboard, the keymap isn`t correctly reload.
But I'm not sure because I try to reproduce it now and not happens nothing of inconsistent.
Maybe only because i'm not writing lesson notes now (aha)

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

I have installed Trusty Tahr on my Dell PC without any other operating system. When the screen locks and I want to unlock the screen by entering my password , I have often a change of keyboard map with a reversion to the US keyboard (instead of the french one). I obtain exactly the same result when I want to relog.

this is NOT an Onboard bug

this problem is starting being very uncomfortable

every time I-m starting pc, the keymap is the US-s, altough in the unity panel service is marked the correct ones with this + and this / and this ] in the right place.

I think that is connect with an another bug (or feature), in fact the desktop ambient (unity) do not response well at the status change, maybe is the same cause.

please someone with the same problem___ ++} >>(where TF is question mark)??

Jimbo, have you tried removing all keymaps (aka input sources) and re-adding them? I heard this helped occasionally, at least before Trusty. In Trusty the settings panel can be reached with
unity-control-center region

I'm not sure about the later comments, but your initial description sounds like old bug
https://bugs.launchpad.net/ubuntu/+source/xorg-server/+bug/837456

The workaround back then was to run (for French keys)
setxkbmap fr
This would pin the keymap down for the current session at least. Does that still help?

thank's marmuta, I'm looking for an answer and I understand that
It is a X problem because if I go in another tty (where isn't X) the keymap is the right ones.
well when I returned back with the X ambient the keymap was charged well.

So definitely 'setxkbmap it' make work my keyboard but is it possible that in log on this is completely ignored??

And what is meaning the right corner of unity panel with the flag of current keylayout? (maybe only the linux keymap and not X keymap)

I will try in xinit or some, to put 'setxkbmap'

Thank's marmuta

You could probably set it in xorg.conf.d, but I wish there was a better solution. This problem keeps coming up, infrequently, but persistently over the years.

OK, let's see. The indicator in unity panel writes to gsettings.
gsettings monitor org.gnome.desktop.input-sources current

Unity-settings-daemon listens for this key's changes and in response sets the root window property _XKB_RULES_NAMES. As I understand it, that's basically what setxkbmap does too.
xprop -root | grep XKB

However, unity-settings-daemon seems to always add the us layout as a second group, something "setxkbmap it,us" would do.
setxkbmap -query | grep layout
layout: it,us

I don't know why that happens. There's probably a good reason for it, but I could imagine this is what exposes you to the old bug #837456.

Right, the good reason for appending the 'us' group is having shortcuts work with non-latin layouts.
https://bazaar.launchpad.net/~ubuntu-branches/ubuntu/utopic/unity-settings-daemon/utopic/view/head:/plugins/keyboard/gsd-keyboard-manager.c#L816
I guess bug #1218322 is what happens when that fails.

Unfortunately for us, that behavior is plain hard coded in gnome/unity-settings-daemon. I don't see a way to select the 'it' layout without getting the 'us' one tacked on, even though both are latin layouts. I'd still say it's difficult to maintain this is a bug in u-s-d. What we really need is a fix for the unexpected group switches, rather than stopping u-s-d/g-s-d from setting up multiple groups. That would have just been nice to have as another workaround. I'll duplicate this one to the X bug #837456 then, that's the best I currently have.

Jimbo, was your Trusty a fresh install or upgrade? What's the output of
$ locale

I'd like to try and see if I can somehow reproduce this on a fresh partition.