Bug 661395 - some keyboard options/layouts (set via system-config-keyboard) make gdm/kdm input non-functional
some keyboard options/layouts (set via system-config-keyboard) make gdm/kdm i...
Product: Fedora
Classification: Fedora
Component: xorg-x11-server (Show other bugs)
x86_64 Linux
low Severity medium
: ---
: ---
Assigned To: Peter Hutterer
Fedora Extras Quality Assurance
: Triaged
: 677164 (view as bug list)
Depends On:
Blocks: F15Blocker/F15FinalBlocker F15Blocker-kde
  Show dependency treegraph
Reported: 2010-12-08 13:09 EST by dominique
Modified: 2011-04-18 19:35 EDT (History)
18 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2011-04-18 13:00:01 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)
/etc/kde/kdm/kdmrc (1.53 KB, text/plain)
2010-12-08 13:44 EST, dominique
no flags Details
00-system-setup-keyboard (315 bytes, text/plain)
2010-12-08 13:49 EST, dominique
no flags Details
Xorg.0.log (29.79 KB, text/plain)
2010-12-08 13:53 EST, dominique
no flags Details

  None (edit)
Description dominique 2010-12-08 13:09:05 EST
Description of problem:
This is result of bug  657785
My kdm don't launch and I apply the solution:
In the kdm.log, I also have "unrecognized argument -nr", I remove it from
/etc/kde/kdm/kdmrc and kdm launch

But now my keyboard is inactive in kdm, and I can't loggin (gdm work fine).

In the kdm.log I have this:

Current version of pixman: 0.20.0
	Before reporting problems, check http://wiki.x.org
	to make sure that you have the latest version.
Markers: (--) probed, (**) from config file, (==) default setting,
	(++) from command line, (!!) notice, (II) informational,
	(WW) warning, (EE) error, (NI) not implemented, (??) unknown.
(==) Log file: "/var/log/Xorg.0.log", Time: Wed Dec  8 17:38:06 2010
(==) Using config directory: "/etc/X11/xorg.conf.d"
(==) Using system config directory "/usr/share/X11/xorg.conf.d"
resize called 1440 900
The XKEYBOARD keymap compiler (xkbcomp) reports:
> Internal error:   Could not resolve keysym XF86TouchpadOn
> Internal error:   Could not resolve keysym XF86TouchpadOff
Errors from xkbcomp are not fatal to the X server
The XKEYBOARD keymap compiler (xkbcomp) reports:
> Error:            No Symbols named "latin9" in the include file "us"
>                   Exiting
>                   Abandoning symbols file "default"
Errors from xkbcomp are not fatal to the X server

What I can do ?
Comment 1 Rex Dieter 2010-12-08 13:26:37 EST
I guess you can start by posting your /etc/kde/kdm/kdmrc file as well as any snippets you have in /etc/X11/xorg.conf.d or /usr/share/X11/xorg.conf.d

/var/log/Xorg.0.log wouldn't hurt either
Comment 2 dominique 2010-12-08 13:44:55 EST
Created attachment 467545 [details]
Comment 3 dominique 2010-12-08 13:49:27 EST
Created attachment 467547 [details]

In etc/X11/xorg.conf.d I have just this file
Comment 4 dominique 2010-12-08 13:53:52 EST
Created attachment 467548 [details]
Comment 5 dominique 2010-12-08 13:58:40 EST
In Xorg.0.log I have this two lines:
[   140.296] (**) Option "xkb_layout" "us"
[   140.296] (**) Option "xkb_variant" "latin9"

I think that is the problem.
Comment 6 Rex Dieter 2010-12-08 14:03:20 EST
My thoughts too, mind either removing your custom item from /etc/X11/xorg.conf.d/ and and try re-running system-setup-keyboard to get a fresh one?
Comment 7 dominique 2010-12-08 14:28:25 EST
I remove item from /etc/X11/xorg.conf.d/ and run system-setup-keyboard.
That create a new 00-system-setup-keyboard, but it's same that old one.
And same result, no keyboard with kdm.

I look the new Xorg.0.log and I have same line:
[    32.829] (**) Option "xkb_layout" "us"
[    32.829] (**) Option "xkb_variant" "latin9"
Comment 8 Rex Dieter 2010-12-08 14:45:40 EST
ok, re-assigning and adjusting summary to match reality
Comment 9 dominique 2011-01-16 11:55:20 EST
Today there is always same problem with kdm...
Despite all updates of kde or kdm, I have always this lines in Xorg.0.log

