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 ?
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
Created attachment 467545 [details] /etc/kde/kdm/kdmrc
Created attachment 467547 [details] 00-system-setup-keyboard In etc/X11/xorg.conf.d I have just this file
Created attachment 467548 [details] Xorg.0.log
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.
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?
OK 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"
ok, re-assigning and adjusting summary to match reality
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?
Hi.. I have tested some thing: In /etc/sysconfig/keyboard I have that: KEYTABLE="fr-latin9" MODEL="pc105" LAYOUT="fr" VARIANT="latin9" With that, my keyboard don't work in kdm. I replace by: KEYTABLE="fr" MODEL="pc105" LAYOUT="fr" 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 )
Same problem with gdm, keyboard doesn't work, only mouse. When booting in init 3 keyboard works fine.
OK, re-assigning to system-config-keyboard
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.
fixing borked (re)assignment (sorry), nominating as f15blocker
This needs to be fixed in the server, reassigning.
Hi, The keyboard problem still persist after a fresh alpha install...
*** Bug 677164 has been marked as a duplicate of this bug. ***
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 https://fedoraproject.org/wiki/BugZappers
(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
"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!
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.