A GNOME login without keypress dosn't set GNOME keyboard settings

[Rapolas K.]

(This report used to cover two separate but similar looking bugs. We split them now, and here we describe one of the two bugs. The other bug, Bug #251443, has to do with some shortcuts to switch between layouts not working. An example is the Alt+AltGr shortcut).

If you enable autologin (it is in the settings, System/Administration/Login window/Security/Enable Automatic Login), then any settings about your keyboard layout including the shortcut to switch between layouts do not work on your next reboot.

In other words, the system ignores any keyboard layout settings that have been configured in GNOME.

This issue has been reported upstream (Freedesktop Project), and the link is shown above.

A good description of the root of the problem is at this post by Peter Hutterer,
http://lists.freedesktop.org/archives/xorg/2008-July/036947.html

"setting the keyboard without a device flag changes the VCK. On the first keypress of a device however this setting is overwritten by the keyboard that is actually being used. If you hit a key before gnome sets the keyboard layout, the phys. keyboard's settings are already copied into the VCK and thus gnome can overwrite them again. consecutive keypresses don't overwrite it again, since the phys. keyboard doesn't change.

"The correct solution here is to let gnome set the keyboard settings on each physical device they apply to."

A workaround is to run "setxkbmap" (command line utility), which reapplies the layout settings in GNOME.

Another workaround is to make a small change in the Keyboard layout settings, something that implicitly reapplies the settings from GNOME. For example, you can change the order of the layouts, then change them back.

[Rapolas K. (casselas)]

Sorry, I didn't mentioned my system, so its hardy heron alpha 5 up to date, computer -> dell inspiron e1505 laptop

[pnr (rusyaev-gmail)]

I can confirm the same bug, as reported by cassel.

The bug is also observed on my Dell Inspiron 6000 with Hardy-i386 updated to date. I use two keyboard layouts: US English and Russian, with a Ctrl+Shift shortcut to switch between the layouts.

After every reboot, I can use US English layout only. Ctrl+Shift shortcut does not switch the layouts, and the keyboard indicator does not change after applying the shortcut. Manual change of the layouts by clicking on the keyboard indicator does not work either: the layout name does change from English to Russian, however the actual input is still English characters.

Only removal and then addition of the Russian layout in the Keyboard Preferences resolves the issue for the current session, until the next reboot.

Please let me know if I can provide any additional info to troubleshoot the issue.

[pnr (rusyaev-gmail)]

The issue has been resolved in my case after manual correction of /etc/X11/xorg.conf as shown below:

ORIGINAL:
Section "InputDevice"
 Identifier "Generic Keyboard"
 Driver "kbd"
 Option "CoreKeyboard"
 Option "XkbRules" "xorg"
 Option "XkbModel" "pc105"
 Option "XkbLayout" "us"
EndSection

CORRECTED:
Section "InputDevice"
        Identifier "Generic Keyboard"
        Driver "kbd"
        Option "CoreKeyboard"
        Option "XkbRules" "xorg"
        Option "XkbModel" "pc105"
        Option "XkbLayout" "us,ru"
        Option "XkbVariant" ",winkeys"
        Option "XkbOptions" "grp:ctrl_shift_toggle,grp_led:scroll"
EndSection

[Rapolas K. (casselas)]

pnr, I know this solution, to manually edit config file, but I'm reporting this bug (at least I think it is a bug) to make ubuntu and gnome easier to use by noobs.

[pnr (rusyaev-gmail)]

cassel, I agree with you that it is a bug and look forward to hearing from the developers.

[Fabián Rodríguez (magicfab)]

Assigning importance to high, it seems many similar bugs to this (keyboard layout problems in Hardy) are popping out. If anyone can search & mark duplicates it would help a lot.

[sibidiba (sibidiba)]

I can confirm this on current Hardy.

Both alt or both ctrl keys as layout switcher does not work. Both shift keys, ctrl+alt or a single key (while pressed) does.

This is a regression, as it worked for me in Feisty and Gutsy.

Apropriate section of xorg.conf:

Section "InputDevice"
        Identifier "Generic Keyboard"
        Driver "kbd"
        Option "XkbRules" "xorg"
        Option "XkbModel" "pc105"
        Option "XkbLayout" "hu"
        Option "XkbVariant" "102_qwertz_dot_nodead"
        Option "XkbOptions" "lv3:ralt_switch"
EndSection

How could I supply more information on this?

[Oren_B (oren.barnea)]

I have a very similar problem, I guess it's the same problem, but I think I better report it anyway.
I upgraded from Gutsy to Hardy the day the Hardy beta was released. When I was still on Gutsy I changed the keyboard layout switching key combination to alt-shift. After upgrading to Hardy the key combination doesn't work, and when clicking the keyboard layout indicator on the panel the indication changes but the layout doesn't. I have to go to the preferences and re-assign the key combination to alt-shift, and then everything works well.

[ynamestnikov (ynamestnikov)]

I have simillar problem in Hardy Beta.
After upgrade I can't switch languages in GDM. It was really big problem, because my password include english letters, and my default language is russian.
I had to change password to login.

[Ori Avtalion (salty-horse)]

I reported the both-alt shortcut switching problem in this bug: https://bugs.launchpad.net/xkeyboard-config/+bug/205314
It also links to the upstream bug.

I confirm Oren's problem that after reboot changing the layout by clicking the panel doesn't work.
I think description of the bug should drop the word "shortcut".

[Larry (creatorlarry)]

I have a similar problem in Hardy. My changes of the delay and the speed of repeat keys will only work in the current session and will lose when restart X server. I think the problem lies in the Keyboard Preferences tool. Maybe it does not have enough authority to change the X setting file or the access permission of a particular X setting file for the keyboard is not right.

[Larry (creatorlarry)]

It seems that my first speculation is wrong.
I found that the setting file for repeat keys (/home/username/.gconf/desktop/gnome/peripherals/keyboard/%gconf.xml) was changed when I changed the corresponding values using gnome-keyboard-properties. Further I can also change these setting files by gconf-editor. That is to say, the changes are saved but the problem is that those settings are never loaded automatically when a session starts and they are only automatically loaded when you edit the corresponding settings either by gnome-keyboard-properties or gconf-editor. I am not familiar with gconf stuff. I tried gconftool-2 but cannot figure out a way to load these settings automatically.
Maybe someone can help.
By the way, for locale, the setting file for each user is in /home/username/.gconf/desktop/gnome/peripherals/keyboard/kbd/%gconf.xml

[David Vonka (vonkad)]

Confirm a similar problem. Keyboard layout changes "work" by clicking, in the sense that USA changes to CZE and back. Unfortunately, this has no impact on anything else, I still can not type Czech letters. Then I have to go to keyboard preferences and change something, for example the keyboard type from "Dell" to "Dell USB". Then (1) the keyboard shortcut starts working (2) When the panel says "CZE", I can indeed type Czech letters.

[Najmudin (hussain-hammady-gmail)]

I'm having the same problem exactly.

[pnr (rusyaev-gmail)]

It appears that the same bug is reported at the following links:
https://bugs.launchpad.net/ubuntu/+source/xorg/+bug/206008
https://bugs.launchpad.net/ubuntu/+bug/207457

[Franco Sirovich (franco-sirovich)]

The keywboard shortcuts for launching mail, browser and logout do not work. I have Hardy, kept well upgraded, on a SONY VAIO VGN-SZ3XP/C.

[Larry (creatorlarry)]

I solved my problem temporarily by create a file named "keyboardsettings.sh":

#!/bin/bash
gconftool-2 --type int --set /desktop/gnome/peripherals/keyboard/delay 184
gconftool-2 --type int --set /desktop/gnome/peripherals/keyboard/rate 150

and add it to the startup programs.
Locale settings are just similar. You can first check them using "gconf-editor". They are in
/desktop/gnome/peripherals/keyboard/kbd/
layouts = [us]
model = [precision_m] (I am using a dell laptop)

You can change the shell script accordingly. This bug remains not fixed in today's update.

[Franco Sirovich (franco-sirovich)]

Dear Larry, thank you for the suggestions. I have tried it and in fact
it works as it did the setting of the typing speed under Gutsy: It is
(and was) not a great solution, in that it decreases to a very little
level the "jumping" of the cursor, provided that the rate is set very
high. You solution is better than the previous because the applet had a
limit of 300 for the rate, and instead with your script I can set it to
500 and it seems better!

I have a related question: I have tried to set the two keys using
gconf-editor, but it does not seem to work; and I have noticed that the
two keys (rate and delay) are classified as "having no schema": What
does it mean?

Thank you in advance,

Franco Sirovich

Larry wrote:
> I solved my problem temporarily by create a file named
> "keyboardsettings.sh":
>
> #!/bin/bash
> gconftool-2 --type int --set /desktop/gnome/peripherals/keyboard/delay 184
> gconftool-2 --type int --set /desktop/gnome/peripherals/keyboard/rate 150
>
> and add it to the startup programs.
> Locale settings are just similar. You can first check them using "gconf-editor". They are in
> /desktop/gnome/peripherals/keyboard/kbd/
> layouts = [us]
> model = [precision_m] (I am using a dell laptop)
>
> You can change the shell script accordingly. This bug remains not fixed
> in today's update.
>
>

[Larry (creatorlarry)]

A good news: this bug has already been fixed in today's update.

Franco Sirovich, a schema is just a bundle of metainformation describing a configuration setting, while normal keys only have simple values such as integers, strings, or lists of those.You can find out more about what is schema in gconf in http://www.gnome.org/projects/gconf/

The problem in fact is not with/without a schema but these gconf settings were never automatically loaded when you started your gnome. After today's update, they will now.

PS: Sorry I forgot to mention that I used really fast keyboard settings. Hopefully it didn't cause a lot of trouble to you. I used to play tetris a lot, and with these settings I could move a block to one side immediately with only one keystroke. So somehow I adapted to these settings, and even use them in typing. It trained me type a lot faster:)

[Oren_B (oren.barnea)]

Today's update might have fixed the problem Larry described, but the problem Rapolas K., I and other people have, about the layout switching, is still happening on my machine after the updates.

[Joe_Bishop (denis-cheremisov-gmail)]

I also have the same issue with layout switching.

[Joe_Bishop (denis-cheremisov-gmail)]

Hey! Do you want to make the most buggy LTS?

[Nir Yeffet (nir-launchpad-net-8ff8)]

Confirmed on Dell OptiPlex 170L; however changing the key from "Keyboard Preferences" to, for example, both shifts, works well.

[Sergei Genchev (sgenchev)]

 I can confirm that the problem still exists in up-to-date Hardy It is a little different to me - *usually* after starting gnome session both keyboard and indicator switching work. Then they stop - and I could not tell when or how. After it stops working, the problem is exactly as the original bug submitter described...

[pnr (rusyaev-gmail)]

I still have to remove and add the second layout after every reboot to make the layout switching to work, as described in this thread on 2008-02-29. I hope that the bug affecting many users will be fixed before the upcoming release.

[Pedro Melero Gonzalez (petterware)]

I also confirm. I still have to add spanish keyboard and change
everytime I reboot. Also the numbers pad doesn't work.

2008/4/16, pnr <email address hidden>:
> I still have to remove and add the second layout after every reboot to
> make the layout switching to work, as described in this thread on
> 2008-02-29. I hope that the bug affecting many users will be fixed
> before the upcoming release.
>
>
> --
> [hardy] keyboard layout switching shortcut doesn't work after reboot
> https://bugs.launchpad.net/bugs/196277
> You received this bug notification because you are a direct subscriber
> of a duplicate bug.
>

--
Pedro Melero González

[Oren_B (oren.barnea)]

That's strange, Pedro: I think I had the numpad bug you're talking about (it was because the status of numlock was "forgotten" with every boot) but since 2-3 weeks ago it works well on my computer.

[mabovo (mabovo)]

I have to on every reboot "reassign/confirm" in System>prefs>keyboard>Disposition>Keyboard Model selecting the same keyboard model as prior defined so the keyboard remember my preferences. Looks like xserver-xorg-input-kbd complains with gnome keyboard configuration.
I filled a bug about this on https://bugs.launchpad.net/ubuntu/+source/linux/+bug/218263

[Arthur (moz-liebesgedichte)]

I'm not sure that #206008 is a duplicate of this bug. This one is about layout switching while #206008 is about forgetting the only configured layout and falling back to US layout. This just happened to me upgrading from 7.10 to 8.04 RC1. Really a showstopper bug.

[Bryce Harrington (bryce)]

Please attach your /var/log/Xorg.0.log

[Oren_B (oren.barnea)]

I'm attaching my /var/log/Xorg.0.log . I can see only one keyboard layout in the log, "us", but I also use Hebrew keyboard layout.

[Arthur (moz-liebesgedichte)]

Mine also only shows
(**) Option "XkbLayout" "us"
(**) Keyboard0: XkbLayout: "us"
I don't think there's anything wrong with the X server itself but with how Ubuntu is setting it up. My xorg.conf is devoid of any layout settings.

[Ori Avtalion (salty-horse)]

This bug probably stems from <https://bugs.freedesktop.org/show_bug.cgi?id=4927> which is the cause of several other bugs reported in Launchpad. (e.g. <https://bugs.launchpad.net/xkeyboard-config/+bug/205314>).

If that is the case, I think they should be made dupes of each other.

[Oren_B (oren.barnea)]

Ori, that's really strange -- the bug you linked to was first reported in October 2005 but keyboard layout switching worked well in Dapper, Edgy, Feisty and Gutsy (or didn't it?).

[SqUe (sque)]

Plz someone confirm this bug...

Steps to reproduce it are:
* Visit System->Preferences->Keyboard-Layouts
* Press Add and add a new layout.
* Close preferences.
* Open Text Editor or whatever you want and write something with Double-Alts it switch layout and writes with the other layout
OK till now.
* Reboot.
* Open a text editor and try to switch layout... Boom! It doesn't work!

