Bug 484488

Summary: Xorg uses US keyboard layout
Product: [Fedora] Fedora Reporter: Andrea Cimitan <andrea.cimitan>
Component: gdmAssignee: jmccann
Status: CLOSED NEXTRELEASE QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: urgent Docs Contact:
Priority: low    
Version: 10CC: admin, alan, bochecha, bugzilla, bugzilla, colin, cschalle, dominik, fcdanilo, fschwarz, htl10, jmccann, jval, kcao, lfelipebm, liedekef, matthias_weiss, m.a.young, miles, mishu, nvwarr, ol.morgan, peter.hutterer, phhs80, pjs1, pmatiello, rafaelgomes, raina, rhbugs, richard, rmy, rpm, rstrode, self, simon.andrews, theholyettlz, tmus, toblerone, tore, xgl-maint
Target Milestone: ---   
Target Release: ---   
Hardware: All   
OS: Linux   
Whiteboard:
Fixed In Version: 1.5.3-15.fc10 Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2009-03-13 14:41:47 EDT Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---
Attachments:
Description Flags
xorg.0.log of the non working layout
none
old log, this worked
none
lshal with the downgraded xorg
none
lshal of the broken xorg
none
lshal output on a "broken" system
none
Xorg.log from a "broken" system
none
Xorg.0.log from broken Swedish system
none
lshal from broken Swedish system
none
etc/sysconfig/keyboard from broken Swedish system none

Description Andrea Cimitan 2009-02-07 04:02:52 EST
Description of problem:
Xorg uses the US keyboard layout, ttys are working fine (italian layout)

Version-Release number of selected component (if applicable):
The problem occures with the updates of 2nd february 2009, using update and update-testing repos.

How reproducible:
Everytime.

Additional info:
Through GDM I ve set the right layout, italian, but it doesnt work
Comment 1 Matěj Cepl 2009-02-07 08:23:55 EST
Thanks for the bug report.  We have reviewed the information you have provided above, and there is some additional information we require that will be helpful in our diagnosis of this issue.

Please attach your X server config file (/etc/X11/xorg.conf, if available) and X server log file (/var/log/Xorg.*.log) to the bug report as individual uncompressed file attachments using the bugzilla file attachment link below.

Could you please also try to run without any /etc/X11/xorg.conf (if you have one) whatsoever and let X11 autodetect your display and video card? Attach to this bug /var/log/Xorg.0.log from this attempt as well, please.

We will review this issue again once you've had a chance to attach this information.

Thanks in advance.
Comment 2 Andrea Cimitan 2009-02-07 08:34:16 EST
Created attachment 331194 [details]
xorg.0.log of the non working layout
Comment 3 Andrea Cimitan 2009-02-07 08:35:29 EST
Created attachment 331195 [details]
old log, this worked
Comment 4 Andrea Cimitan 2009-02-08 11:27:16 EST
downgrading xorg-x11-drv-evdev does NOT fix the bug
Comment 5 Andrea Cimitan 2009-02-08 11:53:06 EST
downgrading xorg-x11-server-Xorg FIXES
Comment 6 Peter Hutterer 2009-02-08 18:23:45 EST
what's the output of lshal? The log file looks like hal is telling us to load it with the us layout. In the downgraded one, this isn't the case and the right layout is listed.
Comment 7 Andrea Cimitan 2009-02-08 18:33:00 EST
Created attachment 331258 [details]
lshal with the downgraded xorg
Comment 8 Peter Hutterer 2009-02-08 19:01:41 EST
I need the version that isn't working please.
Comment 9 Andrea Cimitan 2009-02-08 21:24:31 EST
Created attachment 331267 [details]
lshal of the broken xorg
Comment 10 Peter Hutterer 2009-02-09 01:28:19 EST
Confirmed, but on my box this is due to GNOME overwriting the settings on startup.
A plain X server with nothing but xterm has the Italian layout.
I think we've seen this bug before, but I couldn't find the dupe now. 