[    64.022] (**) Option "xkb_layout" "us"
[    64.022] (**) Option "xkb_variant" "latin9"

I think of something:
For enable kdm, I create a file "desktop" in etc/sysconfig with content:
DISPLAYMANAGER=KDE (that's work with F14)

In F15, the name of desktop is not kde, but kde-workspaces.
Do you think that is important?
Comment 10 dominique 2011-02-10 01:10:31 EST
I have tested some thing:
In /etc/sysconfig/keyboard I have that:


With that, my keyboard don't work in kdm.

I replace by:

VARIANT="Autre, latin-9 seulement"

And now my keyboard work with kdm, but it is in us and not in fr.

I want launch system-config-keyboard but that don't work (I post a bug here: Bug 676388 )
Comment 11 Nicolas Berrehouc 2011-02-10 08:35:47 EST
Same problem with gdm, keyboard doesn't work, only mouse.
When booting in init 3 keyboard works fine.
Comment 12 Rex Dieter 2011-02-11 09:18:38 EST
OK, re-assigning to system-config-keyboard
Comment 13 Rex Dieter 2011-02-11 09:33:37 EST
Seems related to X and xorg-x11-xkb-utils too it seems, based on a short #fedora-devel irc conversation :

[08:27] <mclasen> rdieter_work: its an X server bug, of sorts
[08:27] <mclasen> has been fixed upstream
[08:27] <mclasen> whats happening is that xkbcomp is erroring out for nonexisting layout/variant combinations
[08:27] <mclasen> and then you end up with an unusable keyboard configuration

so 2-fold, somehow invalid layout/variant combinations end up in /etc/sysconfig/keyboard (system-config-keyboard?) , and when/if that happens, xkbcomp doesn't handle that gracefully.
Comment 14 Rex Dieter 2011-02-11 09:34:42 EST
fixing borked (re)assignment (sorry), nominating as f15blocker
Comment 15 Peter Hutterer 2011-02-13 18:12:04 EST
This needs to be fixed in the server, reassigning.
Comment 16 Raphos 2011-02-18 16:19:40 EST

The keyboard problem still persist after a fresh alpha install...
Comment 17 Martin Naď 2011-02-25 09:49:53 EST
*** Bug 677164 has been marked as a duplicate of this bug. ***
Comment 18 Adam Williamson 2011-04-15 15:17:44 EDT
Discussed at 2011-04-15 blocker review meeting. Given the severe impact of this bug, we accept it per criterion "# Following on from the previous criterion, after firstboot is completed and on subsequent boots, a system installed according to any of the above criteria (or the appropriate Beta or Final criteria, when applying this criterion to those releases) must boot to a working graphical environment without unintended user intervention. This includes correctly accessing any encrypted partitions when the correct passphrase is supplied " and the weasel clause regarding language-specific issues.

However, can we ask for an update here, as no-one's touched this since Feb? Has X been fixed to fall back better? Has s-c-k been fixed to not set bad layouts?

Fedora Bugzappers volunteer triage team
Comment 19 Peter Hutterer 2011-04-17 20:10:12 EDT
(In reply to comment #18)
> However, can we ask for an update here, as no-one's touched this since Feb? Has
> X been fixed to fall back better? 

Yes, the X server has a better fallback now. If the keymap fails to load, the default (in our case "us" is loaded, leaving the user at least with a functional keyboard). Any 1.10 server has this patch included (i.e. F15 has it).

There was another bug in the server that triggered the "us(latin9)" problem of overwriting the layout while maintaining the variant, causing incorrect keyboard layouts. This bugs has been fixed since as well.

> Has s-c-k been fixed to not set bad layouts?

All the actually invalid keyboard layouts I've seen so far were the result of manual editing. If there are invalid layouts actually set by s-c-k, please let me know.

AFAICT this bug is fixed with xorg-x11-server-1.10.0-1.fc15
Comment 20 Adam Williamson 2011-04-18 13:00:01 EDT
"All the actually invalid keyboard layouts I've seen so far were the result of
manual editing. If there are invalid layouts actually set by s-c-k, please let
me know."

I was assuming the 'latin9' stuff was a bad configuration, but it seems not. so, looks like we can close this now. thanks!
Comment 21 Peter Hutterer 2011-04-18 19:35:37 EDT
fr(latin9) is a valid configuration. This was triggered by the second bug mentioned above which replaced "fr" with "us" (which then is an invalid config). said bug is fixed though.

Note You need to log in before you can comment on or make changes to this bug.