Temporary Workaround. Open Layouts again and remove/add the second layout to start working again.

The steps are so simple, please someone mark it as "CONFIRMED"!!!!!

[SqUe (sque)]

hmm I thought I couldn't do it... Ok I marked it as confirmed.
Someone must find a solution too. :P

[mkrishnan (x-soulmirror-x)]

Can anyone please provide feedback on whether the following issue is the same bug or a different bug?

On my Eee, Ubuntu Desktop, Hardy, latest updates:

- keyboard model = generic 104-key (same happens with 105-key)
- layout = US (I had an international layout too, but even with US as the only layout left, this happens)
- behavior = On boot, the keyboard works fine. At some point, after using just Firefox 3b5, Pidgin 2.4.1, the system preferences, and the terminal, the "w" key of all keys suddenly begins to behave like a dead key. Shift-W produces a character, and all keyboard shortcuts using w continue to work as well, but the only way to produce a lower-case w is to use AltGr-w. The behavior disappears on reboot and then recurs at some later time. Switching keyboard layouts from the system preference window does not impact the behavior, oddly, although the layout change does "take."

Same bug or different bug? Thank you!

[Peter S (peter-sevemark)]

I can confirm this bug under Hardy and with Swedish keyboard layout. It has also been filed here: https://bugs.launchpad.net/ubuntu/+source/xkeyboard-config/+bug/213265 and here https://bugs.launchpad.net/ubuntu/+bug/219835

[Nir Misgav (nirmisgav)]

I have the same thing also.
It appears that this bug does not occur to people who installed a clean install from Hardy RC.
It only appears for those who upgraded from earlier revisions.

[Masoris (masoris)]

Nirmisgav /
I did reinstall Ubuntu 8.04 official release version today, but I still have keyboard layout problem.

[puntium (puntium)]

I think might be related, I'm seeing a problem where the 'Use capslock as another control key' doesn't work after I upgraded to Hardy. Turning the option on and off through the preferences applet has no effect. Using a Microsoft Natural Elite, USB. Worked fine through Gutsy and Feisty before that.

[puntium (puntium)]

Argh, now I changed something (not sure what), and the capslock->control mapping works, but the it still turns the capslock indicator on and off on the keyboard

[Yomamen (yomamen)]

I confirm this bug, on Ubuntu hardy fresh install.

When i add a secondary keyboard layout in gnome all is right until i reboot the xserver/gdm .

On two computers, one with french layout as default and the other with deutsch layout as default.

On two computers, the first layout is ok but the secondary is false.

The secondary layout write the alt-gr layout of default layout instead of the other layout.

For example if the default layout is french "azerty" when i switch to secondary layout i obtain "æâ€êþÿ"

[Mirza (mirza-seznam)]

I can confirm this bug and suggest raising it to critical since it renders ordinary generic PCs unusable for other then US keyboards.

[MickeA59 (mikael-andersson-home)]

I can confirm this to in the 8.04 release

[Ivan Kuznetsov (ivan-y-kuznetsov)]

I can confirm on 8.04 Russian (upgraded from 7.10 Russian) - have to reapply layout switch Alt-Shift after every reboot.
Another computer with same upgrade (7.10 to 8.04) English works fine. Layouts in both cases are Finnish and Russian.

On a computer where layout switching doesn't workj xorg.conf is missing Option "CoreKeyboard" in Section "InputDevice".

[Yomamen (yomamen)]

For me, this bug appears only when the autologin in gdm is active.

I have noticed this error message when i launch gnome-keyboard-properties and i try to choose a layout to add :

(gnome-keyboard-properties:26477): GnomeKbdIndicator-CRITICAL **: XkbGetKeyboard failed to get keyboard from the server!

[Liam McDermott (liam-intermedia-online)]

Confirmed for me also, just wanted to add that it's possible to change the keyboard layout in /etc/X11/xorg.conf from 'us' to your chosen layout. The change will then stick across restarts.

Think the problem might be that xorg.conf isn't updated by the gnome keyboard configuration tool.

[Bryce Harrington (bryce)]

There are enough confirmations of this bug, please don't comment here unless you have information that will help in solving the issue.

[Bryce Harrington (bryce)]

Closing the xorg component; the xkeyboard-config component is sufficient.

[Bryce Harrington (bryce)]

xserver-xorg-input-kbd not xkeyboard-config

[Simon Kågedal (simon-helgo)]

The bug manifests itself rather differently for me, so I'll just describe that.

1. In System->Preferences->Keyboard->Layouts, add a new layout so that there are two, for example first USA than SWE.
2. In System->Preferences->Keyboard->Layouts->Layout Options->Layout switching, check both "Both Alt keys..." and "Both shift keys..."
3. Now, switching with double alt works from "SWE" to "USA", but not from "USA" to "SWE". Double shift works both ways.
4. Go back to System->Preferences->Keyboard->Layouts and switch places between USA and SWE, so that SWE is first.
5. Now, switching with double alt works from "USA" to "SWE", but not from "SWE" to "USA"!

Some additional points:
- Rebooting does not change anything - double alt still only works one-way.
- Double ctrl seems to not work at all! (with "both alt keys...", "both shift keys...", "both ctrl keys..." all checked in "layout switching")
- Mouse clicking on USA/SWE works correctly all the time.

Don't know if /var/log/Xorg.0.log is useful, but I'm attaching that

[Taygeto (taygeto)]

I just did a clean install of the final hardy release and the problem is solved (at least on my pc it is).
So whatever changes were made, did the trick.

[Frantisek Fuka (fuxoft)]

I updated my 7.10 three days ago (i.e. from the final release) and this bug appeared. Can you please englighten me what to delete / reinstall to get rid of it? I wouldn't want to completely reinstall just to fix keyboard switching bug....

Just to recapitulate: After changing something in Keyboard Setup, everything works OK, but after Reboot, "Alt+Shift" does absolutely nothing, while clicking on keyboard indicator changes between "Cze" and "USA" but real keymap is still USA regardless...

[Frantisek Fuka (fuxoft)]

Also, when I disable "Automatic Login" in gdm, everything works OK. Any ideas?

[Oren_B (oren.barnea)]

Frantisek Fuka, here is a translation of instructions from an Israeli forum on how to fix this issue. It worked well on my machine, switching between English and Hebrew with Alt-Shift. Auto-login on. I can't be sure it will work with Czech, but I think it's worth trying:
1. Go to System --> Administration --> Language Support and make sure that "support for complex characters" is UNchecked (I also added Hebrew support there, I have no idea why it wasn't there already, I thought I added it after I installed Gutsy. Although the original instructions didn't mention it, I thought it couldn't hurt)
2. Edit your xorg.conf: the keyboard section should look like this:

Section "InputDevice"
   Identifier "Generic Keyboard"
   Driver "kbd"
   Option "CoreKeyboard"
   Option "XkbRules" "xorg"
   Option "XkbModel" "pc105"
   Option "XkbLayout" "us,il"
   Option "XKbOptions" "grp:alt_shift_toggle"
EndSection

The two changes from what I had originally are:
- under "XkbLayout", I replaced "us" with "us,il"
- added the line
Option "XKbOptions" "grp:alt_shift_toggle"

Next time I logged out and in again it worked well. Rebooted to make sure, worked again.
Good luck!

[Iulian D. (iulianu-gmail)]

The layout switching bug seems definitely related to Automatic login. Prompted by Comment 55 above, I enabled Automatic login (System -> Administration -> Login Window, tab Security). After reboot, layout switching fails to work exactly as described in this bug. Disable automatic login, log off and back on, and layout switching starts to work. Tested on a fresh install of hardy.

[Mirza (mirza-seznam)]

I tested all advices so far, nothing helped. It works only until next reboot (I do have auto-login). I am using CZ and US layouts.

[Jan Vlnas (jnv)]

I can confirm the same symptoms on Hardy with USA and Czech layout, using both shift keys for switching.
I use autologin in GDM, but problem stays even with timed login set in GDM.
Support for complex characters in Language support in administration is unchecked.
Editing xorg.conf can probably help, but I prefer some end-user solution.
Are there any functional workarounds or fix?

[guy_elg (guy-guyel)]

work around :

run this script

#!/bin/bash
gconftool-2 -s /desktop/gnome/peripherals/keyboard/kbd/options -t list --list-type=string "[]"
gconftool-2 -s /desktop/gnome/peripherals/keyboard/kbd/options -t list --list-type=string "`echo -e "[grp\tgrp:alt_shift_toggle]"`"

you can add it to session-setting to run automatically

[Roderick B. Greening (roderick-greening)]

For those who have this problem, can they try creating a brand new user account and testing it there. It is possible that those that have migrated from earlier releases via dist-upgrades may have some files in their home dir conflicting. Testing under a new account will help verify that.

Secondly, if you still have this problem under a new account, and have gone the emigration path, try making a backup of your xorg.conf and trying a new default xorg.conf.

Just some additional test cases for those working on this bug.

[maor (maors)]

according to the link upstream this bug wont be fixed any time soon (wont be ready for 7.4) i suggest we distribute the script using automatic update .

[Jan Vlnas (jnv)]

@Roderick Greening:
Creating new account, setting the keyboard and autologin won't help. I get the same symptoms.
Reverting to the default xorg.conf will create the same keyboard input section like in my old xorg.conf, so I think, it won't have any effect. It is very unlikely that this is caused by eg. mouse configuration. (But anything is possible; anyone who wants to test this?)

guy_elg's script is possible solution, but please notice that it will change your keyboard settings to Alt+Shift switching and remove all your extra configuration (like compose key etc.) You have to change it accordingly to your settings or we can make some universal solution when we dump the settings first.

[Jan Vlnas (jnv)]

This script should work like the previously mentioned workaround, but keeps your keyboard settings:
#!/bin/bash
gconftool-2 -s /desktop/gnome/peripherals/keyboard/kbd/options -t list --list-type=string "`gconftool-2 -g /desktop/gnome/peripherals/keyboard/kbd/options`"

The problem is, where to put it to be autostarted. I've tried the regular Session settings in GNOME and .xprofile, but script has no effect then. I guess it can be executed before the gconfd's start. Maybe putting it to `sleep` for a few seconds would help. Any ideas?

[Ori Avtalion (salty-horse)]

Here's another possible workaround. It works for me.

Add the following line in ~/.bash_profile :
setxkbmap

[Yomamen (yomamen)]

New account and new default Xorg config haven't any effect.

The command "setxkbmap" works fine

[Mýreček (mka-iol)]

I have the same problem but I have temporal (delayed) login active.
If I perform login manually, layout switching works OK. If I wait for automatic login, layout switching doesn't work.

[Jan Vlnas (jnv)]

Command "setxkbmap" works fine, but has not effect for me, when I put
it into ~/.bash_profile or even ~/.profile

[Mirza (mirza-seznam)]

to syntax: easier way - in system menu on top of the screen, find "session" configuration, I hope it is called that way in English version, and you will see list of programs that are started after login. Pres "add" and enter "setxkbmap" command, name it anyhow, and it should work.

[Jan Vlnas (jnv)]

@Mirza: Thanks, it seems that adding 'setxkbmap' to Gnome's autostart
finally work.

[lunomad (damon-metapaso)]

I have this problem as well in Hardy full updates on a Dell X1.

I use US, Latin American and Japanese layouts. I have three problems:

1) Alt+alt switching does not work (I have enabled LAlt+LShift which works)
2) "Show keyboard layout" opens a window, but no keyboard is shown.
3) Japanese SCIM input is not working.

Is there anyone who has gotten this to work that is also using SCIM?

I have edited my xorg.conf file with the following section:

Section "InputDevice"
 Identifier "Generic Keyboard"
 Driver "kbd"
 Option "CoreKeyboard"
 Option "XkbRules" "xorg"
 Option "XkbModel" "pc105"
 Option "XkbLayout" "us,latam,jp106"
 Option "XkbOptions" "grp:alts_toggle"
EndSection

And I put a setxkbmap command in my gnome session. I'm afraid of setting up the script because it looks like it might conflict with the xkb settings?

Thanks!

[Bryce Harrington (bryce)]

Another way to add 'setxkbmap' is to copy this into file ~/.config/autostart/setxkbmap.desktop:

[Desktop Entry]
Type=Application
Encoding=UTF-8
Version=1.0
Name=setxkbmap
Name[en_US]=setxkbmap
Exec=setxkbmap
X-GNOME-Autostart-enabled=true

[ikar (ioannis-karalis)]

O.K I have the same problem and I have to set the keyboard layout settings every time I boot. Since I am a linux newbie could you more specific regarding the steps I have to follow? How do I save and run the script and how do I set it to the start up manager? Thx

[ikar (ioannis-karalis)]

O.K, following the directions here I have found a solution for changing layouts among us and greek keyboard. The issue has been resolved in my case after manual correction of /etc/X11/xorg.conf as shown below:

ORIGINAL:
Section "InputDevice"
 Identifier "Generic Keyboard"
 Driver "kbd"
 Option "XkbRules" "xorg"
 Option "XkbModel" "pc105"
 Option "XkbLayout" "us"
EndSection

Modified:
Section "InputDevice"
 Identifier "Generic Keyboard"
 Driver "kbd"
 Option "XkbRules" "xorg"
 Option "XkbModel" "pc105"
 Option "XkbLayout" "us,el"
        Option "XkbOptions" "grp:ctrl_shift_toggle"
EndSection

Hope this can help others too!

[Ilya (ilya-redhat-bugs)]

Description of problem:

A keyboard layout bug. After boot strange characters entered from keyboard
instead proper ones. Also keyboard layout cannot be switched neither by
switchkey, nor through menu switcher. Default layout is US English, second
layout is Russian-winkeys. The proper layout can only be restored through
keyboard properties screen.

