Bug 434669 - keyboard layout not correctly detected
keyboard layout not correctly detected
Status: CLOSED RAWHIDE
Product: Fedora
Classification: Fedora
Component: xorg-x11-server (Show other bugs)
rawhide
x86_64 Linux
low Severity high
: ---
: ---
Assigned To: Adam Jackson
Fedora Extras Quality Assurance
https://www.redhat.com/archives/fedor...
: Reopened
: 433917 434634 (view as bug list)
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2008-02-23 23:59 EST by David Nielsen
Modified: 2009-11-05 18:40 EST (History)
34 users (show)

See Also:
Fixed In Version: xorg-x11-server-1.5.0-2.fc9
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2009-11-05 18:40:15 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
sundaram: fedora_requires_release_note-


Attachments (Terms of Use)
Xorg.log (59.36 KB, application/octet-stream)
2008-02-23 23:59 EST, David Nielsen
no flags Details
xorg.conf (571 bytes, application/octet-stream)
2008-02-24 00:00 EST, David Nielsen
no flags Details
This is xorg.log with current session where ctl-alt-f1 followed by f7 tried (45.04 KB, text/plain)
2008-03-05 20:31 EST, Jim Cornette
no flags Details
log from current session (41.55 KB, text/plain)
2008-03-13 22:52 EDT, Jim Cornette
no flags Details
setxkbmap -print output (240 bytes, text/plain)
2008-08-11 21:46 EDT, MASAO TAKAHASHI
no flags Details
Xorg log (84.33 KB, text/plain)
2008-08-11 21:48 EDT, MASAO TAKAHASHI
no flags Details
gconftool-2 --dump /desktop/gnome/peripherals/keyboard output (6.06 KB, text/plain)
2008-08-11 21:50 EDT, MASAO TAKAHASHI
no flags Details
Xorg.log (61.14 KB, text/plain)
2008-08-26 13:35 EDT, Milan Kerslager
no flags Details
gconftool-2 --dump /desktop/gnome/peripherals/keyboard output (6.85 KB, text/plain)
2008-08-26 13:36 EDT, Milan Kerslager
no flags Details
setxkbmap -print output (380 bytes, text/plain)
2008-08-26 13:36 EDT, Milan Kerslager
no flags Details
xev output (6.56 KB, text/plain)
2008-08-26 13:40 EDT, Milan Kerslager
no flags Details
xorg.conf (596 bytes, text/plain)
2008-08-30 13:04 EDT, Adam Huffman
no flags Details
xkbcomp output (56.42 KB, text/plain)
2008-09-09 03:40 EDT, Adam Huffman
no flags Details
xkbcomp output with keyboard problem (56.42 KB, text/plain)
2008-09-09 18:51 EDT, Adam Huffman
no flags Details

  None (edit)
Description David Nielsen 2008-02-23 23:59:52 EST
Description of problem:
Ever since the upgrade to
xorg-x11-server-common-1.4.99.1-0.23.20080222.fc9.x86_64 Xorg detects my
keyboard wrong it also does not respond to changes to the layout setting in
xorg.conf. Affected keyboard is a Logitech Internet Navigator DK layout

Additional reports for i386 and other layouts can be found in this following
thread and follow ups:
https://www.redhat.com/archives/fedora-devel-list/2008-February/msg02024.html

Mike Chambers also reports problems with detection of his logictech mouse here:
https://www.redhat.com/archives/fedora-devel-list/2008-February/msg02028.html

Version-Release number of selected component (if applicable):
xorg-x11-server-common-1.4.99.1-0.23.20080222.fc9.x86_64

How reproducible:
100%

Steps to Reproduce:
1. upgrade to -23
2. restart X
  
Actual results:
watch in awe as keyboard layout is now detected as 

(**) Option "xkb_rules" "base"
(**) Option "xkb_model" "evdev"
(**) Option "xkb_layout" "us"
(II) XINPUT: Adding extended input device "AT Translated Set 2 keyboard" (type:
KEYBOARD)

Expected results:
Correctly detected keyboard, or at least obeying the xorg.conf setting

Additional info:
Comment 1 David Nielsen 2008-02-23 23:59:52 EST
Created attachment 295732 [details]
Xorg.log
Comment 2 David Nielsen 2008-02-24 00:00:56 EST
Created attachment 295733 [details]
xorg.conf
Comment 3 Pierre Ossman 2008-02-24 06:05:55 EST
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).
Comment 4 Pierre Ossman 2008-02-24 06:07:31 EST
I guess that was three things. I blame the lack of caffeine ;)
Comment 5 Pierre Ossman 2008-02-24 07:14:07 EST
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.
Comment 6 David Nielsen 2008-02-24 07:22:36 EST
sounds like we need davidz, hal superhero.. added to CC
Comment 7 Ralf Ertzinger 2008-02-24 08:28:41 EST
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?
Comment 8 Mike Chambers 2008-02-24 09:13:58 EST
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.
Comment 9 Pierre Ossman 2008-02-24 10:36:04 EST
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.
Comment 10 Jim Cornette 2008-02-24 11:15:22 EST
no control or alt keys. Adding to cc.

