Created attachment 295732 [details]
Xorg.log

Created attachment 295733 [details]
xorg.conf

Same problem here. The issue seems to be that Xorg now automatically loads the
evdev driver for the keyboard. This is all fine and dandy except for two things:

1. It kills the kbd driver, which is the one that has a proper layout setting in
xorg.conf.

2. The default for evdev is hard coded into the driver, so you can't tell it
that all keyboards will have layout "foo".

3. Gnome has a bug where it doesn't reapply the configured layout on login.
(this would not solve the issue though as every user would have to change their
layout, and GDM would still have the wrong one).

I guess that was three things. I blame the lack of caffeine ;)

Did a bit more digging and found the problem.

Xorg now uses hal to detect input hardware. And it also expects hal to provide
proper information about the keyboard layout. Unfortunately, Fedora ships an fdi
with the following>

      <merge key="input.xkb.layout" type="string">us</merge>

(file in question is /usr/share/hal/fdi/policy/10osvendor/10-keymap.fdi)

This is of course very bad and it should be doing some callout to read
/etc/sysconfig/keyboard.

sounds like we need davidz, hal superhero.. added to CC

Ah, that explains why I don't have this problem, because my keyboard happens to
be US.

But I have noticed that Ctrl-Alt-F[1-6] does no longer work (and neither does
Ctrl-Alt-Backspace). Is that related?

I have the same problem with control-alt-whatever along with my mouse not 
working correctly.  I do believe hal is involved in all of this some way as 
someone already mentioned.  I believe my gnome-sessions problem is due to this 
as well maybe, but could be another bug.

I'd say most/all of these problems are caused by the fact that X now uses the
evdev driver instead of kbd. So they're all probably latent bugs that nobody
notices because so few uses evdev.

It's probably best to open separate bugs for each problem. If it turns out to be
the same they can always be closed as DUPLICATE.

no control or alt keys. Adding to cc.

Section "InputDevice"
	Identifier  "Keyboard0"
	Driver      "kbd"
	Option	    "XkbModel" "pc105"
	Option	    "XkbLayout" "us+inet"

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

(In reply to comment #6)
> sounds like we need davidz, hal superhero.. added to CC

You want hughsie instead. I don't really know how the whole keymap quirk thing
is supposed to work.

Further testing shows that hal is not entirely to blame. Even if I get hal to
produce the right data, X does the wrong thing. So David or Richard, the issue
in hal should probably be moved to a separate bug.

As for X, it is completely determined to use the us layout. If I remove the
keyboard configuration from xorg.conf and let it rely completely on hal, I get this:

[root@mjolnir log]# grep -i layout Xorg.0.log
(==) ServerLayout "Default Layout"
(==) The core keyboard device wasn't specified explicitly in the layout.
(**) Option "XkbLayout" "us"
(**) <default keyboard>: XkbLayout: "us"
(**) Option "xkb_layout" "se"

Layout in X is us. So I put the keyboard config back in case the default setting
trumps the hotplugged device. Now I get this:

[root@mjolnir log]# grep -i layout Xorg.0.log
(==) ServerLayout "Default Layout"
(**) Option "XkbLayout" "se"
(**) Keyboard0: XkbLayout: "se"
(**) Option "xkb_layout" "se"

Layout in X is still us. So something is seriously broken when it comes to
layout handling.

I don't think it's just that it's choosing US erroneously. I've got a US
keyboard (perfectly generic, but IBM brand) and it's not working right either
(Down arrow is mapped to multi_key, for example.)

WorkARound is reverting to previous release. Assuming keepcache=1 in /etc/yum.conf

# cd /var/cache/yum/development/packages
# rpm -Uvh --force xorg-x11-server-common-1.4.99.1-0.19.20080107.fc8.x86_64.rpm
xorg-x11-server-Xorg-1.4.99.1-0.19.20080107.fc8.x86_64.rpm

Ajax is sacrificially taking blame for this ;-).

ctrl-alt not working is different from the other issues. See
http://freedesktop.org/bugzilla/show_bug.cgi?id=14584.

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

See https://www.redhat.com/archives/fedora-devel-list/2008-February/msg02131.html