The attachment shows incorrect characters displayed just after bootup, with
layout indicator shows US English as the current layout.

[Ilya (ilya-redhat-bugs)]

Created attachment 305899
screenshot showing the bug

[Ilya (ilya-redhat-bugs)]

By the way, on the fresh system all worked well (FC9-release). The bug appeared
after I made updates from the Internet.

[dj3 (dim-jakobi)]

The above solution works for me, thanks a lot! (For German/Russian: Option "XkbLayout" "de,ru").

[Frantisek Fuka (fuxoft)]

Unfortunately, the "setxkbmap" solution doesn't work for me. After I run "setxkbmap", I can indeed switch between Czech and English keyboard (the toolbar indicator now works and the layout changes correctly) but the "dead key" for writing characters with diacritics doesn't work at all. It's completely DEAD (hahaha). When I press the dead key (the key immediately to the right of "-") and then "a", it should produce "á". However, it produces normal "a", the dead key doesn't do anything and that means I'm unable to write several commonly used Czech characters. After I go to "Keyboard" configuration and change something small, everything works fine - until next reboot.

Everything also works fine when I disable gdm autologin.

When I create new user account, it's also mared by this problem.

The "xorg.conf solution" is useless for me because it changes the global keyboard configuration for everyone whereas different users on my machine need to use different keyboard configurations.

I see the exact same problem on FOUR different machines (all of them updated from 7.10) with quite different hardware and software configurations. I read it works correctly on "virgin" installations. What should I remove/reinstall? Do I realy have to reinstall my whole system just because of this bug? It's very annoying to have to explain to my 70-year old mother that she has to go to "Keyboard" options and change something, then change it back for the keyboard to work in both languages...

[Yankele52 (yankele-timetotalk)]

 I added the "Israel" layout and then "+Add to Panel..." the keyboard indicator and now I can switch from the panel between En and He with no problem.