Section "InputDevice"
	Identifier  "Keyboard0"
	Driver      "kbd"
	Option	    "XkbModel" "pc105"
	Option	    "XkbLayout" "us+inet"
Comment 11 Charles R. Anderson 2008-02-24 14:48:30 EST
*** Bug 434634 has been marked as a duplicate of this bug. ***
Comment 12 David Zeuthen 2008-02-24 15:22:02 EST
(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.
Comment 13 Pierre Ossman 2008-02-25 03:15:20 EST
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.
Comment 14 Matthew Miller 2008-02-25 07:01:37 EST
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.)
Comment 15 Tore H. Larsen 2008-02-25 09:13:24 EST
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
Comment 16 Matěj Cepl 2008-02-25 09:28:11 EST
Ajax is sacrificially taking blame for this ;-).
Comment 17 Bill Nottingham 2008-02-25 11:46:02 EST
ctrl-alt not working is different from the other issues. See
http://freedesktop.org/bugzilla/show_bug.cgi?id=14584.
Comment 18 Bill Nottingham 2008-02-25 11:47:37 EST
*** Bug 433917 has been marked as a duplicate of this bug. ***
Comment 20 Horst H. von Brand 2008-02-26 10:25:41 EST
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.
Comment 21 Ralf Ertzinger 2008-02-26 10:51:03 EST
Strangely enough, apart from the Ctrl-Alt-Problem, my keyboard works as it
should, with both config styles (xkb and evdev).
Comment 22 Pierre Ossman 2008-02-26 12:03:14 EST
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.


