Bug 484488

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.

Created attachment 331194 [details]
xorg.0.log of the non working layout

Created attachment 331195 [details]
old log, this worked

downgrading xorg-x11-drv-evdev does NOT fix the bug

downgrading xorg-x11-server-Xorg FIXES

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.

Created attachment 331258 [details]
lshal with the downgraded xorg

I need the version that isn't working please.

Created attachment 331267 [details]
lshal of the broken xorg

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)

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.

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

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.

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.

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

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

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.

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

I'm having the problem with UK keyboard.
How can I revert?

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

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

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

Could this issue be related to the introduction of devicekit?

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

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.

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

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.

Created attachment 333719 [details]
Xorg.log from a "broken" system

(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?

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

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.

Yeah. GDM on this F10 box works fine. My problems start at some point during login...

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?

Created attachment 333969 [details]
Xorg.0.log from broken Swedish system

Created attachment 333970 [details]
lshal from broken Swedish system

Created attachment 333971 [details]
etc/sysconfig/keyboard from broken Swedish system

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.

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.

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!

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

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

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

(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=""

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

(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

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)

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

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

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 = []

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

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

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.

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

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.

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

(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

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

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

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

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

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

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.

The updated package fixes this problem on my end. Thanks

here the same, seems solved, the keyboard layout gnome control panel now runs (and looks) fine too
thanks

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.

AFAICT this problem is still present in rawhide

i'm using system-config-keyboard-1.2.15-8.fc11.noarch and currently facing the same problem