The only problem I have is with Thunderbird Hebrew (I can't combine He-En, It makes me crazy...) . I believe that this is a Mozilla-Thunderbird bug.
Can you help....

[TenLeftFingers (tenleftfingers)]

Hi Yankele52,

Submit a seperate report if you believe it is a Mozilla issue, and tag it for that package. If you need help doing this you can email me and I'll be happy to help. But a discussion outside the scope of this bug report does not belong here.

Regards,
Jarlath

[Götz Christ (g-christ)]

I can confirm the same bug in Hardy.

Adding 'setxkbmap' to Gnome's autostart has fixed this.

[Miloš Mandarić (mandzo18)]

'setxkbmap' also fixes problem in my case.

[Frantisek Fuka (fuxoft)]

Including the diacritics dead keys? Not in my case (Czech layout). See my message above.

[Joro Todorov (gueorguitodorov)]

 'setxkbmap' works for me too. It also fixes Ctsl/Caps swapping bug.
 However I have to execute it every time. I tried adding 'setxkbmap' line to .bash_profile or rc.local but it didn't work. Why :( ?

[Jan Vlnas (jnv)]

To Joro Todorov: Have you tried adding it as autostart item? See
https://bugs.launchpad.net/ubuntu/+source/xorg/+bug/196277/comments/69

[Joro Todorov (gueorguitodorov)]

Thanks syntax

[mp (m-p)]

Confirmed.

[Amr Hassan (amr-hassan)]

confirmed in hardy..

[Bob Radu (bobradu)]

Again confirmed after the latest updates. Gnome 2.22.2 and Hardy (Linux 2.6.24-18-generic). So annoying.

[Aristotelis Mikropoulos (amikrop)]

I just would like to add that the issue applies for the Eurosign €, as well. So, annoying, indeed.

[Ansus (neptunia)]

Confirming in Hardy. Gusty had no such problem.

Also observed the same problem on Fedora 9 after updates (but on the fresh install all worked well).

[Ansus (neptunia)]

Still there after all updated as of June 17 2008 (i.e. with post- 8.04.1 updates).

[Simos Xenitellis  (simosx)]

The picture I have is this:

A. Ubuntu and GNOME have their own system to deal with switching layouts, adding options such as whether to get the euro key and so on. You see these in System/Preferences/Keyboard/Layouts.

B. Traditionally, the Linux desktop would read this information from the cryptic file in /etc/X11/xorg.conf, in the Keyboard section. Over there you can set all the options that you normally set now in the graphical user interface.

C. When the graphical interface starts, GNOME makes a decision; is it possible to use the settings in System/Preferences/Keyboard/Layouts? Now, it appears in some cases, the answer is no (for example, if you have Autologin enabled), so GNOME eventually uses the keyboard settings found in /etc/X11/xorg.conf. These settings are not configured, and it ends up just typing English.

The hot issue is this:

Does this problem appear when you enable Autologin into GNOME?

Can you verify that when you disable Autologin, the settings work (requires reboot)?

Are there other cases (when Autologin is off) that the problem still appears?

[Frantisek Fuka (fuxoft)]

To Simos Xenitellis:

Yes, this problem appears ONLY when I enable Autologin. With Autologin enabled, the problem is ALWAYS present. With Autologin disabled, the problem is NEVER present.

When the Autologin is enabled, the "solution" to this problem is opening "Keyboard preferences", opening "Layouts / Layout options" and toggling ANY option On and back Off. Afterwards, the switching works correctly... Until next reboot.

Unfortunately, I am not enough Linux expert to dig deeper into this problem. But if someone wants to dig, I am more than willing to help. I have this exactly same problem on FOUR different machines and it's very hard for me to explain to (non-geek) people that "Yes, Ubuntu is great, you can use it instead of Windows but you cannot type Czech characters until you do this crazy stuff each time you turn it on..."

[Ansus (neptunia)]

I experience this problem both with and without autologin.

Also in Ubuntu 7.10 I was sometimes asked afted boot which settings to use: from xorg.conf or from Gnome (even when autologin was enabled). In 8.04 I never seen this question dialogue.

In Fedora 9. This also was independent of autologin. The bug appeared exactly after the system update.

[Ansus (neptunia)]

I agree that this is very important for overal Linux image amang people. Here in Russia EVERY Ubuntu user will face this problem, which makes Linux an image of very buggy OS. People still ask "is there support for Russian in Linux?" but what you should answer them? "Yes, it has, but... well wait until they fix it"? I wonder how it was possible to release this update without testing.

[Bob Radu (bobradu)]

I can confirm that the issue does not appear when I turn off auto or timed login.

[xlinuks (xlinuks-yahoo)]

I confirm too that the issue is gone after turning off auto login (at System->Administration->Login Window->Security).
This might be also important: each time I after install (not start, but install) Ubuntu 8.04, when the first time I access this option it takes like forever to display this window (sometimes I have to restart the computer, regardless of AMD or Intel chip). So perhaps this bug gets "auto-created" at this point?

[Simos Xenitellis  (simosx)]

Nxx: You are currently the only person mentioning that the problem exists for you, even when you disable autologin (or timed login).

Could you please run the command

gconftool-2 -R /desktop/gnome/peripherals/keyboard/kbd

and report back the results?

What I am interested in is the value for the "overrideSettings" variable.

If this variable is "false", then GNOME ignores the settings in System/Preferences/Keyboard/Layouts, and uses the information from /etc/X11/xorg.conf.

AFAIK, this variable ("overrideSettings") is set to "false" when you are presented with the situation you describe with "also in Ubuntu 7.10 I was sometimes asked afted boot which settings to use: from xorg.conf or from Gnome" in your comment above.

[Jacob Nordfalk (jacob-nordfalk)]

Its not that this is a critical bug for all non US-keyboard users....
Its not that is has been around for 3 1/2 months with now 20 duplicates...
Its that Ubuntu is giving new users NO CHANCE to find out what to do about the problem!

I have been using Mandriva, so I'm used to relase notes and errata.
http://wiki.mandriva.com/en/Releases/Mandriva/2008.0/Notes
http://wiki.mandriva.com/en/Releases/Mandriva/2008.0/Errata
These two documents are perhaps the most valuable documents at all for a distro.
They save all users (especially new ones!) for TONS of time.

Now see what you get in Ubuntu:
http://www.ubuntu.com/getubuntu/releasenotes/804 ... nothing, it's a joke!

And this bug is now the only one. To another show-stopper for Linux beginners (https://bugs.launchpad.net/ubuntu/+source/openoffice.org/+bug/149586) I got the answer 'this bug is not worth a mention'.

Now, I like Ubuntu and after I have spend the days needed to learn to do the right searches on Launchpad I will stick to it.
But the sole lack of an errata document with known bugs (and workarounds) makes me feel Ubuntu is NOT suited at all for beginner Linux users, becaurse they have hell no change whatsover to neither review their problem nor solve them!

So this (not the bug itself, but the lack of an errata document!) has made me confident that new users should perhaps try Ubuntu for fun, but if they decide to switch to Linux from Windows they should use another distro, perhaps Mandriva.

I hope this will not be taken as a flame, becaurse I like Ubuntu but this is just too important to not critisize.

Yours Jacob

[Simos Xenitellis  (simosx)]

Ori,

You linked this bug to the bug report https://bugs.freedesktop.org/show_bug.cgi?id=4927
It does not appear to have relevance to me.

I am considering removing the link. Does anyone have objections?

[Jan Vlnas (jnv)]

I wonder why the simmilar or maybe the same bug #173721 is marked as fixed. Adding the configuration into the xorg.conf is a workaround, but definitely not a fix.

[Simos Xenitellis  (simosx)]

Jacob,

Ubuntu Linux is this community; which is ourselves.
When we find bugs, we cooperate in figuring out what's the source and how to fix them.
If one does not have programming skills, they can still help with triaging, testing and reporting back what is requested.
All this work is voluntary, whether it is Ubuntu, Fedora, OpenSUSE or else.
Suppose some guy manages to fix this bug. Is anyone going to send him/her a personal e-mail thanking them?
We, as end-users have to figure out constructive ways to attract people to help in programming, or make the effort ourselves as well to help with figuring out these bugs.

I would like to switch this discussion back to constructive effort, and eventually fix this bug.

[Jacob Nordfalk (jacob-nordfalk)]

Simos,

Im sorry if I have offended any body, I was perhaps too full of feelings.

I have files my proposal of an errata document as a seperate "bug".
Those interested can subscribe https://bugs.launchpad.net/ubuntu/+bug/240713 where we can then discuss the matter.

[aldebx (aldebx)]

Jacob,
despite Canonical's fault is that it hasn't even mentioned this bug, they cannot provide assistance for it.

"So it is not an issue in the input-output code, it is a bigger issue - in the
XKM format. This causes problems when configuration is passed through binary files."

"This problem is very visible now - the default GNOME switcher Alt-Alt is broken
- because virtual modifiers RAlt/LAlt are not passed to X server."

These quotes are taken from the upstream bug report https://bugs.freedesktop.org/show_bug.cgi?id=4927
which explains why this bug couldn't be fixed before 8.04 shipping and also before Xorg 7.4. It seems to be requiring a relevant architecture change in the keyboard manager subset.

I'm also waiting for it to be fixed. If some Canonical dev can help the guys at Xorg would be a nice contribution for the whole community since this bug has a relevant major impact on the user experience.

[Bryce Harrington (bryce)]

For errata on Xorg drivers, I would refer you to https://wiki.ubuntu.com/X/Drivers, which is an Xorg driver status page I maintain, listing known issues. Please feel free to let me know if you know any other highly important confirmed issues that ought to be added there.

[Bryce Harrington (bryce)]

Both Canonical and upstream are aware of this issue and consider it of high importance. Unfortunately, the root cause is not something that can be easily fixed.

The issue is that to solve this problem, X needs to have a way to save the ExplicitVModMapMask, which is tracked okay in memory but not when the configuration is passed via XKM binary files, because the XKM binary file format simply doesn't have a field for storing the VModMask flag data. The XKM file format allows only 8 flags to be set total, and there are already 8 defined. See the upstream bug report for details: https://bugs.freedesktop.org/show_bug.cgi?id=4927

Upstream's proposed solution to the problem is to remove the xkbcomp design and the xkm file format entirely, and switch to new X input technologies. This will be a fairly sizeable re-architecting effort, and will take time to complete. If you would like to help contribute to this solution for this problem, please offer your assistance to Sergey Udaltsov.

[Ansus (neptunia)]

Why simply not to rollback to the previous versions of the software which worked well?

[Timpotten (tim-potten)]

The default radio button on mine is not selectable
I found I had two files after resetting keyboard and deleting the US keyboard (so only Spain was displayed)

/etc/X11/xorg.conf.20080506153915 (contained the correct ES Keyboard)
/etc/X11/xorg.conf.20080506155231 (contained US Keyboard which should have been deleted)

They contain the advice

# If you have edited this file but would like it to be automatically updated
# again, run the following command:
# sudo dpkg-reconfigure -phigh xserver-xorg

[Simos Xenitellis  (simosx)]

Bryce, it looks to me that the issue that you are referring to
is different from the issue that the GUI layout settings are not enabled
when the user has activated the autologon feature.

When GNOME starts, libgnomekdb makes a decision
whether to use the system layout settings (found in /etc/X11/xorg.conf),
or use the user-configured layout settings (found in gconf).

The latter is the typical choice, and only when gconf settings are not provided,
libgnomekdb ends up using the system (/etc/X11/xorg.conf) as last resort ("shortcut does not work after reboot").

What it looks to me is that during autologin, libgnomekdb fails to read the gconf entries (maybe gconf is started a bit later, or something?) so it ends up with the system settings (xorg.conf).

[Ansus (neptunia)]

Probably it is related to some timing issues during bootup. For example, I frequently have Nautilus to fail to load at bootup with autologin (but not always), see the bug https://bugs.launchpad.net/ubuntu/+source/nautilus/+bug/241807 , when typing the password manually it always loads, and also pptp connection if configured to run in the startup scripts, works only if to insert a long pause before the command, or start in step-by-step mode (in earlier distributions all worked well without any pause).

[Simos Xenitellis  (simosx)]

After discussion with Sergey Udaltsov (maintainer of xkeyboard-config, libgnomekbd, libxklavier), he said that the source of this is libxklavier. So I am removing libgnomekdb and add libxklavier in the bug report.

[Simos Xenitellis  (simosx)]

This bug report mixes together two separate issues.

The first issue is that some shortcuts that can be used to switch between layouts, do not work. They do not work due to issues that related to the X.Org, and are described at
https://bugs.freedesktop.org/show_bug.cgi?id=4927
A workaround here is to change the shortcut to something else that works.

Then, this report switched to a different issue. When autologin is enabled, GNOME (keyboard settings) are not able to configure the shortcut or any other keyboard-related settings (such as euro, compose, layouts, etc). This is (most probably) due to the autologin feature.
The workaround here is to disable autologin.

Rapolas (reporter), how shall we go about this issue? Which issue do you want this report to cover?

[Ansus (neptunia)]

Since the report is about not working layout switching after reboot, it's definitely about Gnome settings not loading at bootup.

[Timpotten (tim-potten)]

The inability to switch from initial US default to User may be connected to the feature that the user preference flag can not be set.
On the system - preferences - keyboard - [layouts] tab - although any loaded keyboard type can be selected (say for deletion)
 The radio button <default>indicator can not be selected to indicate the user's choice is activated as default.

On mine, although editing the /etc/X11/xorg.conf has worked, and the machine now selects my Spanish keyboard on start-up,
I would have to edit this xorg.conf file again to set the default to something else.

Was there an update in this area sometime about May 6th 2008?
/etc/X11/xorg.conf.2008 05 06 153915 (contained the correct ES Keyboard)
/etc/X11/xorg.conf.2008 05 06 155231 (contained US Keyboard which should have been deleted)

[mp (m-p)]

this problem has seized to exist for me - after an update (didnt notice
exactly which ones, due to being very busy) it just works..

Timpotten wrote:
> The inability to switch from initial US default to User may be connected to the feature that the user preference flag can not be set.
> On the system - preferences - keyboard - [layouts] tab - although any loaded keyboard type can be selected (say for deletion)
> The radio button <default>indicator can not be selected to indicate the user's choice is activated as default.
>
> On mine, although editing the /etc/X11/xorg.conf has worked, and the machine now selects my Spanish keyboard on start-up,
> I would have to edit this xorg.conf file again to set the default to something else.
>
> Was there an update in this area sometime about May 6th 2008?
> /etc/X11/xorg.conf.2008 05 06 153915 (contained the correct ES Keyboard)
> /etc/X11/xorg.conf.2008 05 06 155231 (contained US Keyboard which should have been deleted)
>

[Erez Segal (segalerez)]

I updated everything I could - and still experience the bug. I can confirm though, that canceling auto login worked for me.

> this problem has seized to exist for me - after an update (didnt notice
> exactly which ones, due to being very busy) it just works..

[Aristotelis Mikropoulos (amikrop)]

I, also, can confirm that disabling auto-login fixes the problem. But this is, obviously, not a solution.

[Simos Xenitellis  (simosx)]

Could someone that is affected by this issue (they have enabled Autologin and the switching does not work), add their ~/.xsession-errors here?

At the start of the file there should be some helpful debugging errors.

[Bob Radu (bobradu)]

/etc/gdm/Xsession: Beginning session setup...
Setting IM through im-switch for locale=en_US.
Start IM through /etc/X11/xinit/xinput.d/all_ALL linked to /etc/X11/xinit/xinput.d/default.
SESSION_MANAGER=local/HOME-PC:/tmp/.ICE-unix/6300
** Message: another SSH agent is running at: /tmp/ssh-ZFDdjE6300/agent.6300
W: daemon-conf.c: Failed to open configuration file '/etc/pulse/daemon.conf': Permission denied
expected keysym, got XF86KbdLightOnOff: line 70 of pc
last scanned symbol is: XF86KbdLightOnOff
expected keysym, got XF86KbdBrightnessDown: line 71 of pc
last scanned symbol is: XF86KbdBrightnessDown
expected keysym, got XF86KbdBrightnessUp: line 72 of pc
last scanned symbol is: XF86KbdBrightnessUp
Warning: No symbols defined for <SYRQ> (keycode 92)
Warning: No symbols defined for <II65> (keycode 101)
Warning: No symbols defined for <BRK> (keycode 114)
Warning: No symbols defined for <FK13> (keycode 118)
Warning: No symbols defined for <FK14> (keycode 119)
Warning: No symbols defined for <FK15> (keycode 120)
Warning: No symbols defined for <FK16> (keycode 121)
Warning: No symbols defined for <FK17> (keycode 122)
Warning: No symbols defined for <KPDC> (keycode 123)
Warning: No symbols defined for <XFER> (keycode 129)
Warning: No symbols defined for <I02> (keycode 130)
Warning: No symbols defined for <NFER> (keycode 131)
Warning: No symbols defined for <I04> (keycode 132)
Warning: No symbols defined for <AE13> (keycode 133)
Warning: No symbols defined for <I06> (keycode 134)
Warning: No symbols defined for <I07> (keycode 135)
Warning: No symbols defined for <I08> (keycode 136)
Warning: No symbols defined for <I09> (keycode 137)
Warning: No symbols defined for <I0A> (keycode 138)
Warning: No symbols defined for <I0B> (keycode 139)
Warning: No symbols defined for <I0C> (keycode 140)
Warning: No symbols defined for <I0D> (keycode 141)
Warning: No symbols defined for <I0E> (keycode 142)
Warning: No symbols defined for <I0F> (keycode 143)
Warning: No symbols defined for <I10> (keycode 144)
Warning: No symbols defined for <I11> (keycode 145)
Warning: No symbols defined for <I12> (keycode 146)
Warning: No symbols defined for <I13> (keycode 147)
Warning: No symbols defined for <I14> (keycode 148)
Warning: No symbols defined for <I15> (keycode 149)
Warning: No symbols defined for <I16> (keycode 150)
Warning: No symbols defined for <I17> (keycode 151)
Warning: No symbols defined for <I18> (keycode 152)
Warning: No symbols defined for <I19> (keycode 153)
Warning: No symbols defined for <I1A> (keycode 154)
Warning: No symbols defined for <I1B> (keycode 155)
Warning: No symbols defined for <K59> (keycode 157)
Warning: No symbols defined for <I1E> (keycode 158)
Warning: No symbols defined for <I1F> (keycode 159)
Warning: No symbols defined for <I20> (keycode 160)
Warning: No symbols defined for <I...

[Simos Xenitellis  (simosx)]

Comparing with my output, it does not show something different.
What you can do now is set the XKL_DEBUG variable in /etc/environment
If you set it to 100, you will get very detailed output. You can try 100 first, and if the output is too much (a line per key pressed), you can change to 1.

Then, you can attach the .xsession-errors file in this report (there is a way to attach files from below).

[Rapolas K. (casselas)]

Simos Xenitellis, actually I don't care which issue this report covers, all I want is to get fixed it. I think Nxx answered already. But it is not bothering me now, I added setxkbmap command to session startup and it is working now. Also i had to change from both alts, to alt+shift shortcut. I don't like this way, because when I try to move window to another desktop, which default shortcut is alt+shift+control arrow and I'm used to it, I get my keyboard layout switched, but not the window moved.

[Simos Xenitellis  (simosx)]

When autologin is enabled in GNOME, it appears that libxklavier fails to set the layout settings. The system falls back to the /etc/X11/xorg.conf layout settings.

This has been reported in Ubuntu 8.04, running
  X.Org X Server 1.4.0.90
  Release Date: 5 September 2007
  X Protocol Version 11, Revision 0
  Build Operating System: Linux Ubuntu (xorg-server 2:1.4.1~git20080131-1ubuntu9.2)
  Current Operating System: Linux computer 2.6.24-19-generic #1 SMP Wed Jun 18 14:15:37 UTC 2008 x86_64 (or x86)
  Build Date: 13 June 2008 01:10:57AM

When setting XKL_DEBUG=100, .xsession-errors shows the following:

[1214761388,100,xklavier_config_xkb.c:xkl_xkb_multiple_layouts_supported/] !!! Checking multiple layouts support
[1214761388,100,xklavier_config.c:xkl_engine_get_ruleset_name/] Rules set: [xorg]
[1214761388,100,xklavier_config_xkb.c:xkl_xkb_multiple_layouts_supported/] !!! Multiple layouts ARE supported
[1214761388,000,xklavier.c:xkl_engine_start_listen/] The backend does not require manual layout management - but it is provided by the application[1214761389,100,xklavier_config.c:xkl_engine_get_ruleset_name/] Rules set: [xorg]
[1214761389,100,xklavier_config.c:xkl_engine_get_ruleset_name/] Rules set: [xorg]
[1214761390,100,xklavier.c:xkl_engine_reset_all_info/] NOT Resetting the cache: same configuration
[1214761390,100,xklavier.c:xkl_engine_reset_all_info/] NOT Resetting the cache: same configuration
[1214761390,100,xklavier.c:xkl_engine_reset_all_info/] NOT Resetting the cache: same configuration
[1214761390,100,xklavier.c:xkl_engine_reset_all_info/] NOT Resetting the cache: same configuration

[Sergey V. Udaltsov (svu)]

Has nothing to do with libxklavier

[Sergey V. Udaltsov (svu)]

It is well-known issue with autologin and startx - X reports XKB configuration as being set, but actually it is not.

[Frantisek Fuka (fuxoft)]

Here is attached my .xsession-errors file with XKL_DEBUG=100 with autologin enabled (resulting in inability to switch layouts):

[Simos Xenitellis  (simosx)]

Thanks Frantisek.
The relevant lines are

[1214761388,100,xklavier_config_xkb.c:xkl_xkb_multiple_layouts_supported/] !!! Checking multiple layouts support
[1214761388,100,xklavier_config.c:xkl_engine_get_ruleset_name/] Rules set: [xorg]
[1214761388,100,xklavier_config_xkb.c:xkl_xkb_multiple_layouts_supported/] !!! Multiple layouts ARE supported
[1214761388,000,xklavier.c:xkl_engine_start_listen/] The backend does not require manual layout management - but it is provided by the application[1214761389,100,xklavier_config.c:xkl_engine_get_ruleset_name/] Rules set: [xorg]
[1214761389,100,xklavier_config.c:xkl_engine_get_ruleset_name/] Rules set: [xorg]
[1214761390,100,xklavier.c:xkl_engine_reset_all_info/] NOT Resetting the cache: same configuration
[1214761390,100,xklavier.c:xkl_engine_reset_all_info/] NOT Resetting the cache: same configuration
[1214761390,100,xklavier.c:xkl_engine_reset_all_info/] NOT Resetting the cache: same configuration
[1214761390,100,xklavier.c:xkl_engine_reset_all_info/] NOT Resetting the cache: same configuration

[Simos Xenitellis  (simosx)]

Created upstream bug report, added link here

When autologin is enabled, system uses the xorg.conf layout settings
https://bugs.freedesktop.org/show_bug.cgi?id=16562

[Frantisek Fuka (fuxoft)]

I thought this bug only affects people who upgraded from older Ubuntu versions but yesterday I installed 8.04 desktop on a brand new computer and the bug is there...

Can I somehow help with getting it fixed?

Until it's fixed: Is there ANY WAY AT ALL to have working keyboard layout indicator in Ubuntu panel and switch layouts by clicking on this indicator? I install computers for non-geeks and they are unable to remember some sort of key-combination to switch layouts.

As I mentioned on 2008-05-24, the "setxkbmap" solution doesn't work for Czech layout.

Switching autologin off is also out of question because these users don't even know their passwords.

[Simos Xenitellis  (simosx)]

Frantisek:

The source of the problem appears to be that when X starts, it tries to initialise the current layouts, and I believe that it does a bit later than GNOME itself. As if GNOME sets the layout correctly, then X.org kicks in and resets to the values found in /etc/X11/xorg.conf.

Therefore, one workaround is to place all the settings in /etc/X11/xorg.conf at they keyboard layout section.

I sent an e-mail to the X.org mailing list,
http://lists.freedesktop.org/archives/xorg/2008-July/036938.html

We will see if that clears up the confusion.

[Mirza (mirza-seznam)]

Frantisek Fuka wrote:
> As I mentioned on 2008-05-24, the "setxkbmap" solution doesn't work for
> Czech layout.

I have Czech layout and setxkbmap added to session startup dialog works
fine. So, bug has random nature probably related to some obscure X
Server setting(s). I have feeling that if I dig deep into any problem I
had with Ubuntu, I ended up at some X Server bug that is root cause of
problem, just like here. Is it really impossible for company like
Canonical to create some alliance and rewrite (and more importantly
re-design) this shitty layer that lives like cancer in between healthy
layers of kernel and Gnome/KDE? </flame>

Mirza

[Frantisek Fuka (fuxoft)]

Simos,

I know I can put "XkbLayout us,cz" to xorg.conf and then switch between layouts using keyboard shortcut.

However, as I wrote earlier, my users need to switch between US and CZ layouts BY CLICKING ON SOME SORT OF INDICATOR in the Ubuntu panel, not by pressing "Alt-Shift", "Alt-Alt" or some other cryptic (for them) combination. Also, they prefer to have difeerent keyboard layouts for different windows. They are 60-70 years old people without computer experience!

From your name I'd say you are Greek so you must know how important it is for people to be able to use both US and local keyboard.

Tell me how I can do this. (This is not a rhetorical question. I really have no idea if or how this can be done.)

I know the indicator and switching start working immediately when I change something in "Keyboard preferences". Can this somehow be done programatically? For example, I could have a script that waits until 10 seconds after desktop has started, then changes some insignificant thing in Keyboard Layout settings, and re-initializes it? This could be the way, at least for now...

[Simos Xenitellis  (simosx)]

First of all, we are all in the same boat. We all want to get this fixed, and the only way to get it is by contributing our time on figuring out a solution.

Secondly, I am not aware that a developer is funded to work full-time on keyboard issues and X. There are some other issues pertaining to keyboard support, more complex than this issue. It would be great if there was a person funded to work full time on these core issues.

Mirza, we want more evidence that the source of the problem is that, due to autologin, X.org is too slow to set the layout settings, and it sets them AFTER GNOME has done so, essentially overriding GNOME. In your reply, it is not clear that from your tests, you verify the above. You mention "random". Does it work for you for some cases, while in others it does not work?

Frantisek, I had a discussion with the developer of libklavier last week. It is possible to write a program that invokes a function from the libxklavier library so that it configures again the keyboard layout. I believe this is what you are asking me. Another way for a workaround is to figure out where/when is the GNOME applet invoked, and add a delay for, let's say 5 seconds, before actually running the applet. You may find the developer at #xkbconfig on Freenode if you want to take this further.

[Mirza (mirza-seznam)]

Simos Xenitellis wrote:
> Mirza, we want more evidence that the source of the problem is that, due
> to autologin, X.org is too slow to set the layout settings, and it sets
> them AFTER GNOME has done so, essentially overriding GNOME. In your
> reply, it is not clear that from your tests, you verify the above. You
> mention "random". Does it work for you for some cases, while in others
> it does not work?

In my case, adding "setxkbmap" to Gnome session startup solved issue
completely, including keyboard switching and Gnome panel
indicator/switching - I am not aware of any remaining problems. However,
same didn't work in Frantisek's case, hence my comment on "randomness"
of this issue - same solution might or might not work on different
computers.

Mirza

[Milan (milan-redhat-bugs)]

*** Bug 449305 has been marked as a duplicate of this bug. ***

[Milan (milan-redhat-bugs)]

I'm not sure what component should be selected for this bug. I hit the same
problem. After a restart I have to go to the keyboard setting through keyboard
applet and change something (deleting and adding keymap). Then keyboard
switching works then again. I'm using default GNOME session.

[Ilya (ilya-redhat-bugs)]

I think official Fedora notes should mention that languages other than English
are not fully supported. Otherwise all people who use another language would
think Fedora is a very buggy system.

[Simos Xenitellis  (simosx)]

Frantisek:

You should check again the workaround with added setxkbmap to the GNOME session startup.
This should work. I think you mentioned above that it did not work for you, however I would like to insist on this.
Could you please describe all the steps you took to add the command in the sessions?
An alternative would be to write a script that looks like

--------------
#!/bin/sh

(sleep 5; /usr/bin/setxkbmap) &
--------------

and invoke that command in the sessions. What the command does is it sleeps for 5 seconds before running setxkbmap.

Mirza: In many cases there are some minor differences in applying commands, which cause the difference in results. I believe it is imperative to double-check the steps. I hope it clears out when Frantisek tries again.

[Michael Nagel (nailor)]

META-Question: at some point we agreed that there are two seperate bugs, namely:
1) automatic login to gnome changes keyboard layout
2) some previously working combos(like double alt) are no longer valid key-combos to change the layout

