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.

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

Thanks in advance.

Created attachment 331198 [details]
xorg.conf as requested

Created attachment 331199 [details]
Xorg log as requested

Are you able to reproduce this using only open source software? I see that you are using nVidia's binary-only driver. I understand that this bug is not primarily about graphic drivers, but unfortunately it is quite possible that some other part of whole Xorg suite of software got changed by installation of nvidia. Please refer to https://fedoraproject.org/wiki/Xorg/3rd_Party_Video_Drivers and clean your system to the original Fedora state, which we can support.

Then, please regenerate and re-attach X server log file (/var/log/Xorg.*.log; don't use any /etc/X11/xorg.conf for this testing) to the bug report.

Thanks in advance.

(In reply to comment #0)
> [fidepus@FUCKUP ~]$ gconftool-2 -R /desktop/gnome/peripherals/keyboard/kbd
>  layouts = [de-latin1-nodeadkeys]
>  model = 
>  options = []

What keyboard layout do you want to activate here? I can't find any such layout, neither in the gnome config, nor in xkeyboard-config.

Same problem here : 

$ xprop -root | grep XKB
_XKB_RULES_NAMES_BACKUP(STRING) = "evdev", "evdev", "us", "latin9", ""
_XKB_RULES_NAMES(STRING) = "evdev", "evdev", "fr-latin9", "", ""


$ gconftool-2 -R /desktop/gnome/peripherals/keyboard/kbd
 layouts = [us	latin9,fr]
 model = pc105
 options = [grp	grp:shift_caps_toggle]

this problem is since recent updates and if i remember well there a xorg one.

same problem after update :

$ xprop -root |grep XKB
_XKB_RULES_NAMES_BACKUP(STRING) = "evdev", "evdev", "us", "latin9", ""
_XKB_RULES_NAMES(STRING) = "evdev", "evdev", "fr-latin9", "", ""

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

this seems to be a gnome problem. there's no us-latin9 keyboard, somehow the gconf keys seem to get mixed up.

does this happen with a test user?

This also happens with freshly installed rawhide:
[julas@rawhide ~]$ xprop -root | grep XKB
_XKB_RULES_NAMES_BACKUP(STRING) = "evdev", "evdev", "us", "", ""
_XKB_RULES_NAMES(STRING) = "evdev", "evdev", "pl", "", ""
[julas@rawhide ~]$ gconftool-2 -R /desktop/gnome/peripherals/keyboard/kbd
 layouts = [pl_PL.UTF-8]
 options = []
 model =

Same here, on a fresh rawhide installation, I don't have any xorg.conf


Error activating XKB configuration.
It can happen under various circumstances:
- a bug in libxklavier library
- a bug in X server (xkbcomp, xmodmap utilities)
- X server with incompatible libxkbfile implementation

X server version data:
The X.Org Foundation
10600000

If you report this situation as a bug, please include:
- The result of xprop -root | grep XKB
- The result of gconftool-2 -R /desktop/gnome/peripherals/keyboard/kbd

----------------------------------------------------
$ xprop -root | grep XKB
_XKB_RULES_NAMES_BACKUP(STRING) = "evdev", "evdev", "us", "", ""
_XKB_RULES_NAMES(STRING) = "evdev", "evdev", "pt", "", ""
---------------------------------------------------------
$ gconftool-2 -R /desktop/gnome/peripherals/keyboard/kbd
 layouts = [en_US.UTF-8]
 options = []
 model =

Created attachment 335099 [details]
Xorg.0.log

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

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

Should be fixed with the latest gdm (2.26.0-6.fc11) for *new* users.  Existing users will still be hosed.

The way to clean it up is sort of gross:

su -c "gconftool-2 --config-source=xml:readwrite:/var/lib/gdm/.gconf --unset /apps/gdm/simple-greeter/recent-layouts --direct"
rm -f ~/.dmrc
gconftool-2 --recursive-unset /desktop/gnome/peripherals/keyboard/kbd

Need to figure out if there's a way I can do that automatically.

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

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

(In reply to comment #14)

> Should be fixed with the latest gdm (2.26.0-6.fc11) for *new* users.  Existing
> users will still be hosed.

Nope. I cannot confirm that it's working for *new* users.
gdm-2.26.0-7.fc11.i586 on a fresh rawhide scratch installation.

Same message appears on first login.

[andreas@workstation ~]$ xprop -root | grep XKB
_XKB_RULES_NAMES_BACKUP(STRING) = "evdev", "evdev", "us", "nodeadkeys", ""
_XKB_RULES_NAMES(STRING) = "evdev", "evdev", "de", "", ""
[andreas@workstation ~]$ gconftool-2 -R /desktop/gnome/peripherals/keyboard/kbd
layouts = []
options = []
model = 
[andreas@workstation ~]$ 

> The way to clean it up is sort of gross:
> 
> su -c "gconftool-2 --config-source=xml:readwrite:/var/lib/gdm/.gconf --unset
> /apps/gdm/simple-greeter/recent-layouts --direct"
> rm -f ~/.dmrc
> gconftool-2 --recursive-unset /desktop/gnome/peripherals/keyboard/kbd

Doesn't fix the problem. The message appears nevertheless as soon as control
is passed from gdm to the normal user session.

Still not fixed with rawhide as of 20090408, neither with deleting the kbd configuration for existing users nor for new users.

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

Having additionally the problem that the nodeadkeys switch does not operate correctly: the handling of "|@[]" on a german nodeadkeys keyboard  is correct, but I have to type the tilde character "~" twice and not once.

(In reply to comment #20)
> Having additionally the problem that the nodeadkeys switch does not operate
> correctly: the handling of "|@[]" on a german nodeadkeys keyboard  is correct,
> but I have to type the tilde character "~" twice and not once.  

Confirmed. Same here.
|@[] are not deadkeys, ~´`^ are.

You are right ;-)

Weird: My keyboard model is "Generic 101-key PC" with USA layout (installed by anaconda as a "german/nodeadkeys" keyboard) , but it functions as it would be a german keyboard (umlauts äöü or s sharp ß are right). But if I switch by System->preferences->keyboard to "Germany Eliminate dead keys" by using the +ADD button in the "Keyboard Preferences" window instead of USA, then AltGr does no more function: getting only + sign instead of ~, or getting no ^ char.

Got rid from all described problems after updating my system on monday, april 13.

Now my keyboard controls:

Keyboard model: Generic 101-Keys PC
Layout: Only "Germany Eliminate dead keys" added and selected. (No more USA layout needed).

The AltGr, tilde (~) and the ^ key now work correctly.

(In reply to comment #23)

> Got rid from all described problems after updating my system on monday, april
> 13.
> 
> Now my keyboard controls:
> 
> Keyboard model: Generic 101-Keys PC
> Layout: Only "Germany Eliminate dead keys" added and selected. (No more USA
> layout needed).
> 
> The AltGr, tilde (~) and the ^ key now work correctly.  

Did you set this manually in the configuration tool or was it autodetected?

If you set it manually, it works but can be considered a workaroung. It should be set automatically.

No, I set it manually (I didn't try a Fc11 re-install).

with rawhide updated for today, after applying above command to reset config, still have the same error message.

To fix the problem for an existing user I had to delete directory
  ~/.gconf/desktop/gnome/peripherals/keyboard .

Problem is still happening on a new rawhide installation, setting F11Blocker

After a fresh install from current "rawhide", I do obtain multiple instances of the "Error activating XKB configuration." error window. During install, I had chosen a keyboard layout "German w/o dead keys" for a German PS/2 keyboard attached to an IBM ThinkPad T23. Furthermore, I get:

$ xprop -root | grep XKB
_XKB_RULES_NAMES_BACKUP(STRING) = "evdev", "evdev", "us", "nodeadkeys", "terminate:ctrl_alt_bksp"
_XKB_RULES_NAMES(STRING) = "evdev", "evdev", "de", "", ""

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

Did you select a layout on the login screen ? 
What does

echo $GDM_KEYBOARD_LAYOUT 

show in this situation ?

And what about

lshal | grep xkb ?

de_AT.UTF-8

  input.xkb.layout = 'us'  (string)
  input.xkb.model = 'evdev'  (string)
  input.xkb.rules = 'base'  (string)
  input.xkb.variant = ''  (string)
  input.xkb.layout = 'us'  (string)
  input.xkb.model = 'evdev'  (string)
  input.xkb.rules = 'base'  (string)
  input.xkb.variant = ''  (string)
  input.xkb.layout = 'de'  (string)
  input.xkb.model = 'pc105'  (string)
  input.xkb.options = 'terminate:ctrl_alt_bksp'  (string)
  input.xkb.rules = 'base'  (string)
  input.xkb.variant = 'nodeadkeys'  (string)

The issue stops by adding a German keyboard layout by means gnome-keyboard-properties, setting it to be the default one and removing the US layout which was the only one displayed in "Selected Layouts" although the system layout was "German w/o dead keys".

But we can't keep asking people to fix their keyboard layouts. This is what? The third time this has happened? It should just work.

To make sure that it just works, you need to help identify what is different in your setup that makes this happen to you, since it does not happen here.

Of course. But as soon as I implement the workaround of reconfiguring my keyboard, you lose that information. So what do you need to know?

Setting the severity to high.

There have been several reports of this triggering F11 preview release users on IRC.

Can you try if http://koji.fedoraproject.org/koji/buildinfo?buildID=100317 
makes any difference ?

After updating to gnome-settings-daemon-2.26.1-4.fc11, the issue does not appear for a new user anymore.

I can confirm that, after updating to gnome-settings-daemon-2.26.1-4.fc11, the issue does not appear for a new user anymore (nor does it for old users). I'm using an fr_CH keyboard layout.

Ok, I'll take this as sufficient proof that things are fixed.

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

I can also confirm that this fixed it on french install + keyboard both for new users and for existing users.