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

Bug #196277 reported by Rapolas K. on 2008-02-27
572
This bug affects 32 people
Affects Status Importance Assigned to Milestone
The Dell Mini Project
Undecided
Unassigned
X.Org X server
Fix Released
Medium
libxklavier
Invalid
Undecided
Unassigned
Fedora
Fix Released
Medium
openSUSE
Fix Released
Unknown
libgnomekbd (Baltix)
Undecided
Baltix GNU/Linux system developers
libgnomekbd (Ubuntu)
Undecided
Unassigned
Hardy
Undecided
Unassigned
libxklavier (Ubuntu)
Undecided
Unassigned
Hardy
Undecided
Unassigned
xorg (Ubuntu)
High
Unassigned
Hardy
Undecided
Unassigned
xorg-server (Ubuntu)
High
Unassigned
Hardy
High
Unassigned
xserver-xorg-input-keyboard (Ubuntu)
Undecided
Unassigned
Hardy
Undecided
Unassigned

Bug Description

(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) wrote :

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

pnr (rusyaev-gmail) wrote :

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) wrote :

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

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) wrote :

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

Fabián Rodríguez (magicfab) wrote :

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.

Changed in xorg:
importance: Undecided → High
sibidiba (sibidiba) wrote :

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) wrote :

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) wrote :

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) wrote :

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) wrote :

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) wrote :

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) wrote :

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.

I'm having the same problem exactly.

pnr (rusyaev-gmail) wrote :

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) 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.

  • unnamed Edit (1.7 KiB, text/html; charset=ISO-8859-1)

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.
>
>

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) wrote :

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.

I also have the same issue with layout switching.

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

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

Sergei Genchev (sgenchev) wrote :

 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) wrote :

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.

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

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) wrote :

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) wrote :

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) wrote :

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

Changed in xorg:
status: Confirmed → Incomplete
Oren_B (oren.barnea) wrote :

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) wrote :

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) wrote :

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) wrote :

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) wrote :

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"!!!!!

Changed in xorg:
status: Incomplete → Confirmed
SqUe (sque) wrote :

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) wrote :

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) wrote :

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) wrote :

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) on 2008-04-24
Changed in xkeyboard-config:
status: New → Confirmed
Masoris (masoris) wrote :

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

Masoris (masoris) on 2008-04-25
Changed in libgnomekbd:
status: New → Confirmed
Bryce Harrington (bryce) on 2008-04-27
description: updated
Bryce Harrington (bryce) on 2008-04-27
Changed in xkeyboard-config:
importance: Undecided → High
Changed in xorg:
status: Confirmed → Invalid
description: updated
Bryce Harrington (bryce) on 2008-04-27
description: updated
Changed in xserver-xorg-input-keyboard:
milestone: none → ubuntu-8.04.1
Changed in xorg-server:
status: Unknown → Confirmed
maor (maors) on 2008-05-06
description: updated
216 comments hidden view all 274 comments

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.

Created attachment 305899
screenshot showing the bug

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

Ansus (neptunia) on 2008-06-17
Changed in xorg:
status: Invalid → Confirmed
Bryce Harrington (bryce) on 2008-06-17
Changed in xserver-xorg-input-keyboard:
milestone: ubuntu-8.04.1 → none
status: Confirmed → Triaged
description: updated
Changed in libgnomekbd:
status: Confirmed → Invalid
Changed in libxklavier:
status: New → Confirmed
Changed in xorg-server:
status: New → Invalid
status: Invalid → Unknown
Changed in libxklavier:
status: Unknown → Confirmed
Changed in xorg-server:
status: New → Invalid
Iulian Udrea (iulian) on 2008-07-03
Changed in xorg:
status: Confirmed → Triaged

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

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.

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.

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"

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

Changed in xorg-server:
status: Invalid → Unknown

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

Michael Nagel (nailor) on 2008-07-24
description: updated
description: updated

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.

Changed in xorg-server:
status: Unknown → Confirmed
Bryce Harrington (bryce) on 2008-07-29
description: updated
Changed in xorg:
status: Triaged → Invalid

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.

Timo Aaltonen (tjaalton) on 2008-07-31
Changed in libxklavier:
status: New → Invalid
status: Confirmed → Invalid
status: Invalid → Confirmed

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/

description: updated

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

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

Timo Aaltonen (tjaalton) on 2008-08-13
Changed in xserver-xorg-input-keyboard:
status: Triaged → Incomplete

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.

Timo Aaltonen (tjaalton) on 2008-09-05
Changed in libxklavier:
status: Confirmed → Invalid
Changed in xorg-server:
status: Incomplete → Fix Released

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

Changed in xorg-server:
status: Confirmed → In Progress

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.

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.

Changed in libgnomekbd:
assignee: nobody → adomas-bosanova
status: New → In Progress
Changed in xorg-server:
status: In Progress → Fix Released
Bryce Harrington (bryce) on 2009-01-09
Changed in xserver-xorg-input-keyboard:
status: New → Incomplete
Bryce Harrington (bryce) on 2009-02-11
Changed in xserver-xorg-input-keyboard:
status: Incomplete → Invalid
38 comments hidden view all 274 comments

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) wrote :

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) on 2009-02-18
Changed in libgnomekbd:
status: New → Invalid
Bryce Harrington (bryce) on 2009-02-18
Changed in libxklavier:
status: New → Invalid
Changed in xorg:
status: New → Invalid
Changed in xserver-xorg-input-keyboard:
status: New → Invalid
Bryce Harrington (bryce) wrote :

@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.

Changed in xorg-server:
importance: Undecided → High
status: New → Triaged
Filippo Argiolas (fargiolas) wrote :

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) wrote :

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) wrote :

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) wrote :

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

Michael Terry (mterry) wrote :

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) wrote :

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) wrote :

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.

>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) wrote :

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.

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.

>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.

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.

Changed in libgnomekbd:
assignee: adomas-bosanova → baltix-members
antistress (antistress) wrote :

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...

Confirmed on Mini 12 and presumably all other Dell Minis

Changed in dell-mini:
status: New → Confirmed

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.

Changed in xorg-server (Ubuntu):
status: Fix Released → Confirmed
Hurin (auxcri) wrote :

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.

Changed in dell-mini:
status: Confirmed → Fix Released
Changed in libgnomekbd (Baltix):
status: In Progress → Invalid
Changed in xorg-server (Ubuntu Hardy):
status: Triaged → Invalid
Changed in xorg-server (Ubuntu):
status: Confirmed → Fix Released
Changed in xorg-server:
importance: Unknown → Medium
Changed in xorg-server:
importance: Medium → Unknown
Changed in xorg-server:
importance: Unknown → Medium
Jakub Tušan (jjtusan) wrote :

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) wrote :

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.

>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.

Changed in fedora:
importance: Unknown → Medium
Displaying first 40 and last 40 comments. View all 274 comments or add a comment.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.