are these bugs properly split now?
where is the main bug for issue 1?
where is the main bug for issue 2?
could description and titles be modified to reflect this seperation?

[Ansus (neptunia)]

>However, as I wrote earlier, my users need to switch between US and CZ
>layouts BY CLICKING ON SOME SORT OF
>INDICATOR in the Ubuntu panel

Well in my case the layout switching worked by clicking the indicator even when the settings were put in xorg.conf... Until recent update but it is a matter of another bug report I made.

[Frantisek Fuka (fuxoft)]

I tried adding "setxkbmap" to my session again and, suprprisingly, it now works perfectly (on 3 different computers). However, I am 100% sure that when I tried the same thing in May, it didn't work (to be exact, it worked, but dead keys with diacritics didn't - as described in my post from May).

[Erez Segal (segalerez)]

I can confirm that adding "setxkbmap" to the session works.

[evgen (evgen-alice-dsl)]

i have the same issue as described abode, that the layout seted up in System-Preferences->Keyboard holds till the next restart...

as a workaround i have modified xorg file

original:

Section "InputDevice"
 Identifier "Generic Keyboard"
 Driver "kbd"
 Option "XkbRules" "xorg"
 Option "XkbModel" "pc105"
 Option "XkbLayout" "de"
 Option "XkbVariant" "nodeadkeys"
EndSection

new:

Section "InputDevice"
 Identifier "Generic Keyboard"
 Driver "kbd"
 Option "XkbRules" "xorg"
 Option "XkbModel" "pc105"
 Option "XkbLayout" "de,ru"
 Option "XkbVariant" "nodeadkeys"
 Option "XKbOptions" "grp:alt_shift_toggle"
EndSection

but "nodeadkeys" option does not work any more....

[evgen (evgen-alice-dsl)]

ok the issue with deadkeys is solved as a workaround too, as i have just tested with "setxkbmap de,ru -variant nodeadkeys," in terminal and it worked so,

new setting in xorg file:

Section "InputDevice"
 Identifier "Generic Keyboard"
 Driver "kbd"
 Option "XkbRules" "xorg"
 Option "XkbModel" "pc105"
 Option "XkbLayout" "de,ru"
 Option "XkbVariant" "nodeadkeys,"
 Option "XKbOptions" "grp:alt_shift_toggle"
EndSection

have you seen this differens?
replaced Option "XkbVariant" "nodeadkeys" with Option "XkbVariant" "nodeadkeys,"
:-P
so all you need is:

Option "XkbVariant" "nodeadkeys,nodeadkey" OR
Option "XkbVariant" ",nodeadkey" OR
Option "XkbVariant" "nodeadkeys,"
what ever your layouts need

[svaens (svaens)]

Not sure what you say has been fixed (geez this is a long running bug report)
but since this is a duplicate bug of a bug that I have experienced (and still am experiencing in up-to-date hardy) I will give my short two cents.

On up-to-date hardy as of 10/07/2008, I cannot (using keyboard combination alt - alt ) change my keyboard from US to DE (US English keyboard to German Keyboard) however, I was always able to change from DE to US using the same key combination. In other words, It would only work ONE WAY.

For ME, the SHIFT-SHIFT combination works perfectly. Now I can switch both ways (US to DE, and back again - DE to US).

For me it is only the Alt - Alt key combination that continues not to work to this day.

[David Huggins-Daines (dhuggins)]

Hi, I found four more duplicates of this bug.

I am willing to try my hand at tracking it down if someone can inform me exactly which GNOME component is the one which attempts to apply keyboard settings on login. Is it gnome-settings-daemon?

I should note that the upstream bug report says "this has nothing to do with libxklavier - xkb reports settings are applied when xinit is used, when they really aren't"

[David Huggins-Daines (dhuggins)]

Never mind, I have traced it into libxklavier.

The problem is, those "NOT resetting the cache" error messages are a red herring. I hacked libxklavier to always reset the cache on XkbNewKeyboardNotify, and it doesn't make any difference.

The settings are not being applied for some other reason. I did set XKL_DEBUG to 999 and found one interesting difference. When I have autologin on, .xsession-errors contains this:

[1216339029,200,xklavier_xkb.c:xkl_xkb_load_all_info/] found 1 groups
[1216339029,200,xklavier_xkb.c:xkl_xkb_load_all_info/] Group 0 has name [USA]

Whereas, when I log in explicitly, it contains this:

[1216347662,200,xklavier_xkb.c:xkl_xkb_load_all_info/] found 2 groups
[1216347662,200,xklavier_xkb.c:xkl_xkb_load_all_info/] Group 1 has name [USA]
[1216347662,200,xklavier_xkb.c:xkl_xkb_load_all_info/] Group 0 has name [-]

I don't know much about xkb so I'm not sure what this "-" group is or where it came from.

[David Huggins-Daines (dhuggins)]

One more data point here to consider. When I have autologin on, and I run 'setxkbmap -print', it actually does show the options which were set by libxklavier:

dhuggins@slim:~$ setxkbmap -print
xkb_keymap {
        xkb_keycodes { include "xfree86+aliases(qwerty)" };
        xkb_types { include "complete" };
        xkb_compat { include "complete" };
        xkb_symbols { include "pc+us+level3(ralt_switch_for_alts_toggle)+group(alts_toggle)+compose(rctrl)" };
        xkb_geometry { include "pc(pc101)" };
};

However, these options have not actually been set in the server! As everybody else mentioned, running setxkbcomp with no options (which actually compiles the description and loads it into the server) makes these settings active. This is equivalent to running:

setxkbmap -print | xkbcomp - :0

These options aren't stored in any configuration file, so setxkbmap *must* be getting them from the X server somehow, right? And yet, for some reason, the server knows about the uncompiled form of the keyboard description but hasn't actually loaded it...

[David Huggins-Daines (dhuggins)]

The libxklavier author is correct, this is not a bug in libxklavier. It does everything exactly as it should, and calls XkbWriteToServer() to set the new keymap, and checks its return value. I have verified this.

The problem is that XkbWriteToServer() is failing silently, for no apparent reason, during startup when autologin is enabled (or, it seems, when GNOME is started via xinit). And yet it works just fine once everything has settled down.

I conjecture that the reason it works with manual login is because in that case, the X server has completely started up well before the point where GNOME tries to apply keyboard settings.

Maybe moving gnome-settings-daemon later in the startup sequence would fix this? I'm revealing my ignorance of how GNOME actually starts up here...

[Simos Xenitellis  (simosx)]

dhd, thanks for taking this further.

See this reply for additional information,
http://lists.freedesktop.org/archives/xorg/2008-July/036947.html

[David Huggins-Daines (dhuggins)]

Okay, that makes perfect sense, except that it's not at all clear if it's possible to change the XKB layout for a specific device. It's something that, in the new age of MPX, really ought to be possible, but from what I understand, it would require XKB to be aware of XInput and multiple devices, which I don't think is the case (see http://www.fooishbar.org/talks/fosdem-xkb.pdf).

I suppose that what we could do is have libxklavier recopy the XKB layout to the server every time it gets an XkbNewKeyboardNotify event. Which, ironically, is more or less the opposite of what it currently does (it updates its cache from the server's information when it gets this event - this is the source of those "red herring" messages above).

[Andrew Conkling (andrewski)]

I should mention that I had this bug at some point, but an update fixed it.
I'm not convinced a lot of the duplicates are really the same bug if you're
still seeing this.

[David Huggins-Daines (dhuggins)]

Are you running Hardy or Intrepid? I am totally up to date on Hardy on three different machines, and I can assure you that the exact sequence of actions mentioned in, among others, bug reports 173721, 182336, and 222653, will show this bug every single time.

If this has been fixed in Intrepid then this fix needs to be isolated and backported to Hardy, right?

[Götz Christ (g-christ)]

I'm using a fresh install of Kubuntu Hardy with KDE 4.1 and don't have that bug any more. So, has KDE a fix/workaround for this or the problem is only in Gnome?

[cyrulution (kube)]

I just switched my PC on this morning, using Gnome. tried the keyboard switching: ...nothing ... Settings off and on. !!! There it is again!
I installed all available updates. So: at my Ubuntu there's still this bug.

[Shawn vega (svega85-gmail)]

yeah i still have this problem too so I think it maybe just a gnome issue

[Andrew Conkling (andrewski)]

On Fri, Jul 18, 2008 at 9:58 AM, dhd <email address hidden> wrote:

> Are you running Hardy or Intrepid? I am totally up to date on Hardy on
> three different machines, and I can assure you that the exact sequence
> of actions mentioned in, among others, bug reports 173721, 182336, and
> 222653, will show this bug every single time.

Hardy. Granted, I have -updates and -proposed installed, so I may have newer
packages. I haven't gone back to test those actions mentioned in other bugs.
I could though, if it'd help.

[David Huggins-Daines (dhuggins)]

Hi, I haven't yet checked to see if anything in -proposed fixes it (I tried the new gdm, which doesn't).

However, I can confirm Peter Hutterer's explanation for the bug. It's really easy to verify. Just do this:

 1) Enable autologin
 2) Go to the console and run sudo /etc/init.d/gdm restart
 3) While gdm is starting up, press a lot of random keys. Don't stop until you see the GNOME panel appear.
 4) Voilà! (hey, my compose key works)

[Ansus (neptunia)]

A related bug: https://bugs.launchpad.net/ubuntu/+source/xorg/+bug/243575

[Andrew Conkling (andrewski)]

On Tue, Jul 22, 2008 at 10:45 AM, dhd <email address hidden> wrote:

> However, I can confirm Peter Hutterer's explanation for the bug. It's
> really easy to verify. Just do this:
>
> 1) Enable autologin
> <SNIP>
>

Wait, so this bug (at least now) only has to do with autologin? Because I
subscribed a while ago because I was experiencing a different bug, and it
wasn't to do with autologin.

[Michael Nagel (nailor)]