Comment 19 only goes so far, the xorg.conf file needs tweaking for evdev. But
adding:   

  Section "InputDevice"
        Identifier  "Keyboard0"
        Driver      "evdev"
        Option      "evBits"  "+1"
        Option      "keyBits" "~1-255 ~352-511"
        Option      "Pass"    "3"
  EndSection

as evdev(4) suggests gives working X, but that crashes as soon as a key is pressed.

Strangely enough, apart from the Ctrl-Alt-Problem, my keyboard works as it
should, with both config styles (xkb and evdev).

More testing:

1. Disabling HAL stuff using "AutoAddDevices", "kbd" in xorg.conf:

Swedish layout is somewhat applied. It seems all buttons that do not exist in
"us" are ignored (e.g. åäö and AltGr). KeyPress events are sent with the correct
keycode, but with 0x0 as keysym.

"AllowEmptyInput" has no effect here (as expected).

2. Enable "AllowEmptyInput" and remove stuff in xorg.conf:

"us" layout without any regard for what hal reports.

Also, under 1 Ctrl+Alt+Backspace works, but not Ctrl+Alt+Fn. Under 2, neither work.

Could somebody please post a full set of _working_ configuration files? The
hints in comment 19 just aren't enough to get functional X here (nVidia, Nouveau
driver, Spanish layout on a Toshiba keyboard).

Also, my /usr/share/hal/fdi/policy/10osvendor/10-keymap.fdi (from
hal-0.5.10-5.fc9.i386, installed 20080215) has no line like the one mentioned in
comment 5.

Thanks!

The point is it shouldn't *NEED* configuration files.