Anyway, I'm blaming gdm (or control center not sure which one)
Comment 11 Thomas M Steenholdt 2009-02-25 20:17:05 EST
Seeing same problem after updating my F10 system today...

Im using dk layout and these are the xorg related packages that have caused the problem for me - I have not had these problems earlier...

Feb 25 06:01:30 Updated: xorg-x11-server-common-1.5.3-13.fc10.x86_64
Feb 25 06:01:34 Updated: xorg-x11-server-Xorg-1.5.3-13.fc10.x86_64
Feb 25 06:02:10 Updated: xorg-x11-server-devel-1.5.3-13.fc10.x86_64

Please let me know if you need other info.
Comment 12 Susi Lehtola 2009-02-26 05:29:53 EST
*** Bug 484338 has been marked as a duplicate of this bug. ***
Comment 13 Matteo Castellini 2009-02-26 06:05:09 EST
I'm experiencing the very same problems. After some poking around I've notice the introduction of this bug in xorg-x11-server-1.5.3-11.fc10 (in my case xorg-x11-server-Xorg-1.5.3-11.fc10.i386.rpm and xorg-x11-server-common-1.5.3-11.fc10.i386.rpm).

AFAICT this bug is caused by the changes in /usr/share/hal/fdi/policy/10osvendor/10-x11-keymap.fdi (changes made to address bug #484217), reverting to the old version of this file solves it, albeit in a very rough way.
Comment 14 Thomas M Steenholdt 2009-02-26 06:18:08 EST
I noticed that unplugging my USB keyboard and plugging it back in, makes the keymap okay. Of course this is a little tricky with the built-in laptop keyboard, but I thought I would be worth a mention anyway.
Comment 15 Franky Van Liedekerke 2009-02-26 15:14:28 EST
I'm seeing the same problems on all my F10 machines after the latest xorg updates: the login keyboard layout always is US by default (it should be be-maint1 in my case), even the gnome keybaord layout is wrong (unless you set it correct manually in the gnome keyboard preferences, but normally it takes the keyboard layout of the login screen if I'm correct).
Comment 16 Albert69 2009-02-26 15:42:45 EST
never notifyed this problem, but after the yesterday update

Feb 25 19:53:44 Updated: gvfs-1.0.3-5.fc10.i386
Feb 25 19:53:45 Updated: 2:gimp-libs-2.6.5-1.fc10.i386
Feb 25 19:53:46 Updated: libgcrypt-1.4.4-1.fc10.i386
Feb 25 19:54:26 Updated: 2:gimp-2.6.5-1.fc10.i386
Feb 25 19:54:30 Updated: system-config-printer-libs-1.0.15-1.fc10.i386
Feb 25 19:54:31 Updated: 2:gimp-help-browser-2.6.5-1.fc10.i386
Feb 25 19:54:32 Updated: libgcrypt-devel-1.4.4-1.fc10.i386
Feb 25 19:54:33 Updated: gvfs-smb-1.0.3-5.fc10.i386
Feb 25 19:54:33 Updated: gvfs-obexftp-1.0.3-5.fc10.i386
Feb 25 19:54:34 Updated: gvfs-gphoto2-1.0.3-5.fc10.i386
Feb 25 19:54:34 Updated: gvfs-archive-1.0.3-5.fc10.i386
Feb 25 19:54:34 Updated: gvfs-fuse-1.0.3-5.fc10.i386
Feb 25 19:54:46 Updated: stellarium-0.10.1-2.fc10.1.i386
Feb 25 19:55:08 Updated: gstreamer-plugins-good-0.10.13-1.fc10.i386
Feb 25 19:55:09 Updated: 1:wpa_supplicant-0.6.4-3.fc10.i386
Feb 25 19:55:10 Updated: 6:kdelibs-common-4.2.0-15.fc10.i386
Feb 25 19:55:10 Updated: xorg-x11-server-common-1.5.3-13.fc10.i386
Feb 25 19:55:13 Updated: system-config-printer-1.0.15-1.fc10.i386
Feb 25 19:55:13 Updated: fontpackages-filesystem-1.20-1.fc10.noarch
Feb 25 19:55:57 Updated: 6:kdelibs-4.2.0-15.fc10.i386
Feb 25 19:56:00 Updated: xorg-x11-server-Xorg-1.5.3-13.fc10.i386
Feb 25 19:56:01 Updated: rpm-libs-4.6.0-1.fc10.i386
Feb 25 19:56:03 Updated: rpm-4.6.0-1.fc10.i386
Feb 25 19:56:04 Updated: rpm-devel-4.6.0-1.fc10.i386
Feb 25 19:56:05 Updated: rpm-python-4.6.0-1.fc10.i386
Feb 25 19:56:06 Updated: rpm-build-4.6.0-1.fc10.i386
Feb 25 19:56:41 Updated: rpm-4.6.0-1.fc10.i386