see my comment (#131, https://bugs.launchpad.net/ubuntu/+source/xorg/+bug/196277/comments/131 )

this bug should be split into two seperate issues imho!

[Simos Xenitellis  (simosx)]

I updated the title; a discussion on the underlying cause of this issue is at
http://lists.freedesktop.org/archives/xorg/2008-July/036947.html

[Simos Xenitellis  (simosx)]

Ubuntu bug report
https://bugs.edge.launchpad.net/ubuntu/+source/xorg/+bug/196277

Fedora bug report
https://bugzilla.redhat.com/show_bug.cgi?id=447252

[Ansus (neptunia)]

The same bug in Fedora Bugzilla:
https://bugzilla.redhat.com/show_bug.cgi?id=447252

They marked it low important.

[Simos (simos-redhat-bugs)]

This bug appears to be similar to

keyboard layout switching shortcut doesn't work after reboot
https://bugs.launchpad.net/bugs/196277

Could you please verify that you have enabled autologin on your system?

If this is the case, then it would be better to change the report title to
"Autologin in GNOME disables keyboard layout switching"

[Alexey (alexey-redhat-bugs)]

As i know fedora 9 do not have autologin feature because xserver.1.4.9 do not
support it anymore.

[Angelos Vlassopoulos (avlass)]

Of course they marked it with a low priority (even though medium severity).

If you read at the end of the bug report:

"...official Fedora notes should mention that languages other than English are not fully supported..."

but that's not really the way to make an OS widely accepted, is it?

The world is far bigger than the English speaking countries, and very diverse.

[Simos Xenitellis  (simosx)]

It's not a libklavier bug.

[Ilya (ilya-redhat-bugs)]

You're wrong. It has no GUI for autologin to switch on, but I enabled autologin
through config files.

[Simos Xenitellis  (simosx)]

I am updating now this bug report.

I split the report in two parts; the part that has to do with certain shortcuts not working at all in Hardy (such as Alt+AltGr), is covered at
https://bugs.edge.launchpad.net/ubuntu/+source/xorg/+bug/251443
Please subscribe to that report, if that is the bug that affects you.

In this report we cover the issue where autologin causes the keyboard layout settings in GNOME not to work at all after reboot.

[Simos (simos-redhat-bugs)]

I am not familiar with Fedora; in Ubuntu there is an option in
System/Administration/Login Window/Security/Enable Automatic Login.

What this actually does is it tells GDM to let a specific user in by default.
Essentially, it's a GDM option in Ubuntu.

[Mirza (mirza-seznam)]

> "...official Fedora notes should mention that languages other than
> English are not fully supported..."

Sounds pretty insane to me (for 2008).

Mirza

[Ansus (neptunia)]

>even though medium severity

severity is assigned by the reporter, not developers.

[Ansus (neptunia)]

> Sounds pretty insane to me (for 2008).
To me it seems insane that neither Fedora, nor Ubuntu are tested with languages other than English before the release.

[Simos Xenitellis  (simosx)]

>> Sounds pretty insane to me (for 2008).
> To me it seems insane that neither Fedora, nor Ubuntu are tested with languages other than English before the release.

Ubuntu and Fedora is you and me. I mean, these are community projects, and we are members.
When the alpha/beta versions of Ubuntu and Fedora come up, it's good to try them out in order to catch these bugs early.

Something really good is if someone can verify whether this bug exists in Ibex (Ubuntu 8.10) as well. If so, we can edit the title of the report accordingly.

[Ansus (neptunia)]

This is English-speaking community and those who do not know English cannot participate here and report bugs. Their comments and bugreports probably would be deleted or at best not undersrtood. Russian Ubuntu forums are full with users who cry about these layot problems. There are some fork Ubuntu-based distributions such as Runtu who try to fix these issues (although as far with little success), whith their own Russian-speaking communities.

Besides, as I know this issue was well known before the Hardy release, but the developers considered it unimportant.

[Peter Hutterer (peter-hutterer)]

> --- Comment #2 from Sergey V. Udaltsov <email address hidden> 2008-06-29 11:36:39 PST ---
> It is well-known issue with autologin and startx - X reports XKB configuration
> as being set, but actually it is not.

Sergey:
I'm trying to track this down, can you give me any hints on what to look for
here?
Where (and how) does gnome actually set the xkb configuration at startup?

[Bryce Harrington (bryce)]

[Closing packages so far determined not to be involved]

[Peter (peter-redhat-bugs)]

There are two separate issues here (from what I can tell so far).

One is that the keymap with autologin is different before and after the first
key has been pressed (when the keyboard is evdev anyway).

The other one is that gnome is incapable of setting the xkb map correctly.
Specifying layouts in HAL's fdi file or the xorg.conf works fine, including the
switcher applet.

I'm still trying to figure out why the second happens.

[muadnu (web-cosas)]

Anyway, I think running 'setxkbmap' provides a good enough workaround.
Simply create a script containing "sleep 25 && setxkbmap" and add it to
gnome-session...

On Tue, Jul 29, 2008 at 11:35 AM, Bug Watch Updater <
<email address hidden>> wrote:

> ** Changed in: opensuse
> Status: Unknown => Confirmed
>
> --
> [hardy] With autologin, keyboard layout switching shortcut/settings don't
> work
> https://bugs.launchpad.net/bugs/196277
> You received this bug notification because you are a direct subscriber
> of a duplicate bug.
>
> Status in libxklavier - XKB foundation libary: New
> Status in X.Org X server: Confirmed
> Status in "libgnomekbd" source package in Ubuntu: Invalid
> Status in "libxklavier" source package in Ubuntu: Confirmed
> Status in "xorg" source package in Ubuntu: Invalid
> Status in "xserver-xorg-input-keyboard" source package in Ubuntu: Triaged
> Status in "libgnomekbd" source package in Baltix: New
> Status in Fedora: Unknown
> Status in openSUSE: Confirmed
>
> Bug description:
> (This bug used to cover two separate but similar looking bugs. We split
> them now, and here we describe one of the two bugs. The other bug, Bug
> #251443, has to do with some shortcuts to switch between layouts not
> working. An example is the Alt+AltGr shortcut).
>
> If you enable autologin (it is in the settings, System/Administration/Login
> window/Security/Enable Automatic Login), then any settings about your
> keyboard layout including the shortcut to switch between layouts do not work
> on your next reboot.
>
> In other words, the system ignores any keyboard layout settings that have
> been configured in GNOME.
>
> This issue has been reported upstream (Freedesktop Project), and the link
> is shown above.
>
> A good description of the root of the problem is at this post by Peter
> Hutterer,
> http://lists.freedesktop.org/archives/xorg/2008-July/036947.html
>
> "setting the keyboard without a device flag changes the VCK. On the first
> keypress of a device however this setting is overwritten by the keyboard
> that is actually being used. If you hit a key before gnome sets the keyboard
> layout, the phys. keyboard's settings are already copied into the VCK and
> thus gnome can overwrite them again. consecutive keypresses don't overwrite
> it again, since the phys. keyboard doesn't change.
>
> "The correct solution here is to let gnome set the keyboard settings on
> each physical device they apply to."
>
> A workaround is to run "setxkbmap" (command line utility), which reapplies
> the layout settings in GNOME.
>
> Another workaround is to make a small change in the Keyboard layout
> settings, something that implicitly reapplies the settings from GNOME. For
> example, you can change the order of the layouts, then change them back.
>

[André Pirard (a.pirard)]

I have introduced Bug #253168 because, although it probably shares the same technical roots with the various issues discussed in these 164 messages, not counting duplicates, it comes to practical conclusions and a workaround I didn't find elsewhere.
Practically, as I concluded it, problems occur when you don't type anything at the GDM login. That's (also) the case of "autologin", this bug's title.
My case uses an alternative method for not typing a username + password: GDM page + passwordless login. Which, BTW, applies to more than one user. There are often more than one person in a family ;-)
The difference is that passwordless login can make a halt at the GDM greeting page where an input field is present and that, although no typing is normally requested, one can type some junk in the input field to solve these keyboard issues before clicking.
Given that the GDM greeting page I use can even contain the user's (or users') face(s), it looks very pleasant to the most demanding kinds of users.
I have absolutely no time for writing a complete HOWTO, but my text contains the hardest to find bits and pieces to come to a solution for many related issues.
Sorry, I sympathized with those losing one week time like I did and I must really finish my project in 2 days.
Good luck.

[Timo Aaltonen (tjaalton)]

hm, reconfirming for libxklavier. Someone with better knowledge please clean up the 'affects' list. Somehow it seems to be a bug in xorg-server, though it's not clear yet.

[Peter (peter-redhat-bugs)]

The fix is rather invasive [1]. I made F9 and rawhide packages, if you could
give them a try that would be much appreciated. Please make sure that you can
rollback in case something breaks:

F9 packages are at http://koji.fedoraproject.org/scratch/whot/task_751549/
Rawhide: http://koji.fedoraproject.org/scratch/whot/task_751591/

[1] http://people.freedesktop.org/~whot/patches/xkbfix/

[Simos Xenitellis  (simosx)]

Peter Hutterer posted a patch for this bug,
https://bugzilla.redhat.com/show_bug.cgi?id=447252#c11

See also the thread "[PATCH] xkb fixes" at
http://lists.freedesktop.org/archives/xorg/2008-August/thread.html#37710

[André Pirard (a.pirard)]

On 2008-08-01 15:26, Simos Xenitellis wrote :
> Peter Hutterer posted a patch for this bug,
> https://bugzilla.redhat.com/show_bug.cgi?id=447252#c11
>
In which page I read :
> Could you please verify that you have enabled autologin on your system?
>
> If this is the case, then it would be better to change the report title to
> "Autologin in GNOME disables keyboard layout switching"
And as I showed the problem can occur with passwordless login too and,
as it can affect any option, it would better not.

The title should rather be something like

GNOME login without any keypress prevents the working of
GNOME-configured keyboard options.

In my passwordless login configuration, keyboard switching was working
but it was global instead of local as configured in GNOME. No wonder it
took me more than one week to realize that the conclusions I found on my
own were the same as in this thread.

[Peter (peter-redhat-bugs)]

This problem should be fixed in rawhide with 906-5. Can you please verify this.

[Peter (peter-redhat-bugs)]

*** Bug 440517 has been marked as a duplicate of this bug. ***

[Peter Hutterer (peter-hutterer)]

This should be fixed with the commits leading up to
c06e27b2f6fd9f7b9f827623a48876a225264132.

See also http://lists.freedesktop.org/archives/xorg/2008-August/037710.html

[korvins (katarata)]

I came here by several duplicates ("keyboard layout switching combination does not get saved"), but this is definetely one of the most annyoing bugs for me. Other people have mentioned this bug to me.

Autologin is on, on my system.

[Timo Aaltonen (tjaalton)]

The patches are applied on xorg-server in Intrepid, please test.

[Miloš Mandarić (mandzo18)]

@Intrepid

Autologin is on.

I have two layouts: USA and Bosnia.
Changing layouts works but only in two ways. Through shortcats and by choosing layout from Groups at keyboard indicator. It doesn't work by clicking on the keyboard indicator. The USA layout is always displayed whatever the layout is chosen.

[Miloš Mandarić (mandzo18)]

I confirm this has been fixed in yesterdays update.

[Nickolay (nickolay-redhat-bugs)]

Can you please update F9 packages, this bug is really critical. You have to go to the keyboard settings after every login and set layout switching again and again.

[Francesco Potortì (pot)]

Is there any hope of a backport to Hardy?

[Franco Sirovich (franco-sirovich)]

What kind of LTS would it be if the bug fixing is not "backported"? I
think that we all definitely expect to be fixed!!!
Franco Sirovich

Francesco Potortì wrote:
> Is there any hope of a backport to Hardy?
>
>

[Simos Xenitellis  (simosx)]

I mentioned above that it would be good to thank the person who manages to fix this issue.
That person is Peter Hutterer.

Thank you Peter!

[svaens (svaens)]

Thanks Peter!

On Fri, Sep 5, 2008 at 1:57 AM, Simos Xenitellis <email address hidden>wrote:

> I mentioned above that it would be good to thank the person who manages to
> fix this issue.
> That person is Peter Hutterer.
>
> Thank you Peter!
>
> --
> A GNOME login without keypress dosn't set GNOME keyboard settings
> https://bugs.launchpad.net/bugs/196277
> You received this bug notification because you are a direct subscriber
> of a duplicate bug.
>

[Franco Sirovich (franco-sirovich)]

Thanks Peter!

svaens wrote:
> Thanks Peter!
>
>
> On Fri, Sep 5, 2008 at 1:57 AM, Simos Xenitellis <email address hidden>wrote:
>
>
>> I mentioned above that it would be good to thank the person who manages to
>> fix this issue.
>> That person is Peter Hutterer.
>>
>> Thank you Peter!
>>
>> --
>> A GNOME login without keypress dosn't set GNOME keyboard settings
>> https://bugs.launchpad.net/bugs/196277
>> You received this bug notification because you are a direct subscriber
>> of a duplicate bug.
>>
>>
>
>

[Miloš Mandarić (mandzo18)]

On Thu, 2008-09-04 at 23:57 +0000, Simos Xenitellis wrote:
> I mentioned above that it would be good to thank the person who manages to fix this issue.
> That person is Peter Hutterer.
>
> Thank you Peter!
>

Thanks Peter!

[André Pirard (a.pirard)]

Thanks Peter for the future, and thanks to all the setxkbmap talkers for
the present, especially Bryce Harrington for the exact, precisely
detailed, working procedure which I exported to the much in need Belarus.

[Timo Aaltonen (tjaalton)]

Closing as fixed in Intrepid.

[Timo Aaltonen (tjaalton)]

Closing as fixed in Intrepid. Thanks for testing!

[xlinuks (xlinuks-yahoo)]

The shortcuts to change the keyboard layout like Alt+Shift now do work in Intrepid, but both Alt keys still don't work (at least for me, with last minute updates to Intrepid), but they used to work in the good old times too.

[Francesco Potortì (pot)]

Thank you for fixing this bug.

Again, is there any hope of seeing this fixed in Hardy?

[Michael Nagel (nailor)]

@xlinukx: your problem seems to be more about Bug #251443 (bug has been split)