(In reply to comment #24)
> 
> Also, my /usr/share/hal/fdi/policy/10osvendor/10-keymap.fdi (from
> hal-0.5.10-5.fc9.i386, installed 20080215) has no line like the one mentioned in
> comment 5.

Odd, that's the same version I have here. And the files are not locally modified:

[root@mjolnir ~]# rpm -V hal
[root@mjolnir ~]# grep us /usr/share/hal/fdi/policy/10osvendor/10-keymap.fdi
      <!-- If we're using Linux, we use evdev by default (falling back to
      <merge key="input.xkb.layout" type="string">us</merge>


(In reply to comment #25)
> The point is it shouldn't *NEED* configuration files.

Well, unless keyboard hardware has changed drastically, there's no way to probe
the layout of it from software. But if you mean that no further configuration
than /etc/sysconfig/keyboard should be needed, then I fully agree.

OK, I deleted the xorg.conf file for kicks. Now CapsLock is Ctrl, Ctrl is
non-functional (!). The arrow keys don't work, AltGr does nothing.

Sorry, the above is after system-config-keyboard'ing it to Spanish

I use a japanese keyboard as follows.
 Microsoft Natural Ergonomic Keyboard 4000 v1.0 USB type
I have experienced a same problem.
Xkbmodel --- jp106
Xkblayout --- jp
arch --- i386

Is the evdev driver needed for xorg-x11-server-common-1.4.99.1-0.23.20080222.fc9 ? 

Still having problems with this as don 't see any fix comments.

Should be fixed in xorg-x11-server-1.4.99.900-0.27.20080303.fc9.

Just loaded xorg-x11-server-Xorg-1.4.99.900-0.28.20080304.fc9 and it definitely
is not working properly. My up-arrow now acts like the Print Screen key.
xorg.conf was generated by system-config-display:

Section "InputDevice"
	Identifier  "Keyboard0"
	Driver      "kbd"
	Option	    "XkbModel" "pc105"
	Option	    "XkbLayout" "us+inet"
EndSection

Unfortunately xorg-x11-server-1.4.99.900-0.27.20080303.fc9 doesn't work for me
either.

xorg.conf:
Section "InputDevice"
        Identifier  "Keyboard0"
        Driver      "kbd"
        Option      "XkbModel" "pc105"
        Option      "XkbLayout" "de"
        Option      "XkbVariant" "nodeadkeys"
EndSection

/etc/sysconfig/keyboard:
KEYBOARDTYPE="pc"
KEYTABLE="de-latin1-nodeadkeys"

When I run startx I get the "us" layout but when I use
System->Administration->Keyboard and change the keyboard from German to
something else and back again I actually get the "de" layout in gnome-terminal.
However AltGr acts as <enter> and the arrow keys don't work at all. Also after
restarting X I'm back with the "us" layout again.

Further testing (follow-up to Comment #33):
Go to System>Preferences>Personal>Keyboard>Shortcuts
Change shortcut for "Take a screenshot of a window" to Ctrl+Up
Close
Up-arrow now works properly, so
Go to System>Preferences>Personal>Keyboard>Shortcuts
Change shortcut for "Take a screenshot of a window" to Ctrl+Print
Close
keyboard seems to be working properly

Don't know if it matters if it does NOT work, but do you need
xorg-x11-server-common or whatever as well?

(In reply to comment #35)
> Don't know if it matters if it does NOT work, but do you need
> xorg-x11-server-common or whatever as well?

The server package depends on it so yes you need it. Yum takes care of that though.

(In reply to comment #32)
> Just loaded xorg-x11-server-Xorg-1.4.99.900-0.28.20080304.fc9 and it definitely
> is not working properly. My up-arrow now acts like the Print Screen key.

As already written up-arrow = PrintScreen is new xorg's way of telling you you
should configure evdev+evdev instead of kbd+pc105,jp106 or whatever

See comment #19

(In reply to comment #37)
> (In reply to comment #32)
> > Just loaded xorg-x11-server-Xorg-1.4.99.900-0.28.20080304.fc9 and it definitely
> > is not working properly. My up-arrow now acts like the Print Screen key.
> 
> As already written up-arrow = PrintScreen is new xorg's way of telling you you
> should configure evdev+evdev instead of kbd+pc105,jp106 or whatever
> 
> See comment #19

And the problem with that reply is that this misconfiguration happens on every
box by default on upgrade. It's a problem.

(In reply to comment #38)

> And the problem with that reply is that this misconfiguration happens on every
> box by default on upgrade. It's a problem.

It's been complained on regularly for at least a year upstream, and no input dev
ever proposed a way to ease the transition, so don't hold your breath on it
happening now. I fear it's going to be a case of "fix configs manually or via a
brutal script" instead of expecting xorg to be smart.

Then we should set the release note flag so that such a change can be documented
and procedures for making the transition can be on the wiki come release - just
so we don't have to deal with a million users plopping in their shiny new F9
DVD, using the upgrade option and complain about how Fedora totally fucked their
setup. 

If this goes to F9 release and most users who upgrade their system, then reboot, cannot use ALT to get 
from GDM to VT1 that constitutes a major screwup... not something for a release note.  I would think a 
method of transition should be in place even its its totally blowing off their xorg.conf and generating a 
new one using evdev.

I am unsetting the release note request for now. In most such cases, we would
want to fix the software rather than documenting workarounds. If Xorg developers
are not able to fix the underlying problems before RC, we can reconsider this.
Till then, continue providing feedback and keep testing updates.  

I can confirm that the new update solves the issue (provided the configuration
is correct).

I've opened bug 436090 to fix HAL.

(In reply to comment #41)
> If this goes to F9 release and most users who upgrade their system, then
reboot, cannot use ALT 

The alt problem was a bug (xorg not behaving as designed). As Ajax noted it
should be fixed in the xorg that just landed in rawhide.

The "up-arrow" = "PrintScreen" is xorg misbehaving in an invalid configuration
that happens to be the one most people migrating from previous versions land
with but remains an invalid config upstream tells you not to use and does not
support.

(the argument being that someday other evdev-compatible keyboard models than
"evdev" may be defined, so forcing the "evdev" model when the "evdev" driver is
used is wrong)

(In reply to comment #43)
> I can confirm that the new update solves the issue (provided the configuration
> is correct).
> 
> I've opened bug 436090 to fix HAL.

can somebody explain what to do and how do I see that my configuration file i
scorrect???

With today's update Xorg -configure gives me the following in xorg.conf

Section "InputDevice"
  Identifier  "Keyboard0"
  Driver      "kbd"
EndSection

which still requires fixing.

(In reply to comment #45)
> 
> can somebody explain what to do and how do I see that my configuration file i
> scorrect???

You modify the file /usr/share/hal/fdi/policy/10osvendor/10-keymap.fdi. Change
the line with "xkb.layout" from "us" to whatever layout you want. Then restart
your machine.

CTL-ALT-F1 takes me to a terminal. It also opens up help for the application
that was in the forefront before the switching.
When I change back to the GUI with the F7 key, help is open. I tried that test
twice with the same results.

Created attachment 296973 [details]
This is xorg.log with current session where ctl-alt-f1 followed by f7 tried

(In reply to comment #47)
> You modify the file /usr/share/hal/fdi/policy/10osvendor/10-keymap.fdi. Change
> the line with "xkb.layout" from "us" to whatever layout you want. Then restart
> your machine.

I tried this but it makes no difference.

[dennis@nexus ~]$ lshal |grep xkb
  input.xkb.layout = 'de-latin1-nodeadkeys'  (string)
  input.xkb.model = 'evdev'  (string)
  input.xkb.rules = 'base'  (string)
  input.xkb.variant = ''  (string)

(In reply to comment #50)
> (In reply to comment #47)
> > You modify the file /usr/share/hal/fdi/policy/10osvendor/10-keymap.fdi. Change
> > the line with "xkb.layout" from "us" to whatever layout you want. Then restart
> > your machine.
> 
> I tried this but it makes no difference.
> 
> [dennis@nexus ~]$ lshal |grep xkb
>   input.xkb.layout = 'de-latin1-nodeadkeys'  (string)
>   input.xkb.model = 'evdev'  (string)
>   input.xkb.rules = 'base'  (string)
>   input.xkb.variant = ''  (string)
> 

Odd. Works fine here, but I'm not using such a complex layout string:

[drzeus@mjolnir]$ lshal | grep xkb
  input.xkb.layout = 'se'  (string)
  input.xkb.model = 'evdev'  (string)
  input.xkb.rules = 'base'  (string)
  input.xkb.variant = ''  (string)

My bad. I bluntly copied the value from /etc/sysconfig/keyboard into the layout
field. When looking at this again after getting a bit of sleep I spotted the
mistake and fixed it: 

[root@nexus drivers]# lshal |grep xkb
  input.xkb.layout = 'de'  (string)
  input.xkb.model = 'evdev'  (string)
  input.xkb.rules = 'base'  (string)
  input.xkb.variant = 'nodeadkeys'  (string)

Now X runs perfect without a xorg.conf file. Sweet!

Thanks! Finally a working Norwegian/Danish config:

# cat /etc/sysconfig/keyboard 
KEYBOARDTYPE="pc"
KEYTABLE="no"

# lshal | grep xkb
  input.xkb.layout = 'no'  (string)
  input.xkb.model = 'evdev'  (string)
  input.xkb.rules = 'base'  (string)
  input.xkb.variant = ''  (string)

Section "InputDevice"
	Identifier  "Keyboard0"
	Driver      "kbd"
	Option	    "XkbModel" "evdev"
	Option	    "XkbLayout" "no"
	Option	    "xkb_rules" "base"
        Option      "XkbVariant" "nodeadkeys"
EndSection

# grep no /usr/share/hal/fdi/policy/10osvendor/10-keymap.fdi 
      <merge key="input.xkb.layout" type="string">no</merge>

For Danish, ^no^dk

> Thanks! Finally a working Norwegian/Danish config

The above apparently means that a particular keyboard layout
is imposed on the whole system or it is possible to hack hal
policies which apply only to a particular account?  Yes, there
were occasions where I had at least such needs.

Temporary switching a keyboard layout while in a session looks
like totally out of question.  Bummer!

> Temporary switching a keyboard layout while in a session looks
> like totally out of question.  Bummer!

True. As soon as I do System->Administration->Keyboard and choose danish and 
back to Norwegian, all is screwed up. Have to exit X to get back the proper 
config.  For instance, AltGr+2 ( at key ) gives me just a nothing. Kind of 
reminds me of problems seen when you put a WHQL keyboard on a codeset 3 only 
computer. The extended scan codes doesn't work as MS didn't see it necessary to 
support codeset 3 in their kbd standard back in 99, and most kbd vendors didn't 
either.

(In reply to comment #44)
> (In reply to comment #41)
> > If this goes to F9 release and most users who upgrade their system, then
> reboot, cannot use ALT 
> 
> The alt problem was a bug (xorg not behaving as designed). As Ajax noted it
> should be fixed in the xorg that just landed in rawhide.

Which one? xorg-x11-server-Xorg-1.4.99.901-1.20080307.fc9.i386 is very much
broken here...

> The "up-arrow" = "PrintScreen" is xorg misbehaving in an invalid configuration
> that happens to be the one most people migrating from previous versions land
> with but remains an invalid config upstream tells you not to use and does not
> support.

I /deleted/ xorg.conf to get rid of old, broken configuration, and I do see this
PrintScreen on UpArrow nonsense. Other arrow keys do nothing at all.

alt-ctrl-Fx does work now, but I still have to use system-config-keyboard to get
Spanish layout (sort of, UpArrow is PrtScreen, other arrow keys don't work,
AltGr does nothing, many other keys (braces, brackets) don't do anything). 

Besides, the handling of the mouse buttons seems to have changed two versions back.

No xorg.conf here.

xorg-x11-server-Xorg-1.4.99.901-1.20080307.fc9.i386

This is *very definitely* not closed!

This is still a problem. Reopening.

Fixed in xserver 1.4.99.901-4 and hal-0.5.11-0.git20080304.4.fc9.  We'll inherit
keyboard layout from /etc/sysconfig/keyboard now.

No change. Hal has the same fdi file, the same result with lshal and the
keyboard is "us" in X.

(In reply to comment #60)
> No change. Hal has the same fdi file, the same result with lshal and the
> keyboard is "us" in X.

cat /etc/sysconfig/keyboard

Agree. I thought xorg xserver rpm just replaced /usr/share/hal//fdi/
policy/10osvendor/10-keymap.fdi setting, but after a couple of reboots it 
definitly do not inherit it from /etc/sysconfig/keyboard.

# rpm -qa | egrep -e "server-Xorg|hal-0."
xorg-x11-server-Xorg-1.4.99.901-5.20080310.fc9.x86_64
hal-0.5.11-0.git20080304.4.fc9.x86_64

Also the problem with "uparrow-snapshot".  Is there a workaround? It is quite 
annoying when working in editors.

# cat /etc/sysconfig/keyboard 
KEYBOARDTYPE="pc"
KEYTABLE="no"

This is not exclusively to gripe in response to the horrible changes to the
keyboard and mice changes. It gives me the chance to lear different and clumsy
means to interface with the computer.
First the mouse behavior, I hav a synaptics touchpad where the click does not
work. I have to use the Belkin USB mouse to click. I next have a problem with
the right click operation on the Belkin, it causes a paste instead of bringing
up the menu which should be displayed. Not only do I have to use both hands for
the mouse interface with two different devices. I also get the up arrow trying
to bring up the screenshot. 

cat /etc/sysconfig/keyboard
KEYBOARDTYPE="pc"
KEYTABLE="us"


A note about the strange mouse behavior. I am getting to like the cut and paste
feature for the Belkin.

I'll attach my xorg.0.log also.

Created attachment 298008 [details]
log from current session

Hopefully this log shoud show useful info to resolve the keyboard and
additionally the strange mouse interface problems.

(In reply to comment #61)
> (In reply to comment #60)
> > No change. Hal has the same fdi file, the same result with lshal and the
> > keyboard is "us" in X.
> 
> cat /etc/sysconfig/keyboard

Sorry. That was of course also checked. :)

# cat /etc/sysconfig/keyboard 
KEYBOARDTYPE="pc"
KEYTABLE="sv-latin1"

(In reply to comment #63)

The right/middle mouse button issue is a different bug, which is fixed in
current rawhide already.

The USB Belkin was fixed by the latest update. (Right and middle working
properly now)
The synaptics is still broken and I'll look for an open bug for the synaptics
problem.

(In reply to comment #67)
> The synaptics is still broken and I'll look for an open bug for the synaptics
> problem.

Red Hat changed the defaults in a recent updates so that tap to click is
disabled. You have to change your config and add "TabButton1" & co.

Thanks for the information regarding the change. I do not understand how to
re-enable this feature yet but will research it. Since it co-coincided with the
funky unintended mouse behavior I assumed that the synaptics was broken too, not
intentionally crippled by configuration changes.

For me, I think this bug was caused by the handling of two keyboard types (one
in X, one in Gnome) being changed.

It doesn't help that there are two programs to manage the keyboard. I changed
the setting in both, and now it wfm.

It doesn't wfm since I rebooted, and since s-c-k is obsolete, I am stuck with
the problem.

There is still a keyboard problem in the latest version of F9-beta/rawhide.
The Std keyboard on my T60 is o.k. (German-nodeadkeys). When X is started while
my old PS/2 keyboard is connected, all the arrow keys and the numeric keypad
have a wrong mapping. Attaching the keyboard while X is running, gives the
correct mapping.

I did not yet tweak with the config files because I think this should be solved
for GA.

Werner

Replugging doesn't work for me.

Hey you fixed it - thanks! What was the problem?

Changing version to '9' as part of upcoming Fedora 9 GA.
More information and reason for this action is here:
http://fedoraproject.org/wiki/BugZappers/HouseKeeping

The latest update broke this in some odd way again. Back to US layout :/

should be fixed in rawhide (In reply to comment #76)
> The latest update broke this in some odd way again. Back to US layout :/

should be fixed in rawhide with 906-5. can you please verify this?

Yes, that did indeed fix it. Although it required a reboot as there were some HAL tweaks in there.

Will HAL pick up updates to /etc/sysconfig/keyboard in realtime or is a reboot required when changing layout?

(In reply to comment #78)
> Will HAL pick up updates to /etc/sysconfig/keyboard in realtime or is a reboot
> required when changing layout?

you need to restart hal for hal to pick it up, and then restart X for X to pick it up.

I've updated today xorg to 906-5 and it has crashed keyboard, before update it worked fine. I had the same problem before yours previous fixing. Arrows, delete, right alt and maybe more keys don't work or work bad.

(In reply to comment #80)
> I've updated today xorg to 906-5 and it has crashed keyboard, before update it
> worked fine. I had the same problem before yours previous fixing. Arrows,
> delete, right alt and maybe more keys don't work or work bad.

Please supply your Xorg.log so we can debug this.

If your arrow/delete/etc. keys are messed up, make sure you change gnome to use "evdev-managed keyboard" as keyboard model.

Sorry for the alarm. It works fine before log in. 
Thank you, I've changed the settings and it is OK.

(In reply to comment #80)
> I've updated today xorg to 906-5 and it has crashed keyboard, before update it
> worked fine. I had the same problem before yours previous fixing. Arrows,
> delete, right alt and maybe more keys don't work or work bad.

I use a japanese type keyboard (Microsoft Ergonomic USB keyboard).
When I update to 906-5,  the keymap is wrong as follows.
  1. cannot input '\', '_' key
  2. cannot input numeric keypad such as '0'--- '9'
But arrow keys, and ctrl+alt+F1 key is works.

So I revert to 906-1.

(In reply to comment #83)
> I use a japanese type keyboard (Microsoft Ergonomic USB keyboard).
> When I update to 906-5,  the keymap is wrong as follows.
>   1. cannot input '\', '_' key
>   2. cannot input numeric keypad such as '0'--- '9'
> But arrow keys, and ctrl+alt+F1 key is works.
> 
> So I revert to 906-1.

can you please attach your xorg.log, the output of setxkbmap -print and the output of gconftool-2 --dump /desktop/gnome/peripherals/keyboard

Created attachment 314023 [details]
setxkbmap -print output

Created attachment 314024 [details]
Xorg log

Created attachment 314025 [details]
gconftool-2 --dump /desktop/gnome/peripherals/keyboard output

(In reply to comment #87)
> Created an attachment (id=314025) [details]
> gconftool-2 --dump /desktop/gnome/peripherals/keyboard output

i wonder how you got jp106 into the sysbackup model. this should always be evdev. 
can you start a raw x server ("xinit --") and tell me if the keyboard is messed up there as well?

(In reply to comment #88)
> (In reply to comment #87)
> > Created an attachment (id=314025) [details] [details]
> > gconftool-2 --dump /desktop/gnome/peripherals/keyboard output
> 
> i wonder how you got jp106 into the sysbackup model. this should always be
> evdev. 
> can you start a raw x server ("xinit --") and tell me if the keyboard is messed
> up there as well?
I press ctrl+alt+F1 and login.
Then '\', '_' key work.
But Numeric 10-key are not recognized.

I change sysbackup model to evdev.
But nothing is changed.

(In reply to comment #89)
> I press ctrl+alt+F1 and login.
> Then '\', '_' key work.
> But Numeric 10-key are not recognized.
> 
> I change sysbackup model to evdev.
> But nothing is changed.

ok, here's what I need you to do:
press ctrl+alt+F1 and login.then type "su -c gdm-stop" and enter the root password. This will stop gdm. You may need to press ctrl+alt-F1 again to get back to the original terminal. then type "xinit --", it will bring up a x server and xterm. try the keyboard in the xterm, then hit ctrl+alt+backspace to stop the X server and drop back onto the console. su -c gdm restarts gdm (or reboot the box).

I'm trying to figure out whether it's X or gnome screwing up the keymap.

(In reply to comment #90)
> (In reply to comment #89)
> > I press ctrl+alt+F1 and login.
> > Then '\', '_' key work.
> > But Numeric 10-key are not recognized.
> > 
> > I change sysbackup model to evdev.
> > But nothing is changed.
> 
> ok, here's what I need you to do:
> press ctrl+alt+F1 and login.then type "su -c gdm-stop" and enter the root
> password. This will stop gdm. You may need to press ctrl+alt-F1 again to get
> back to the original terminal. then type "xinit --", it will bring up a x
> server and xterm. try the keyboard in the xterm, then hit ctrl+alt+backspace to
> stop the X server and drop back onto the console. su -c gdm restarts gdm (or
> reboot the box).
> 
> I'm trying to figure out whether it's X or gnome screwing up the keymap.
I tested as you wrote on xterm .

1. 906-5
    '\', '_' key are not recognized.
    numeric keys are same.

2. 906-1
   '\', '_' are recognized.
   But, numeric keys(KP-01,02, .. so on) are not recognized.

regards.

I tryed 906-5 from Rawhide. Gnome uses evdev. My preferred keymap is properly activated at login (autologin by gdm). But the secondary keymap is odd (US). Space is generating weird whitespace character so I'm unable to type commands on commandline. If keyboard properties are activated, changed and saved, all works again. So there is a great progress with some outstanding issues.

Created attachment 315017 [details]
Xorg.log

Created attachment 315018 [details]
gconftool-2 --dump /desktop/gnome/peripherals/keyboard output

Created attachment 315019 [details]
setxkbmap -print output

Created attachment 315020 [details]
xev output

Space key has been pressed on my keyboard (line 95), layout has been changed (Alt+Shift) and space key with US layout has been pressed (line 140). Then focus has been changed and xev has been aborted by CTRL+c.

(In reply to comment #92)
> I tryed 906-5 from Rawhide. Gnome uses evdev. My preferred keymap is properly
> activated at login (autologin by gdm). But the secondary keymap is odd (US).
> Space is generating weird whitespace character so I'm unable to type commands
> on commandline. If keyboard properties are activated, changed and saved, all
> works again. So there is a great progress with some outstanding issues.

This is most likely an xkbcomp issue. Please open a separate bug report, attaching the output of "xkbcomp :0 -" and linking to the attachments above.

Component is xorg-x11-xkb-utils, assign it to me. Thx.

Posted as bug #460545.

This bug has reappeared for me on Rawhide - cursor keys don't work, nor do PageUp and PageDown.

xorg-x11-server-Xorg-1.4.99.906-10.fc10.x86_64

Created attachment 315424 [details]
xorg.conf

Keyboard is broken for me too. Apart from the keyboard selector in gdm not working at all, the arrow keys, pipe key, and all alt-gr keys are broken.

It's not worth using Linux without a pipe key. Please can we have our Linux boxes back :)

Adam: which keyboard model is configured in GNOME? Make sure it is "evdev-managed keyboard".

It's gone through several stages of working and not working in the past week, with Rawhide updates.  As of today, it is working (and I do have that setting in GNOME).

xorg-x11-server-Xorg-1.5.0-1.fc10.x86_64

Adam: please post the output of setxkbmap -print when it's working and when it's not working. Likewise, the output of xkbcomp :0 -.

setxkbmap -print

xkb_keymap {
	xkb_keycodes  { include "evdev+aliases(qwerty)"	};
	xkb_types     { include "complete"	};
	xkb_compat    { include "complete"	};
	xkb_symbols   { include "pc+gb+inet(evdev)"	};
	xkb_geometry  { include "pc(pc104)"	};
};

Created attachment 316153 [details]
xkbcomp output

Both this and the previous comment cover when the keyboard is working normally.

This evening there seems to be a problem with using Ctrl-Alt-<cursor> to switch desktops, and right-clicking on an application#s titlebar.  The desktop becomes unresponsive and the only workaround is to switch to a virtual console and then back into X.

setxkbmap -print

xkb_keymap {
	xkb_keycodes  { include "evdev+aliases(qwerty)"	};
	xkb_types     { include "complete"	};
	xkb_compat    { include "complete"	};
	xkb_symbols   { include "pc+gb+inet(evdev)"	};
	xkb_geometry  { include "pc(pc104)"	};
};

Created attachment 316260 [details]
xkbcomp output with keyboard problem

(In reply to comment #107)
> This evening there seems to be a problem with using Ctrl-Alt-<cursor> to switch
> desktops, and right-clicking on an application#s titlebar.  The desktop becomes
> unresponsive and the only workaround is to switch to a virtual console and then
> back into X.

there's difference in the keymaps to what you submitted the other day, or the setup I tried here - indicating that the problem is more likely at an application level rather than xkb/xserver level.
Especially if the right-clicking doesn't work. It could be something like a key grab going rogue, but we'd need a reproduceable test-case to confirm that.

"there's _no_ difference", was what I meant to say.

And this morning that problem has disappeared, even though no new packages have been installed.  Hmm...

Let us know if it returns.

it seems acceptable now, will resurrect this bug if it returns it's naughty behavior

Can I please have an update on this? Anyone running F9 still experiencing this issue with xorg-x11-server-1.5.0-2.fc9?

F10 issues - please file a separate bug so it's easier to keep track of them.

Both my F10 machines are fine at the moment, as are the various F9 machines.

The bug has been resoved with prior fixes as I'm using xorg-x11-server-Xorg-1.4.99.906-5.fc10.i386 now and I'm fine for some time at most machines. Even that I have problem with   produced by space key but only on one machine I have around with the same setup. See bug #460545 for more info.

xorg-x11-server-Xorg-1.5.2-2.fc10.i386 screwed this up again.

Hmm... maybe a false alarm. When I went into gconf and nuked all the kbd settings, things started working. The problem first appeared when I updated the server package though.

Closing again, Pierre's issue is with F10.

That one is 466675

I upgraded to F12 (beta) today, and this bugger is back. Very annoying... :/

Better to file a new bug I think.

Is comment 121 bug 530452?

bug 530452 is probably related, but it's the wrong keyboard in gdm as well, so there is something amiss with the initial setup as well.

I guess I should have read the entire thread. It seems to be the same bug. Updating gdm and nuking my .dmrc fixed the issue.

Since this bugzilla report was filed, there have been several major updates in various components of the Xorg system, which may have resolved this issue. Users who have experienced this problem are encouraged to upgrade their system to the latest version of their packages (at least F12Beta, but even better if the very latest versions).

Please, if you experience this problem on the up-to-date system, let us now in the comment for this bug, or whether the upgraded system works for you.

If you won't be able to reply in one month, I will have to close this bug as INSUFFICIENT_DATA. Thank you.

[This is a bulk message for all open Fedora Rawhide Xorg-related bugs. I'm adding myself to the CC list for each bug, so I'll see any comments you make after this and do my best to make sure every issue gets proper attention.]

Seems fixed in Rawhide (F12 beta has slight issues but a fresh rawhide install is bugfree in this area)