today the "it" keyboard is desappeared
regards
Comment 17 Franky Van Liedekerke 2009-02-26 16:57:21 EST
I also confirm comment #13 of this bug: reverting /usr/share/hal/fdi/policy/10osvendor/10-x11-keymap.fdi to the previous version fixes the issue.
Comment 18 Susi Lehtola 2009-02-26 17:38:48 EST
*** Bug 487558 has been marked as a duplicate of this bug. ***
Comment 19 Colin Adams 2009-02-27 06:32:12 EST
I'm having the problem with UK keyboard.
How can I revert?
Comment 20 Albert69 2009-02-27 07:29:46 EST
is not really a solution, but for have again the correct keyboard i added my local one in system..preferences..hw..keyboard, then restart x
Comment 21 Matěj Cepl 2009-02-27 09:55:58 EST
*** Bug 487543 has been marked as a duplicate of this bug. ***
Comment 22 Tim Jackson 2009-02-28 19:05:57 EST
I got this really nasty problem too on my machine with a UK keyboard. To share a few facts/pointers:

- Keyboard layout forced to US.
- For me, changing it in System -> Preferences -> Hardware -> Keyboard has no effect whatsoever. I've tried all kinds of combinations, changed it from "evdev-managed-keyboard" to specific layouts and nothing has any effect.
- Extra badness is that if I have an Xmodmap file loaded, my entire keyboard starts typing as if I was continually holding down AltGr, making the entire system unusable. (I had to rename .Xmodmap to something else via Nautilus and log out, then back in again)

Some things which may help others with this problem:

- Temporary workaround: if you have it installed, run "system-config-keyboard" (as root) and select the relevant keyboard map. It fixes the problem until you reboot. (although it doesn't fix my separate Xmodmap problem)

- To revert to the previous version of the offending software, do this:

a) go to http://koji.fedoraproject.org/koji/buildinfo?buildID=74390

b) check which packages (not specific versions) you have installed from the list available on that page. I had xorg-x11-server-Xorg and xorg-x11-server-common.

c) download the packages corresponding to what you have installed from the above page and install them (rpm -Uvh --oldpackage xorg-x11-server*)

d) reboot.

e) optionally, to stop the bad versions getting downloaded again, add "exclude=xorg-x11-server-*" somewhere within the "[updates]" section of /etc/yum.repos.d/fedora-updates.repo
Comment 23 Morgan Olausson 2009-03-01 01:25:09 EST
Could this issue be related to the introduction of devicekit?
Comment 24 Alex Butcher 2009-03-01 04:32:41 EST
@tim: Alternatively, until an updated xorg-x11-server package is released, modify /usr/share/hal/fdi/policy/10osvendor/10-x11-keymap.fdi; change

<match key="info.capabilities" contains="input.keyboard">

to

<match key="input.xkb.layout" exists="true">
Comment 25 Peter Hutterer 2009-03-01 19:26:56 EST
fell off the CC list there...

All:
If you check the output of lshal, what is the value of input.xkb.layout? Is this the right one (the one from /etc/sysconfig/keyboard)?
If not, please attach the lshal output here.
Comment 26 Thomas M Steenholdt 2009-03-01 20:08:46 EST
Created attachment 333669 [details]
lshal output on a "broken" system