[Sergey V. Udaltsov (svu)]

Is this bug related to #16364 ?

[Peter Hutterer (peter-hutterer)]

(In reply to comment #7)
> Is this bug related to #16364 ?

sort-of. 16364 describes an xmodmap issue, and xmodmap had the right behaviour already (i.e. apply to all devices instead of just the VCP/VCK).
xkb didn't have this behaviour until c06e27b2f6fd9f7b9f827623a48876a225264132.

16364 was caused by the VCK having a different keymap before the first key is pressed, which would also be an issue for this bug I guess. So this bug depends on 16364, but not the other way round.

[Peter (peter-redhat-bugs)]

xorg-x11-server-Xorg 1.5.0 has been pushed to testing. This update should fix the issues with the keyboard switcher. Can you please verify this?

https://admin.fedoraproject.org/updates/F9/FEDORA-2008-8032

[Fedora (fedora-redhat-bugs)]

xorg-x11-server-1.5.0-1.fc9 has been pushed to the Fedora 9 stable repository. If problems still persist, please make note of it in this bug report.

[Milan (milan-redhat-bugs)]

The bug has been resoved with prior fixes as I'm using xorg-x11-server-Xorg-1.4.99.906-5.fc10.i386 now and I'm fine for some time at most machines. Even that I have problem with &nbsp; produced by space key but only on one machine I have around with the same setup. See bud #460545 for more info.

[Ansus (neptunia)]

Stll does not work in Hardy.

[Սահակ (petrosyan)]

To fix this bug we need to use "Alt+Shift" as default shortcut for keyboard layout switching.

[svaens (svaens)]

what? Do you mean, the fix is to avoid triggering the problem?

On Fri, Oct 10, 2008 at 1:06 AM, Ani <email address hidden> wrote:

> To fix this bug we need to use "Alt+Shift" as default shortcut for
> keyboard layout switching.
>
> --
> A GNOME login without keypress dosn't set GNOME keyboard settings
> https://bugs.launchpad.net/bugs/196277
> You received this bug notification because you are a direct subscriber
> of a duplicate bug.
>

[Սահակ (petrosyan)]

"Alt+Alt" combination can work only after http://bugs.freedesktop.org/show_bug.cgi?id=4927 bug is fixed, which won't happen until xorg-server-1.6 release.

In the meantime we have two choices for Ubuntu 8.10:
1. Ship with broken keyboard layout applet.
2. replace "Alt+Alt" combination with a working shortcut.

[Սահակ (petrosyan)]

Actually I confused this bug with bug 251443

[André Pirard (a.pirard)]

On 2008-10-10 07:09, svaens wrote :
> On Fri, Oct 10, 2008 at 1:06 AM, Ani <email address hidden> wrote:
>> o fix this bug we need to use "Alt+Shift" as default shortcut for
>> keyboard layout switching.
> what? Do you mean, the fix is to avoid triggering the problem
>
It also leaves the keyboard usage documentation costs to Bill :-)

Seriously, I mean this. Double pronged keyboard users like Cyrillic will
tell you they switch between US and their local layout with Shift-Alt.
Anyone "on the street" will, as if it were a hardware feature of the
keyboard.
Why would Linux answer be "whatever your setting is : Gnome ... KDE ...
Xfce ...", change the setting every time for every user you define"?
(fortunately, I myself do that with scripts).
Deciding the mode (US or local) in which the keyboard starts is enough
of a question already.
I went for US because some programs requiring it, like game movement
keys, make a misuse invisible, whereas almost every Cyrillic usage has
visual feedback of the typing.

I found that defining a Cyrillic keyboard is not exactly the easy Ubuntu
setup for everyone.

[Aristotelis Mikropoulos (amikrop)]

I can confirm this bug, on 2 computers, a laptop (DELL Latitude D800) and a desktop, both running Ubuntu Hardy Heron 8.04 LTS.

Personally, I think this bug is very important, because, people who want to make the change from other (proprietary) operating systems, to Linux (and especially Ubuntu), are really discouraged, when they hit on bugs like this. I know this, from facts I have seen with my eyes, and it was very sad.

[el es (el-es-poczta)]

Linux lukasz-laptop 2.6.24-21-generic #1 SMP Tue Oct 21 23:43:45 UTC 2008 i686 GNU/Linux, latest Hardy all the way the updates were offered.

Layouts used : Polish, Esperanto

Symptoms : Keyboard silently uses some different (looking at the description here, US) keyboard layout. The keyboard indicator applet shows the 'default' (in my case, Polish) layout being used.
Left-click on the keyboard indicator, changes the 'Pol' to 'Epo', and back, but no diacritics work.

When right-clicking on the keyboard indicator, select 'show current layout' shows nothing, i.e. empty window appears (all grey, no inner white frame).

This has manifested itself when I enabled automatic login. Without autologin, all worked well.

Executing setxkbmap command fixes this immediately :
- 'show current layout' works,
- diacritics work ąćęłńóśżź, ĉŝĝŭĵĥ.

[Ansus (neptunia)]

This will not be fixed in Hardy. Upgrade to Intrepid if you want support.

[André Pirard (a.pirard)]

Please define LTS.

[svaens (svaens)]

i'll second that question.

[Ansus (neptunia)]

LTS provides only security updates. If you need a non-security bugfix or a new version of software, you should update to a new release.

You would need to update you Xorg version in order to fix this bug.

[André Pirard (a.pirard)]

> LTS provides only security updates.

Under System|Administration|Software Sources|Updates, I read Security,
Recommended ...
Please define Recommended (...)

[korvins (katarata)]

I suppose there is somehow a good reason that makes this bug not fixable easily in 8.04.

If you have bought the right support for Ubuntu, probably you can get an special build just for you with the fix you are requesting.

If you have not, you can try to convince or to understand why it is so hard or so important to fix in 8.04, doing some research before, or at least trying to be nice.

I am not saying that you are not being nice, I am just saying that we should be nice while asking for free support. Otherwise we can just pay, and ask for specialized support. Or try to investigate and do it ourselves.

(I do not work for Ubuntu, I am simply another user who had this problem...)

[Ansus (neptunia)]

You can volunteer and do it yourself.

[Angelos Vlassopoulos (avlass)]

I cannot say if it is easy, hard or impossible to fix in Hardy. I really don't know enough technical stuff.

If it can't be done, or if it's too hard to do it, so be it.

I just want to make sure that the people who decide to fix it or not, understand just how important this issue is for everybody that does not use a Latin character alphabet. It's not just about Greece and Bulgaria, but also about China, Thailand and many other countries.

This bug makes it quite unfit for professional use (e.g. people writing documents in offices).

Furthermore, if I want my business to start using Ubuntu, I would definitely go for the LTS, so I would be able to stick with it for as long as possible. I would not use the latest release for the same reason many businesses do not use Windows Vista (I would assume it's still buggy).

As for paid support, I do not believe anyone should pay for support for a feature that is needed, by half the counties in the world.

Just a user's opinion.

[svaens (svaens)]

Since this has turned into a bit of a chat... I would like to say;
You do strike a note with me, Mr Ansus!

I have been wanting to help for sometime, but never got around to finding
out where begin.
I am a programmer, so i have some skill. But do we have some sort of scheme
whereby the other active developers of Ubuntu do 'peer reviews' on code
another developer wants to introduce, or modify?
If I want to contribute, say if i find a bug, how do i begin?
How do i introduce myself myself to this process. Because you are entirely
right. We can't expect/demand the services of others who are volunteering
their time and efforts.

Please direct me to the person, forum, or whatever where I can introduce
myself and my credentials (such as they are) after which I can learn what
the processes are to contributing to Ubuntu.

Regards,

Sean

[Haggai Eran (haggai-eran)]

I've been using the workaround of running setxkbmap automatically after login for a long time without problems. Perhaps this workaround can be implemented as an update for hardy, and the real Xorg fix remain in Intrepid?
I think it really make no sense that an LTS release won't be usable out of the box for anyone with an extra keyboard layout.

[Ansus (neptunia)]

Svaens, if you feel capable to fix some bug, you can attach a patch which will be reviewed.

[Ansus (neptunia)]

There are somel reports that this bug still exists in Intrepid
http://forum.ubuntu.ru/index.php?topic=40344.0

So I recommend to wait for Jaunty for this bug to be fixed.

[Francesco Potortì (pot)]

>I just want to make sure that the people who decide to fix it or not,
>understand just how important this issue is for everybody that does not
>use a Latin character alphabet. It's not just about Greece and Bulgaria,
>but also about China, Thailand and many other countries.

It also affects people using latin alphabets. So, in fact, everyone
apart from English people.

[Francesco Potortì (pot)]

>I've been using the workaround of running setxkbmap automatically after
>login for a long time without problems. Perhaps this workaround can be
>implemented as an update for hardy, and the real Xorg fix remain in
>Intrepid?

If possible at all, please do!

By the way, I cannot make it work automatically. I have to open a
terminal and write 'setxkbmap' manually each time X starts.

>I think it really make no sense that an LTS release won't be usable out
>of the box for anyone with an extra keyboard layout.

Same here. What's the purpose of LTS if fundamental bugs don't get
corrected? To keep a buggy version alive as long as possible?

[Ansus (neptunia)]

Ubuntu does not fully support languages other than English. If you experience problems with other languages, use English instead.

[Walter (wdoekes)]

> Ubuntu does not fully support languages other than English.
> If you experience problems with other languages, use English instead.

Okay.. so I'll have to switch to Windows whenever I want to write an e-mail to my mom? What?

I respect the fact that a fix won't get into Hardy, but that last comment does not improve understanding.

[Haggai Eran (haggai-eran)]

Francesco, try putting the attached file in ~/.config/autostart.

Haggai

[Arthur (moz-liebesgedichte)]

>> Ubuntu does not fully support languages other than English.
>> If you experience problems with other languages, use English instead.
>
> Okay.. so I'll have to switch to Windows whenever I want to write an e-mail to my mom? What?
>
> I respect the fact that a fix won't get into Hardy, but that last comment does not improve
> understanding.

Ansus doesn't speak for ubuntu, he is a launchpad user like everyone else, so I take his comments with a grain of salt. I don't think it's ubuntu's position to only support English fully. If so, I'm going to change to another distro which does support non-English versions fully (e.g. OpenSUSE).

[Francesco Potortì (pot)]

>Ubuntu does not fully support languages other than English. If you
>experience problems with other languages, use English instead.

Okay, I'll take this as a joke :)

[Ansus (neptunia)]

>I'm going to change to another distro which does support non-English versions fully (e.g. OpenSUSE).

This wouldn't much helpful. This bug also affects SuSE and Fedora (and any other distribution that uses Xorg).

[Franco Sirovich (franco-sirovich)]

Hi All!

Would it be possible to have an official statement by the Ubuntu Distro
on the issues, namely:

   1. Which level of support of national languages is committed to by
      the Ubuntu distro
   2. Which is the precise definition of LTS, and the commitments of to
      it, by the Ubuntu Distro

Not to argue ... simply to know and be aware of it!

Franco

[André Pirard (a.pirard)]

>
> If you have not, you can try to convince or to understand why it is so
> hard or so important to fix in 8.04, doing some research before, or at
> least trying to be nice.
>
I had written an explanatory text that I finally erased in fear of
reading again that this is no place for rambling.
But opinions vary. Well, if I'm asked...

I'm not asking for support. I'm *doing* support of a "community" in
Belarus who received free computers on which I chose to install Ubuntu,
and that's 8.04 right because of its LTS tag. Those poor Чернобыль
victims refrain from spending their few rubles on Internet phone calls.
The main goal of my setting up their Internet connection (not a given
thing) is communication with their Belgian friends and my e-mail
support, after tests on my mirror system.
I don't know a word of russian (well, I did learn a fair amount of
amount of Russian in the process; actually, I might well even be able to
install Russian Windows :-)) but those who know the meaning of the word
Ubuntu can cope with anything with the help of a good словарь. And
Ubuntu was my choice also because of the i18n thing, I can send them
explanations in the form of screen shots in Russian. The one who said "a
picture's worth a thousand words" must have been counting bytes :-)

I was hoping I would be able to extract from 8.04 updates the minimum to
send to Belarus over e-mail to solve their problems. What I'm being told
here is that it's not exactly the meaning of the word "support".
My questions are not particularly focusing on Bug 196277, which was
particularly harmful to them, but fortunately, other Ubuntu lovers
posted a workaround that Belarus applied. I thanked them a lot, but I
will never do it enough.

I usually do not just report bugs, but I analyze the problems deeply
before reporting.
I expect to see someone come, to help him solve the problem, but it
never happened.

One big problem that remains is Bug 202456, an awful behaviour of Wine
on Ubuntu.
Wine is important for Ubuntu. My experience (supporting Belgian users
too) is that many a one regret Windows because some particular
Windows-only program they like is missing. I'm repeatedly solving
Windows integration problems and I found that the best is to package
them in DEBs directly with a front end script taking care of any problem
and, in particular, automatically selecting the language when feasible,
that's often Russian of course :-)
It takes from half an hour work to a few days delay to repackage many
(moderately complex) Windows programs. It's EASY and those who have
experimented that find totally shameful to see distribution Web pages
full of long lists of Windows-only programs when a deb file could exist
right next to them, be it only for anyone to wonder where it's there for
and get interest. The worst is the amazement of the programmer when you
tell him that his program works on Linux, or almost. Especially when he
begins to fancy programming for Linux as well.
Ubuntu-heading people should consider Wine better. From experience, I
call it the Portal to Unix.
Regarding my desire to cooperate, the only answer to 202456 so far is
"have you tested ...

[André Pirard (a.pirard)]