Comment 23 Pierre Ossman 2008-02-26 12:05:15 EST
Also, under 1 Ctrl+Alt+Backspace works, but not Ctrl+Alt+Fn. Under 2, neither work.
Comment 24 Horst H. von Brand 2008-02-28 07:59:35 EST
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!
Comment 25 Bill Nottingham 2008-02-28 10:59:50 EST
The point is it shouldn't *NEED* configuration files.
Comment 26 Pierre Ossman 2008-02-28 11:47:01 EST
(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.
Comment 27 Horst H. von Brand 2008-02-28 14:27:17 EST
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.
Comment 28 Horst H. von Brand 2008-02-28 14:37:52 EST
Sorry, the above is after system-config-keyboard'ing it to Spanish
Comment 29 MASAO TAKAHASHI 2008-02-28 21:34:53 EST
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 ? 
Comment 30 Mike Chambers 2008-03-04 07:09:27 EST
Still having problems with this as don 't see any fix comments.
Comment 31 Adam Jackson 2008-03-04 10:33:52 EST
Should be fixed in xorg-x11-server-1.4.99.900-0.27.20080303.fc9.
Comment 32 Steven Usdansky 2008-03-04 19:05:11 EST
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
Comment 33 Dennis Jacobfeuerborn 2008-03-04 19:24:39 EST
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.
Comment 34 Steven Usdansky 2008-03-04 19:56:17 EST
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
Comment 35 Mike Chambers 2008-03-04 19:58:51 EST
Don't know if it matters if it does NOT work, but do you need
xorg-x11-server-common or whatever as well?
Comment 36 Dennis Jacobfeuerborn 2008-03-04 20:26:31 EST
(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.
Comment 37 Nicolas Mailhot 2008-03-05 02:34:30 EST
(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
Comment 38 David Nielsen 2008-03-05 04:49:07 EST
(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.

Comment 39 Nicolas Mailhot 2008-03-05 05:02:23 EST
(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.
Comment 40 David Nielsen 2008-03-05 05:22:23 EST
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. 
Comment 41 Andrew Farris 2008-03-05 06:06:23 EST
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.
Comment 42 Rahul Sundaram 2008-03-05 06:27:12 EST
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.  
Comment 43 Pierre Ossman 2008-03-05 06:51:29 EST
I can confirm that the new update solves the issue (provided the configuration
is correct).

I've opened bug 436090 to fix HAL.
Comment 44 Nicolas Mailhot 2008-03-05 07:01:04 EST
(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)
Comment 45 antonio montagnani 2008-03-05 07:06:55 EST
(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???
Comment 46 Steven Usdansky 2008-03-05 07:34:22 EST
With today's update Xorg -configure gives me the following in xorg.conf

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

which still requires fixing.
Comment 47 Pierre Ossman 2008-03-05 08:46:21 EST
(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.
Comment 48 Jim Cornette 2008-03-05 20:28:38 EST
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.
Comment 49 Jim Cornette 2008-03-05 20:31:51 EST
Created attachment 296973 [details]
This is xorg.log with current session where ctl-alt-f1 followed by f7 tried
Comment 50 Dennis Jacobfeuerborn 2008-03-07 21:33:50 EST
(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)
Comment 51 Pierre Ossman 2008-03-08 06:53:27 EST
(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)
Comment 52 Dennis Jacobfeuerborn 2008-03-08 21:11:26 EST
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!
Comment 53 Tore H. Larsen 2008-03-09 17:15:55 EDT
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
Comment 54 Michal Jaegermann 2008-03-09 17:51:59 EDT
> 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!
Comment 55 Tore H. Larsen 2008-03-09 18:12:10 EDT
> 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.
Comment 56 Horst H. von Brand 2008-03-09 18:57:18 EDT
(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.
Comment 57 Horst H. von Brand 2008-03-10 09:55:36 EDT
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!
Comment 58 Thomas Woerner 2008-03-10 12:56:06 EDT
This is still a problem. Reopening.
Comment 59 Adam Jackson 2008-03-12 16:53:57 EDT
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.
Comment 60 Pierre Ossman 2008-03-13 12:28:10 EDT
No change. Hal has the same fdi file, the same result with lshal and the
keyboard is "us" in X.
Comment 61 Adam Jackson 2008-03-13 16:55:09 EDT
(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
Comment 62 Tore H. Larsen 2008-03-13 19:36:12 EDT
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"

Comment 63 Jim Cornette 2008-03-13 22:49:31 EDT
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.
Comment 64 Jim Cornette 2008-03-13 22:52:47 EDT
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.
Comment 65 Pierre Ossman 2008-03-14 02:32:56 EDT
(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"
Comment 66 Ralf Ertzinger 2008-03-14 08:22:47 EDT
(In reply to comment #63)

The right/middle mouse button issue is a different bug, which is fixed in
current rawhide already.
Comment 67 Jim Cornette 2008-03-14 11:38:45 EDT
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.
Comment 68 Pierre Ossman 2008-03-14 13:07:04 EDT
(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.
Comment 69 Jim Cornette 2008-03-14 22:00:50 EDT
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.
Comment 70 Need Real Name 2008-04-04 13:21:54 EDT
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.
Comment 71 Need Real Name 2008-04-11 12:30:36 EDT
It doesn't wfm since I rebooted, and since s-c-k is obsolete, I am stuck with
the problem.
Comment 72 Werner Gold 2008-04-22 09:25:56 EDT
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
Comment 73 Need Real Name 2008-04-22 12:26:57 EDT
Replugging doesn't work for me.
Comment 74 Need Real Name 2008-04-28 14:22:10 EDT
Hey you fixed it - thanks! What was the problem?
Comment 75 Bug Zapper 2008-05-14 01:36:23 EDT
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
Comment 76 Pierre Ossman 2008-08-01 13:36:57 EDT
The latest update broke this in some odd way again. Back to US layout :/
Comment 77 Peter Hutterer 2008-08-06 03:49:06 EDT
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?
Comment 78 Pierre Ossman 2008-08-06 07:41:51 EDT
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?
Comment 79 Peter Hutterer 2008-08-06 20:42:15 EDT
(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.
Comment 80 Karol Trzcionka 2008-08-10 17:49:49 EDT
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.
Comment 81 Peter Hutterer 2008-08-10 21:09:36 EDT
(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.
Comment 82 Karol Trzcionka 2008-08-11 04:21:57 EDT
Sorry for the alarm. It works fine before log in. 
Thank you, I've changed the settings and it is OK.
Comment 83 MASAO TAKAHASHI 2008-08-11 19:51:54 EDT
(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.
Comment 84 Peter Hutterer 2008-08-11 20:46:54 EDT
(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
Comment 85 MASAO TAKAHASHI 2008-08-11 21:46:59 EDT
Created attachment 314023 [details]
setxkbmap -print output
Comment 86 MASAO TAKAHASHI 2008-08-11 21:48:48 EDT
Created attachment 314024 [details]
Xorg log
Comment 87 MASAO TAKAHASHI 2008-08-11 21:50:14 EDT
Created attachment 314025 [details]
gconftool-2 --dump /desktop/gnome/peripherals/keyboard output
Comment 88 Peter Hutterer 2008-08-11 23:10:20 EDT
(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?
Comment 89 MASAO TAKAHASHI 2008-08-11 23:58:16 EDT
(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.
Comment 90 Peter Hutterer 2008-08-12 00:05:47 EDT
(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.
Comment 91 MASAO TAKAHASHI 2008-08-12 00:47:16 EDT
(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.
Comment 92 Milan Kerslager 2008-08-26 13:33:29 EDT
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.
Comment 93 Milan Kerslager 2008-08-26 13:35:18 EDT
Created attachment 315017 [details]
Xorg.log
Comment 94 Milan Kerslager 2008-08-26 13:36:18 EDT
Created attachment 315018 [details]
gconftool-2 --dump /desktop/gnome/peripherals/keyboard output
Comment 95 Milan Kerslager 2008-08-26 13:36:59 EDT
Created attachment 315019 [details]
setxkbmap -print output
Comment 96 Milan Kerslager 2008-08-26 13:40:36 EDT
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.
Comment 97 Peter Hutterer 2008-08-27 03:26:34 EDT
(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.
Comment 98 Milan Kerslager 2008-08-28 10:50:18 EDT
Posted as bug #460545.
Comment 99 Adam Huffman 2008-08-30 13:03:16 EDT
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
Comment 100 Adam Huffman 2008-08-30 13:04:20 EDT
Created attachment 315424 [details]
xorg.conf
Comment 101 Need Real Name 2008-09-01 14:38:09 EDT
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 :)
Comment 102 Peter Hutterer 2008-09-08 03:16:16 EDT
Adam: which keyboard model is configured in GNOME? Make sure it is "evdev-managed keyboard".
Comment 103 Adam Huffman 2008-09-08 03:46:16 EDT
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
Comment 104 Peter Hutterer 2008-09-08 05:06:39 EDT
Adam: please post the output of setxkbmap -print when it's working and when it's not working. Likewise, the output of xkbcomp :0 -.
Comment 105 Adam Huffman 2008-09-09 03:39:27 EDT
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)"	};
};
Comment 106 Adam Huffman 2008-09-09 03:40:50 EDT
Created attachment 316153 [details]
xkbcomp output

Both this and the previous comment cover when the keyboard is working normally.
Comment 107 Adam Huffman 2008-09-09 18:50:38 EDT
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)"	};
};
Comment 108 Adam Huffman 2008-09-09 18:51:40 EDT
Created attachment 316260 [details]
xkbcomp output with keyboard problem
Comment 109 Peter Hutterer 2008-09-10 03:33:52 EDT
(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.
Comment 110 Peter Hutterer 2008-09-10 03:35:13 EDT
"there's _no_ difference", was what I meant to say.
Comment 111 Adam Huffman 2008-09-10 03:46:06 EDT
And this morning that problem has disappeared, even though no new packages have been installed.  Hmm...
Comment 112 Matěj Cepl 2008-09-10 11:56:06 EDT
Let us know if it returns.
Comment 113 David Nielsen 2008-09-10 13:25:11 EDT
it seems acceptable now, will resurrect this bug if it returns it's naughty behavior
Comment 114 Peter Hutterer 2008-09-17 23:19:01 EDT
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.
Comment 115 Adam Huffman 2008-09-18 06:34:15 EDT
Both my F10 machines are fine at the moment, as are the various F9 machines.
Comment 116 Milan Kerslager 2008-09-18 13:17:58 EDT
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 &nbsp; produced by space key but only on one machine I have around with the same setup. See bug #460545 for more info.
Comment 117 Pierre Ossman 2008-10-12 14:29:19 EDT
xorg-x11-server-Xorg-1.5.2-2.fc10.i386 screwed this up again.
Comment 118 Pierre Ossman 2008-10-12 14:44:16 EDT
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.
Comment 119 Peter Hutterer 2008-10-12 23:09:25 EDT
Closing again, Pierre's issue is with F10.
Comment 120 Horst H. von Brand 2008-10-12 23:51:12 EDT
That one is 466675
Comment 121 Pierre Ossman 2009-10-24 14:50:32 EDT
I upgraded to F12 (beta) today, and this bugger is back. Very annoying... :/
Comment 122 Jens Petersen 2009-10-26 03:44:24 EDT
Better to file a new bug I think.
Comment 123 Jens Petersen 2009-10-26 04:14:35 EDT
Is comment 121 bug 530452?
Comment 124 Pierre Ossman 2009-10-26 13:04:30 EDT
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.
Comment 125 Pierre Ossman 2009-10-26 13:27:25 EDT
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.
Comment 126 Matěj Cepl 2009-11-05 12:11:34 EST
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.]
Comment 127 David Nielsen 2009-11-05 18:40:15 EST
Seems fixed in Rawhide (F12 beta has slight issues but a fresh rawhide install is bugfree in this area)

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