Looking for input.xkb.layout in the lshal output, I get 4 different hits, so i'm posting the entire thing. My system is an HP laptop with no external keyboard, presently attached. My real kb layout is "dk", which matches the last of the four layouts listed in the lshal output. Still - Things do not work correctly after boot. I've found "system-config-keyboard --noui dk" the most useful workaround for me...
Comment 27 Peter Hutterer 2009-03-01 21:13:09 EST
hah. I think I found the issue. can you please attach your Xorg.log too, I think we have a bit of a startup order issue  here.
Comment 28 Thomas M Steenholdt 2009-03-02 04:20:42 EST
Created attachment 333719 [details]
Xorg.log from a "broken" system
Comment 29 Peter Hutterer 2009-03-02 20:25:53 EST
(In reply to comment #26)
> I've found "system-config-keyboard --noui dk" the most useful workaround for me...

wait, you mean you didn't have dk in /etc/sysconfig/keyboard before?
I just talked to mclasen, gdm in F10 gets the layout from exactly there, so if you have "us" in there, it will choose "us" as default.
How did you merge the danish layout? through an fdi file?
Comment 30 Thomas M Steenholdt 2009-03-02 20:32:45 EST
/etc/sysconfig/keyboard has had "dk" in it, all the time. I actually think that gdm works after boot, but things break after login. I'll have to test this again, to make sure.
Comment 31 Peter Hutterer 2009-03-02 20:56:30 EST
this is an issue that has AFAIK been resolved in rawhide. we have different entities fighting over the keyboard control and in F10 at least gdm and gnome are separate and you have to separately configure them. in rawhide, there's extra magic happening to guess the right layout.

F10's gdm should however take the setting from sysconfig.
Comment 32 Thomas M Steenholdt 2009-03-02 21:16:04 EST
Yeah. GDM on this F10 box works fine. My problems start at some point during login...
Comment 33 Peter Hutterer 2009-03-03 20:49:15 EST
Matteo, Alex:
if you have the updated package, does gdm pick the right layout?
is the layout in /etc/sysconfig/keyboard?
does lshal show the right layout for the keyboards?
Comment 34 Morgan Olausson 2009-03-03 23:13:25 EST
Created attachment 333969 [details]
Xorg.0.log from broken Swedish system
Comment 35 Morgan Olausson 2009-03-03 23:15:11 EST
Created attachment 333970 [details]
lshal from broken Swedish system
Comment 36 Morgan Olausson 2009-03-03 23:17:47 EST
Created attachment 333971 [details]
etc/sysconfig/keyboard from broken Swedish system
Comment 37 Morgan Olausson 2009-03-03 23:20:07 EST
Hi, I am from Sweden and I am suffering from this bug that does not allow me to write in my native language. Unfortunately I am kind of a newbie, but with some help, perhaps I can provide necessary printouts.

I guess these questions need printoutanswers:
Do I have the relevant package? What is the packageID ?
If not, how to get it?
Any printouts you need, please tell me how to make them...I want this fixed.
Comment 38 Peter Hutterer 2009-03-03 23:34:34 EST
Morgan:
Looking at the logs, the server loads the right layout. I tried it with german here and gdm loads the right layout (it should display the right language on the bottom when you click on "other").
Once gnome loads, it reverts to whatever was set up in the gnome keyboard properties.
Comment 39 Morgan Olausson 2009-03-04 03:36:37 EST
Thanks Peter Hutterer,
now it works fine again. I have actually never done any Gnome-Keyboard-Settings before, it has just worked, until a week or so back in time. But now that I have gone into System->Preferences->Hardware->keyboard and added my language-layout and deleted the US-one it works as it should again. Thanks once more!
Comment 40 Franky Van Liedekerke 2009-03-04 03:44:35 EST
In my case, the keyboard for the login screen was displayed as being "be-latin1" when in the password dialog screen. However, it was in fact qwerty layout (be-latin1 is an azerty layout). After selecting manually "Belgium" (note that "be-latin1" couldn't be selected) as the keyboard layout, it was azerty and I could type in my password in the usual manner. After a reboot, the same action was needed again ... until I reverted the fdi file like mentioned in coment #13
I must stress that before the xorg update, this was not the case (the keyboard layout was azerty in the password screen dialog of gnome).
Also inside gnome my keyboard settings were changed to US layout, when again they used to be ok upon install. Of course I could change the layout manually in gnome, but that was'nt part of the xorg-update deal I guess ...
(see also my comment #15)

Franky
Comment 41 Matthias Weiss 2009-03-04 06:12:53 EST
(In reply to comment #24)
> @tim: Alternatively, until an updated xorg-x11-server package is released,
> modify /usr/share/hal/fdi/policy/10osvendor/10-x11-keymap.fdi; change
> 
> <match key="info.capabilities" contains="input.keyboard">
> 
> to
> 
> <match key="input.xkb.layout" exists="true">

Fixes my problem too.
Comment 42 Matthias Weiss 2009-03-04 06:22:42 EST
(In reply to comment #39)
> Thanks Peter Hutterer,
> now it works fine again. I have actually never done any Gnome-Keyboard-Settings
> before, it has just worked, until a week or so back in time. But now that I
> have gone into System->Preferences->Hardware->keyboard and added my
> language-layout and deleted the US-one it works as it should again. Thanks once
> more!

I did that too, but after the reboot I had the US keyboard again. In System->Preferences->Hardware->keyboard still was my german keyboard. So I untoggled and toggled the Default button for the german keyboard and it worked afterwards until the next reboot where it was the same problem again.

As mentioned in comment #13 and #24 fixing the fdi file solves this bug.
Comment 43 Matthias Weiss 2009-03-04 06:37:08 EST
(In reply to comment #25)
> fell off the CC list there...
> 
> All:
> If you check the output of lshal, what is the value of input.xkb.layout? Is
> this the right one (the one from /etc/sysconfig/keyboard)?
> If not, please attach the lshal output here.

with the original /usr/share/hal/fdi/policy/10osvendor/10-x11-keymap.fdi file:

lshal | grep input.xkb.model
  input.xkb.model = 'evdev'  (string)
  input.xkb.model = 'evdev'  (string)
  input.xkb.model = 'evdev'  (string)
  input.xkb.model = 'pc105'  (string)

cat /etc/sysconfig/keyboard
KEYBOARDTYPE="pc"
KEYTABLE="de-latin1"
LAYOUT="de"
MODEL="pc105"
OPTIONS=""
VARIANT=""
Comment 44 Matthias Weiss 2009-03-04 06:43:01 EST
(In reply to comment #25)
> fell off the CC list there...
> 
> All:
> If you check the output of lshal, what is the value of input.xkb.layout? Is
> this the right one (the one from /etc/sysconfig/keyboard)?
> If not, please attach the lshal output here.

with the modified /usr/share/hal/fdi/policy/10osvendor/10-x11-keymap.fdi file described in comment #24:

lshal | grep input.xkb.layout
  input.xkb.layout = 'de'  (string)
  input.xkb.layout = 'de'  (string)
  input.xkb.layout = 'de'  (string)
  input.xkb.layout = 'de'  (string)
Comment 45 Albert69 2009-03-04 07:33:10 EST
(In reply to comment #41)
> (In reply to comment #24)
> > @tim: Alternatively, until an updated xorg-x11-server package is released,
> > modify /usr/share/hal/fdi/policy/10osvendor/10-x11-keymap.fdi; change
> > 
> > <match key="info.capabilities" contains="input.keyboard">
> > 
> > to
> > 
> > <match key="input.xkb.layout" exists="true">
> 
> Fixes my problem too.

here sometimes i have only the uk keyboard instead the locale one with that "fix"

only removing all the keyboards and left only the used one seems to work fine (i still have the edited /usr/share/hal/fdi/policy/10osvendor/10-x11-keymap.fdi)

regards
Comment 46 Albert69 2009-03-04 07:35:24 EST
cat /etc/sysconfig/keyboard

KEYBOARDTYPE="pc"
KEYTABLE="it"
LAYOUT="it"
MODEL="pc105"
OPTIONS=""
VARIANT=""


lshal | grep input.xkb.layout

  input.xkb.layout = 'it'  (string)
  input.xkb.layout = 'it'  (string)
  input.xkb.layout = 'it'  (string)
  input.xkb.layout = 'it'  (string)
Comment 47 Jarkko 2009-03-04 08:12:37 EST
I originally commented about this to bug 474276 (comments 3 - 8 there). Downgrading xorg-x11-server-Xorg and xorg-x11-server-common "fixes" the issue (as you've already pointed out here too).

With the latest xorg-x11-server-common-1.5.3-13.fc10.x86_64 and xorg-x11-server-Xorg-1.5.3-13.fc10.x86_64 this issue goes away by editing /usr/share/hal/fdi/policy/10osvendor/10-x11-keymap.fdi as suggested:

----------
change

<match key="info.capabilities" contains="input.keyboard">

to

<match key="input.xkb.layout" exists="true">
----------

So this was just me saying "yes, the suggested fix works for me too". :)
Comment 48 Matteo Castellini 2009-03-04 09:46:18 EST
(In reply to comment #33)
> if you have the updated package, does gdm pick the right layout?

The situation is quite messy, I try to explain it as best as I can:
* When trying to quickly select the username (by typing a few letters) the layout is US.
* When entering the whole username (after clicking on "Other...") gdm correctly picks the IT layout (and shows it on the bottom of the gdm login screen).
* When entering the password gdm still correctly picks the IT layout (and again it is shown on the bottom of the screen).
* After logging in (with GNOME up and running) the layout is US (gnome-keyboard-properties shows it accordingly).
* On any tty the keyboard layout is always set to IT.

> is the layout in /etc/sysconfig/keyboard?

Yes, definitely.
$ cat /etc/sysconfig/keyboard 
KEYBOARDTYPE="pc"
KEYTABLE="it"
LAYOUT="it"
MODEL="pc105"
OPTIONS=""
VARIANT=""

> does lshal show the right layout for the keyboards?

lshal shows correctly "input.xkb.layout = 'it'  (string)" for the keyboard and "input.xkb.layout = 'us'  (string)" for any other button (AFAICT this how it should work).
Comment 49 alan 2009-03-07 06:57:07 EST
Same here plus system-config-keyboard also explodes. Complete mess and how this got out past the original packagers testing is mindboggling

bash-3.2$ system-config-keyboard  uk
Loading /lib/kbd/keymaps/i386/qwerty/uk.map.gz
Traceback (most recent call last):
  File "/usr/share/system-config-keyboard/system-config-keyboard.py", line 65, in <module>
    useCliMode(kbdtype, help)
  File "/usr/share/system-config-keyboard/system-config-keyboard.py", line 47, in useCliMode
    app = keyboard_cli.childWindow(kbdtype, help)
  File "/usr/share/system-config-keyboard/keyboard_cli.py", line 66, in __init__
    keyboardBackend.modifyXconfig(fullname, layout, model, variant, options)
  File "/usr/share/system-config-keyboard/keyboard_backend.py", line 47, in modifyXconfig
    xconfig.layout[0].inputs.insert (xf86config.XF86ConfInputref ("Keyboard0", "CoreKeyboard"));
IndexError: index out-of-bounds

bash-3.2$ xprop -root | grep XKB
_XKB_RULES_NAMES_BACKUP(STRING) = "evdev", "evdev", "us", "", ""
_XKB_RULES_NAMES(STRING) = "evdev", "evdev", "us", "", ""
bash-3.2$ gconftool-2 -R /desktop/gnome/peripherals/keyboard/kbd
 layouts = [uk]
 model = 
 options = []
Comment 50 Luis Felipe Marzagao 2009-03-08 22:14:08 EDT
Same issue here.

[duli@localhost ~]$ xprop -root | grep XKB
_XKB_RULES_NAMES_BACKUP(STRING) = "evdev", "evdev", "us", "", ""
_XKB_RULES_NAMES(STRING) = "evdev", "evdev", "us", "", ""


[duli@localhost ~]$ gconftool-2 -R /desktop/gnome/peripherals/keyboard/kbd
 layouts = []
 model = 
 options = []

[root@localhost ~]# system-config-keyboard --noui br-abnt2
Loading /lib/kbd/keymaps/i386/qwerty/br-abnt2.map.gz
Traceback (most recent call last):
  File "/usr/share/system-config-keyboard/system-config-keyboard.py", line 65, in <module>
    useCliMode(kbdtype, help)
  File "/usr/share/system-config-keyboard/system-config-keyboard.py", line 47, in useCliMode
    app = keyboard_cli.childWindow(kbdtype, help)
  File "/usr/share/system-config-keyboard/keyboard_cli.py", line 66, in __init__
    keyboardBackend.modifyXconfig(fullname, layout, model, variant, options)
  File "/usr/share/system-config-keyboard/keyboard_backend.py", line 47, in modifyXconfig
    xconfig.layout[0].inputs.insert (xf86config.XF86ConfInputref ("Keyboard0", "CoreKeyboard"));
IndexError: index out-of-bounds

After the last command, keyboard is ok. But if a reboot, it will come back to us layout.

Thanks
Comment 51 Fedora Update System 2009-03-09 18:52:27 EDT
system-config-keyboard-1.2.15-5.fc10 has been submitted as an update for Fedora 10.
http://admin.fedoraproject.org/updates/system-config-keyboard-1.2.15-5.fc10
Comment 52 Peter Hutterer 2009-03-09 18:58:18 EDT
Note that the system-config-keyboard update is only for the issues listed in Comments #49 and #50. This is NOT the fix for this bug.

As for the real fix - I don't know, need to wait for a gdm/gnome person to provide some insight.
Comment 53 Morgan Olausson 2009-03-10 12:38:17 EDT
"As for the real fix - I don't know, need to wait for a gdm/gnome person to
provide some insight."

Is the bug filed against right component? How to get the right know-how?
Comment 54 Thomas M Steenholdt 2009-03-10 12:45:27 EDT
Why not simply revert to the previous/working version of /usr/share/hal/fdi/policy/10osvendor/10-x11-keymap.fdi, until such time where the new version can be supported without problems for the user?
I'm all for fast moving development, but IMHO this should have been fixed (even by falling back) a long time ago.
Comment 55 Jarkko 2009-03-10 16:56:27 EDT
> I'm all for fast moving development

Pure development belongs to Rawhide. The released version is not for blind tests. ;)

If you make a change to a released version and something breaks, the change should be reverted when it can't be fixed *right away* with another change. Especially when the change wasn't a fix for any critical issue, but caused one - like what's happened here...
Comment 56 Paul Smith 2009-03-10 17:13:39 EDT
(In reply to comment #55)
> > I'm all for fast moving development
> 
> Pure development belongs to Rawhide. The released version is not for blind
> tests. ;)
> 
> If you make a change to a released version and something breaks, the change
> should be reverted when it can't be fixed *right away* with another change.
> Especially when the change wasn't a fix for any critical issue, but caused one
> - like what's happened here...  

I fully agree with your opinion. Moreover, bugs like this one give to newbies a (wrong) impression of Linux (more precisely, Fedora) inferiority. That is not acceptable that one has to configure the keyboard after every reboot during so many days.

Paul
Comment 57 Fedora Update System 2009-03-10 19:40:21 EDT
xorg-x11-server-1.5.3-15.fc10 has been submitted as an update for Fedora 10.
http://admin.fedoraproject.org/updates/xorg-x11-server-1.5.3-15.fc10
Comment 58 Peter Hutterer 2009-03-10 19:43:04 EDT
Reverted.
Sorry about the mess, I still don't know why this would break on some machines but not others (e.g. mine), but reverting seems to be the best option for now.
Let's hope this same bug doesn't appear in rawhide/F11 (where the hal/xkb/gdm/gnome conflicts are resolved in a slightly different way).
Comment 59 Hin-Tak Leung 2009-03-10 21:18:42 EDT
"me-too" from me - I found this bug# after I noticed it in the rpm change log.

FWIW, my problem seems to be intermittent - it sometimes happens after a suspend/resume or a reboot; I can "fix" it by explicitly setting session preference once I log in again, old gnome terminal doesn't take effect up new one does. 

I think dbus/hal is to blame - I had a look under Xorg.0.log once - although I have gb/uk specified in /etc/X11/xorg.conf and /etc/sysconfig/keyboard (and per-user session preference), it seems that sometimes just out of resume/reboot
hal or dbus gets a bit confused by some of the extra buttons, around the laptop and decide they are keyboards, so I have seen in Xorg.0.log that it sets gb, found another devices, etc and then set to "us".

currently I have these:

$ lshal | grep input.xkb.model
  input.xkb.model = 'evdev'  (string)
  input.xkb.model = 'evdev'  (string)
  input.xkb.model = 'evdev'  (string)
  input.xkb.model = 'pc105'  (string)

I think one is keyoard, one is mouse, another is the laptop lid, and another the power button...

Hope this helps... I am going to put the new rpms on now...
Comment 60 Jarkko 2009-03-11 03:45:50 EDT
$ lshal | grep input.keyboard
  info.capabilities = {'input', 'input.keyboard', 'input.keypad', 'input.keys', 'button'} (string list)

$ lshal | grep input.xkb.model
  input.xkb.model = 'pc105'  (string)
  input.xkb.model = 'pc105'  (string)
  input.xkb.model = 'pc105'  (string)

$ lshal | grep input.xkb.layout
  input.xkb.layout = 'fi'  (string)
  input.xkb.layout = 'fi'  (string)
  input.xkb.layout = 'fi'  (string)

My keyboard does advertise it has the input.keyboard capability, but still it didn't work with: match key="info.capabilities" contains="input.keyboard"

I'm not sure if this was clear or not, so I wanted to mention about this just in case. :) I mean, it's not about whether the system has the input.keyboard capability or not. It has, but this:

<match key="info.capabilities" contains="input.keyboard">

...seems to be false - not true. Why? I don't know, but this is how it is if I've got it right. :)
Comment 61 Fedora Update System 2009-03-11 14:02:30 EDT
xorg-x11-server-1.5.3-15.fc10 has been pushed to the Fedora 10 testing repository.  If problems still persist, please make note of it in this bug report.
 If you want to test the update, you can install it with 
 su -c 'yum --enablerepo=updates-testing update xorg-x11-server'.  You can provide feedback for this update here: http://admin.fedoraproject.org/updates/F10/FEDORA-2009-2620
Comment 62 Fedora Update System 2009-03-13 14:41:35 EDT
xorg-x11-server-1.5.3-15.fc10 has been pushed to the Fedora 10 stable repository.  If problems still persist, please make note of it in this bug report.
Comment 63 Thomas M Steenholdt 2009-03-15 09:11:29 EDT
The updated package fixes this problem on my end. Thanks
Comment 64 Albert69 2009-03-16 12:23:07 EDT
here the same, seems solved, the keyboard layout gnome control panel now runs (and looks) fine too
thanks
Comment 65 Fedora Update System 2009-03-27 10:47:55 EDT
system-config-keyboard-1.2.15-5.fc10 has been pushed to the Fedora 10 stable repository.  If problems still persist, please make note of it in this bug report.
Comment 66 Matteo Castellini 2009-05-06 09:05:09 EDT
AFAICT this problem is still present in rawhide
Comment 67 Omar CHERIF 2009-09-26 07:07:16 EDT
i'm using system-config-keyboard-1.2.15-8.fc11.noarch and currently facing the same problem