On 2008-12-11 10:12, Ansus wrote :
> Svaens, if you feel capable to fix some bug, you can attach a patch
> which will be reviewed.
>
I suppose that if I had sent my long e-mail sooner, you would no have
dared write this.
Or else, please pull my information and patches out of the trash.

Now I'm reassured that the majority think like me.
Not that I would have changed my mind.

[André Pirard (a.pirard)]

On 2008-12-11 10:21, Ansus wrote :
> Ubuntu does not fully support languages other than English. If you
> experience problems with other languages, use English instead.
>
I suppose that if I had sent my long e-mail sooner, you would no have
dared write this.

This the first message I received from Belarus from a very cheap laptop
that was configured in Belgium an that worked out of the err.. her bag
when she returned (the kiddie had spent much time on it, watching those
H2O series while here).

But of course, it doesn't break anyone's heart.

If you experience problems with other languages, use English instead.

-------- Original Message --------
Subject: привет как дела
Date: Thu, 04 Sep 2008 21:24:15 +0300
From: Daria ...
To: André ...

привет как дела

я очень рада привет всем. Я скоро пришлю новый фильм H2O 3 сезон. Biz

[Haggai Eran (haggai-eran)]

Hi,

I built a new package of x11-xkb-utils that runs setxkbmap on every login (by putting the above .desktop file /etc/xdg/autostart), thus trying to workaround this bug. You can try and download it from my PPA:
https://launchpad.net/~haggai-eran/+archive

Hope it helps,
Haggai

[Adomas (adomasj)]

Tikrai rimta klaida, skubu ja istaisyti, pagal galimybes (dabar net lt raidziu negaliu nadoti) :)

[Francesco Potortì (pot)]

>Francesco, try putting the attached file in ~/.config/autostart.
>
>Haggai
>
>** Attachment added: "Setxkbmap autostart .desktop file"
> http://launchpadlibrarian.net/20360216/setxkbmap.desktop

I had already tried to do this using System / Preferences / Sessions
without any result, so I resorted to do it by hand at a pseudo console
window every time I log in. I will try to use your file when I have
time and let you know the outcome.

[Peter Hutterer (peter-hutterer)]

This should be fixed in master now. We have the same keymap for both MDs and
SDs now, so anything GNOME does on the MD propagates down.

[Bryce Harrington (bryce)]

[This is an automated message]

Hi casselas,

Please attach the output of `lspci -vvnn` too.

[Bryce Harrington (bryce)]

We're closing this bug since it is has been some time with no response from the original reporter. However, if the issue still exists please feel free to reopen with the requested information. Also, if you could, please test against the latest development version of Ubuntu, since this confirms the bug is one we may be able to pass upstream for help.

[Francesco Potortì (pot)]

I have two PC both running Ubuntu 8.10, and I do not observe the bug any
more on any of them.

[Haggai Eran (haggai-eran)]

Bryce: I don't understand why you are closing this bug. True it is fixed in 8.10, but it is not fixed in 8.04, which is still supposed to be supported. Some workarounds have been offered above. Why not use them to fix it in 8.04, or backport the fix from 8.10?
What more information is needed to send upstream?

Haggai

[Franco Sirovich (franco-sirovich)]

I strongly agree with Haggai, keeping in mind that 8.04 is labelled as
Long Term Support: If running a LTS means that for long time you can run
a buggy code... then just let us know!
Thanks,
Franco

Haggai Eran wrote:
> Bryce: I don't understand why you are closing this bug. True it is fixed in 8.10, but it is not fixed in 8.04, which is still supposed to be supported. Some workarounds have been offered above. Why not use them to fix it in 8.04, or backport the fix from 8.10?
> What more information is needed to send upstream?
>
> Haggai
>
>

[Andrew Conkling (andrewski)]

On Wed, Feb 11, 2009 at 05:46, Haggai Eran <email address hidden> wrote:

> Bryce: I don't understand why you are closing this bug. True it is fixed in
> 8.10, but it is not fixed in 8.04, which is still supposed to be supported.
> Some workarounds have been offered above. Why not use them to fix it in
> 8.04, or backport the fix from 8.10?

Someone else can speak for me, but I think a SRU or backport would be the
correct procedure here. Someone would have to approve an SRU (as per the
procedure here: https://wiki.ubuntu.com/StableReleaseUpdates#Procedure), but
if rejected, it can be requested as a backport:
https://help.ubuntu.com/community/UbuntuBackports#How%20to%20request%20new%20packages

Frankly though (and I don't know everything, so don't quote me on this), I
doubt that xorg-xserver would be backported since it's a core package.

[svaens (svaens)]

yes, Or is LTS just a nice sounding lie to get the commericial investors in.

LTS should be what it says. If it is a bug there should be two options
1. If no time and resources OR low priority amongst other higher priority
bugs, postpone fix.
  OR
2. fix

but not ignore because it is fixed in another version.

> Haggai Eran wrote:
> > Bryce: I don't understand why you are closing this bug. True it is fixed
> in 8.10, but it is not fixed in 8.04, which is still supposed to be
> supported. Some workarounds have been offered above. Why not use them to fix
> it in 8.04, or backport the fix from 8.10?
> > What more information is needed to send upstream?
> >
> > Haggai
> >
> >
>
> --
> A GNOME login without keypress dosn't set GNOME keyboard settings
> https://bugs.launchpad.net/bugs/196277
> You received this bug notification because you are a direct subscriber
> of a duplicate bug.
>

[Bryce Harrington (bryce)]

@svaens, please respect the code of conduct, such comments are less than helpful.

> Bryce: I don't understand why you are closing this bug. True it is fixed in
> 8.10, but it is not fixed in 8.04, which is still supposed to be supported.

It is standard to close bugs when they are fixed in the current development version. If it is desired to have the fix for a previous release, you nominate it for that release, which someone has done and I've approved.

> Some workarounds have been offered above. Why not use them to fix it in
> 8.04, or backport the fix from 8.10?

Unfortunately, upstream did not flag a specific patch but a range of patches in which they think the fix might be, and the quantity of code is more than can be easily backported. So someone will first need to go through the changes and narrow it down. In general, the SRU team prefers simple patches with 0 chance of regression; at this point it is not clear whether that will hold true in this case.

What I need someone able to reproduce this bug to do is git bisect the xserver between commits de4936d7482f820728efeef338a2041c7a9186d2 and c06e27b2f6fd9f7b9f827623a48876a225264132 to see exactly which change resulted in the fixed behavior. If you can identify which change resulted in the fix, I can take the action to port the patch for hardy and get it into the xserver.

Meanwhile, I'll look into the feasibility of doing the setxkbmap workaround, but my guess is that it's not going to be acceptable by the SRU team.

> Someone else can speak for me, but I think a SRU or backport would be the
> correct procedure here. Someone would have to approve an SRU (as per the
> procedure here: https://wiki.ubuntu.com/StableReleaseUpdates#Procedure)

This is correct; I can take care of doing this part, if someone can identify the change that fixes it for me.

[Filippo Argiolas (fargiolas)]

I believe Ubuntu Hardy shipped with Dell Mini 9 is also affected by this bug (it uses autologin), at least it is after latest upgrades.
As far as I can tell it worked fine before the upgrades so it could be fixed reverting the change that introduced it, I don't know but maybe it would be easier than going through a SRU to backport upstream patches.

[dj3 (dim-jakobi)]

Yesterday (2009-02-25) I switched back to Hardy from Intrepid. To my suprise, the keyboard switching works after reboot correctly: abcdABCD, абвгАБВГ. I have not been using Hardy for long, so one of the 200 updates might have fixed the problem.
I attach my working xorg.conf. It was (re-)generated by aticonfig via sudo aticonfig --initial -f. Good luck!

[Haggai Eran (haggai-eran)]

dj3: I think the solution using changes to XkbLayout section in xorg.conf was already mentioned above.
Do you think this section was added automatically by aticonfig?

[dj3 (dim-jakobi)]

Haggai Eran: no, the entry XkbLayout shows up in the original xorg-conf as well. I attach the original xorg.conf.

[Michael Terry (mterry)]

Here's a Hardy debdiff for the setxkbmap workaround, to move this bug forward. I'll subscribe ubuntu-sru to see if this is acceptable.

This patch installs a simple .desktop file in /etc/xdg/autostart that calls 'setxkbmap' once the user has logged in. This works around the bug that X doesn't correctly set the keyboard mappings itself.

It's fixed upstream a different way. But backporting it is non-trivial and would involve patching X. This workaround seems like a lower-risk way of fixing it for Hardy.

[Martin Pitt (pitti)]

This workaround looks very intrusive to me. It adds an unconditional new autostart .desktop file, which alters the X session startup sequence and thus is a potential source of regressions.

Also, please consider that GNOME doesn't use X.org's keymap by default, but manages it on its own. As soon as you use setxkbmap with a particular option, you break the keyboard layout applet and the "switch keyboard layout" hotkey. This doesn't *seem* to happen if you call setxkbmap without parameters, but can we be sure that it doesn't berak anything else?

If the workaround is well understood and believed to be correct, can we please call it in gnome-settings-daemon (which handles keyboard layout), instead of adding a completely new conffile and autostart .desktpo file?

[Martin Pitt (pitti)]

I just noticed that calling "setxkbmap" resets the changes of xmodmap. Thus by doing so we'd potentially break xmodmap calls that the user also stuffed into the autostart sequence. So I don't consider this a valid workaround for a SRU.

[Francesco Potortì (pot)]

>I just noticed that calling "setxkbmap" resets the changes of xmodmap.
>Thus by doing so we'd potentially break xmodmap calls that the user also
>stuffed into the autostart sequence. So I don't consider this a valid
>workaround for a SRU.

If a workaround improves the current situation, it is better than no
workaround. Based on my and others' experience, calling setxkbmap
without arguments in fact vastly improves the current situation.

[Ansus (neptunia)]

This improves situation only for speakers of languages other than English. For English speakers it may potentially cause minor regressions. Since most users of Ubuntu speak English as their primary language, introducing potential regressions which may touch them and which could be avoided is not acceptable.

[Martin Pitt (pitti)]

Francesco Potortì [2009-03-09 12:41 -0000]:
> If a workaround improves the current situation, it is better than no
> workaround.

No. Any solution which fixes a major bug, but introduces a small
regression, is unsuitable for a stable update. It is infinitely more
important to not break working things than to fix things which have
never worked in the first place. People adapt to the latter, but
rightfully get very grumpy about the former.

[Francesco Potortì (pot)]

>This improves situation only for speakers of languages other than
>English. For English speakers it may potentially cause minor
>regressions. Since most users of Ubuntu speak English as their primary
>language, introducing potential regressions which may touch them and
>which could be avoided is not acceptable.

Right.

Maybe it is possible for the workaround to be improved, so that it calls
setxkbmap only when it detects a setup with non-English languages.

[Martin Pitt (pitti)]

Ansus [2009-03-09 13:57 -0000]:
> This improves situation only for speakers of languages other than
> English.

This is not a valid criterion for bug fixes, though.

> For English speakers it may potentially cause minor regressions.
> Since most users of Ubuntu speak English as their primary language

This bug is about keyboard layouts, and I doubt that the majority of
users have US keyboards. Even if that were so, we shouldn't decline to
fix a bug just because it "only helps non-English speakers".

I do appreciate that this is an important bug, but fixing it shouldn't
break other things. Apparently it was fixed properly in Jaunty, so I
guess in some way it can be properly fixed in Intrepid.

[antistress (antistress)]

i can confirm that bug with a Dell Mini 9 (inspiron 910) i've just bought, running default Dell-customed-Ubuntu.

Without updates it worked fine
Since i've done an update, i have that bug

Although i'm french, my keyboard is always set on QWERTY on startup instead of AZERTY

The setxkbmap workaround worked for me

I agree with Filippo Argiolas who wrote on 2009-02-26 :

"I believe Ubuntu Hardy shipped with Dell Mini 9 is also affected by this bug (it uses autologin), at least it is after latest upgrades.
As far as I can tell it worked fine before the upgrades so it could be fixed reverting the change that introduced it, I don't know but maybe it would be easier than going through a SRU to backport upstream patches."

I guess that french Dell customers will not be very happy with that situation since mots users don't browse launchpad everyday...

[Brian Chidester (brianchidester)]

Confirmed on Mini 12 and presumably all other Dell Minis

[Christian Funder Sommerlund (zero3)]

This bug unfortunately doesn't seem to be fixed just yet. I'm getting this bug on Ubuntu 9.04 x64 with all updates installed.

[Hurin (auxcri)]

Affected by this bug too.

Hardy Heron 2.6.24-24-generic
Microsoft Ergonomic Keyboard 4000
GDM set to autologin
Right ALT key set to Composite
After reboot or suspend the key doesn't do composite functions any more

setxkbmap workaround sounds buggy as it doesn't seem to be clean when in combination of xmodmap settings.

Waiting for freedesktops-bugs page to announce the VERIFIED fix.

[Jakub Tušan (jjtusan)]

This bug affects me too, I have USA and Slovakia qwerty keyboard, and everytime after restart, system adds "Slovakia" keyboard, so then I have 3 layouts:

1. Usa
2. Slovakia qwerty
3. Slovakia

I have auto-logging turned off !

My key shortcut to switch keyboards works fine even after restart.

[Alex Mayorga (alex-mayorga)]

Is this really fixed?

I do see this bug or a variant on Trusty, please see https://bugs.launchpad.net/ubuntu/+source/xorg/+bug/1408539 and advice.

[Francesco Potortì (pot)]

>Is this really fixed?
>
>I do see this bug or a variant on Trusty, please see
>https://bugs.launchpad.net/ubuntu/+source/xorg/+bug/1408539 and advice.

Sorry, I cannot tell. First, I use really old versions of Ubuntu.
Second, either because of workaraounds that I applied at the time or
because of bugs corrected, I do not observe this problem.