Bug 13037

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

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

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

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

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

I think the evdev driver requires XkbModel "evdev".

please excuse the duplicates. i think they were caused by the page that showed the summary to my request. i kept it open and reloaded it several times to see if someone has answered. i find this behaviour of bugzilla quite weird. the results-page should not keep any of the previous POST-information in the back. sorry again.

i tried the XkbModel line but without changes

That's because your desktop environment is overriding your settings.  Change the model in the preferences to 'Evdev-managed keyboard'.  Also, US is the default because there is no 'none'.  Either you pick a given locale's keyboard (of which US is the most widely used), or you have no keyboard whatsoever, and pressing on any key results in nothing happening.

are you talking about KDE? i'm using XFCE, and there is no such option.

also, you got me wrong. i was talking about how xorg 'should' behave to provide a native feeling (i'm not in the U.S.A. and am really not interested in it's widely used profiles at all--that is just of no use to me. and, the most widely used profile isn't automatically the most used profile (if the assumption is correct at all). in the specific case, this is not of any interest. choosing a fix setting as a default, instead of respecting the system's locale settings if the xorg setting is 'none' [not set to a fix value yet], is generally a break with the user's preferences and expectancies about how his apps behave on his system--even if a fix default setting was accidentially useful.)

Btw.: you shouldn't use the imperative so generously. many thanks.

(In reply to comment #7)
> please excuse the duplicates. i think they were caused by the page that showed
> the summary to my request. i kept it open and reloaded it several times to see
> if someone has answered.

just add yourself to the CC list on the bugs you want to hear about. saves you reloading the pages. 
(yes, fixing bugzilla is an option but in the meantime...)

I installed evdev 1.2 and now even the mouse doesn't work anymore.

(In reply to comment #11)
> I installed evdev 1.2 and now even the mouse doesn't work anymore.

evdev 1.2 does not support the "Name" option. you have to specify the device directly. 
or, if you're running 1.4 just let the server find it.

(In reply to comment #9)
> also, you got me wrong. i was talking about how xorg 'should' behave to provide
> a native feeling

the x server gets the keyboard layout from HAL at hot-plug time. the most likely offender is x11-input.fdi, to be found in xserver/config (or /etc/hal/fdi/policy/ after installation). 
so the best way to fix this problem is to make hal to submit the layout matching the local. 

Patches welcome of course :)

well my problem is: on server 1.4.x , if I install evdev correctly, evdev loads automatically, which make kdb and mouse drives obsoletes and the xorg.conf configuration drives should change. 

In my case , when I had (on xorg.conf) drive kbd with layout pt and "XkbModel"  "pc105" which loads first of evedev, after that, evedev loads and reload keyboard with layout us.
The setting model by kbd in first place, is the problem here.
Or not have evdev keyboard layout config.  

so IMHO if evdev loads, automatically without changing old xorg.conf cause problems, and or should not load if at least kdb and mouse had load before or should warning that kdb and mouse are deprecated and should be change to evdev or if this is not possible, the module shouldn't if it is not on #Section "Module"

... the module evdev shouldn't load if it is not on #Section "Module"

> the most likely offender is x11-input.fdi

There is no such file on my system.

> evdev 1.2 does not support the "Name" option. you have to specify the device
> directly. or, if you're running 1.4 just let the server find it.

The man page still lists the "Name" option. I tried the following config with 1.4.0.90 but neither the mouse nor the keyboard worked:

Section "InputDevice"
	Identifier  "Keyboard0"
	Driver      "evdev"
	Option      "XkbModel"  "evdev"
EndSection

Section "InputDevice"
	Identifier  "Mouse0"
	Driver      "evdev"
EndSection

Can somebody please write me a config to try out, double please?

(In reply to comment #15)
> ... the module evdev shouldn't load if it is not on #Section "Module"
> 

Add "Option" "AutoAddDevices" "False" to your ServerLayout. This will stop
evdev from loading. 
It's not the silver bullet since you lose input-hotplug, but it might help in
your specific case.

(In reply to comment #16)
> > the most likely offender is x11-input.fdi 
> There is no such file on my system.

hmm. interesting. did you have libhal-dev installed when you ran configure? if not, hal support won't be compiled in and the above file won't get installed.
 
> The man page still lists the "Name" option. 

i know. the code for it doesn't exist anymore though.

 
> Section "InputDevice"
>         Identifier  "Keyboard0"
>         Driver      "evdev"
>         Option      "XkbModel"  "evdev"
> EndSection
> 
> Section "InputDevice"
>         Identifier  "Mouse0"
>         Driver      "evdev"
> EndSection
> 
> Can somebody please write me a config to try out, double please?

Section "InputDevice"
  Identifier "kbd"
  Driver "evdev"
  Option "Device" "/dev/input/event0"
  Option "XkbModel" "evdev"
  Option "XkbLayout" "de"
  Option "XkbRules" "evdev"
EndSection


that should do the job IIRC

(In reply to comment #18)
> (In reply to comment #16)
> > > the most likely offender is x11-input.fdi 
> > There is no such file on my system.

found it in the policy directory of /usr/share/hal

> Section "InputDevice"
>   Identifier "kbd"
>   Driver "evdev"
>   Option "Device" "/dev/input/event0"
>   Option "XkbModel" "evdev"
>   Option "XkbLayout" "de"
>   Option "XkbRules" "evdev"
> EndSection
> 
> 
> that should do the job IIRC
> 

with this settings--also when trying a different eventX number--X crashes silently

(In reply to comment #19)
> with this settings--also when trying a different eventX number--X crashes
> silently

ouch. anything in the log files? can you install a server with debug symbols?

ping?

i have a serious problem with my crashing hal. the developer is still quite clueless. but i think that i should first solve this problem before i go on testing evdev since you said that evdev relies on hal.

hald is running again. however, there is no change. when i try your recommended configuration, the login manager (slim) doesn't even start. there's no warning or whatever to evdev in the logfile. the module gets loaded and that's it.

however, there's some problem between xorg and dbus, which may be related to this:

[config/dbus] couldn't take over org.x.config: org.freedesktop.DBus.Error.Access
Denied (Connection ":1.11" is not allowed to own the service "org.x.config.displ
ay0" due to security policies in the configuration file)

On Fri, Mar 14, 2008 at 10:52:03PM -0700, bugzilla-daemon@freedesktop.org wrote:
> however, there's some problem between xorg and dbus, which may be related to
> this:
> 
> [config/dbus] couldn't take over org.x.config:
> org.freedesktop.DBus.Error.Access
> Denied (Connection ":1.11" is not allowed to own the service
> "org.x.config.displ
> ay0" due to security policies in the configuration file)

That's just the D-Bus configuration API, not HAL, so don't worry.

Created attachment 15143 [details]
got a debug xorg-server running

I got a debug X running with the following config:

Section "InputDevice"
  Identifier "keyboard0"
  Driver "evdev"
  Option "Device" "/dev/input/event4"
  Option "XkbModel" "evdev"
  Option "XkbRules" "evdev"
  Option "XkbLayout" "de"
EndSection

Section "InputDevice"
	Identifier  "Mouse0"
	Driver      "evdev"
	Option      "Name"   "HID 04d9:0461"
EndSection

However, the keyboard was switched to us-layout though my system defaults to german layout, and many AltGr combinations, like the EURO symbol on key E, and shortkeys, like ALT-TAB or CTRL-ALT-BACKSPACE, did not work. This was especially frustrating because the mouse cursor did not move at all. The positive is that I got a debug server running. The logfile is quite noisy. Hope you understand it all...

Btw.: Why can't X find the XKB keymaps? I installed xkbdata, or do I miss something?

On Sat, Mar 15, 2008 at 08:29:16AM -0700, bugzilla-daemon@freedesktop.org wrote:
>   Option "XkbRules" "evdev"

This should be 'base', not 'evdev'.  This would be it couldn't compile
your keymap ...

this didn't change anything. is there something more to read about nationalization because of new packages, places or some hard entries in some scripts or so?

(In reply to comment #28)
> this didn't change anything. is there something more to read about
> nationalization because of new packages, places or some hard entries in some
> scripts or so?
> 

tbh, I'm losing track of what the actual problem is. Is it still the lack of arrow keys?


Reading through the log file I noticed "(EE) Mouse0: cannot open input pEvdev". Are you running evdev 1.1X? If so, please update to version 1.2, if not git master.

I just lost track of what could be the culprit because one keyboard worked half and the other not at all, etc. Still both, my cherry keyboard and my perixx mouse, don't want to work at all with evdev (I'm using only latest individual packages, like xf86-input-evdev-1.2.0):

Mouse with evdev:

Section "InputDevice"
	Identifier  "Mouse0"
	Driver      "evdev"
	Option      "Name"   "HID 04d9:0461"
EndSection

(**) Option "CorePointer"
(**) Mouse0: always reports core events
(EE) Mouse0: cannot open input pEvdev
(II) UnloadModule: "evdev"
(EE) PreInit returned NULL for "Mouse0"



Mouse without evdev:

Section "InputDevice"
	Identifier  "Mouse0"
	Driver "mouse"
	Option "Device" "/dev/psaux"
EndSection

(**) Mouse0: Device: "/dev/psaux"
(==) Mouse0: Protocol: "Auto"
(**) Option "CorePointer"
(**) Mouse0: always reports core events
(**) Option "Device" "/dev/psaux"
(==) Mouse0: Emulate3Buttons, Emulate3Timeout: 50
(**) Mouse0: ZAxisMapping: buttons 4 and 5
(**) Mouse0: Buttons: 9
(**) Mouse0: Sensitivity: 1



Keyboard with evdev:

Section "InputDevice"
 Identifier "keyboard0"
  Driver "evdev"
  Option "Device" "/dev/input/event4"
  Option "XkbModel" "evdev"
  Option "XkbRules" "base"
  Option "XkbLayout" "de"
EndSection

(**) Option "CoreKeyboard"
(**) keyboard0: always reports core events
(EE) keyboard0: cannot open input pEvdev
(II) UnloadModule: "evdev"
(EE) PreInit returned NULL for "keyboard0"



Keyboard without evdev:

Section "InputDevice"
	Identifier  "Keyboard0"
	Driver      "kbd"
	Option      "XkbModel"  "pc105"
	Option      "XkbLayout" "de"
EndSection

(**) Option "CoreKeyboard"
(**) Keyboard0: always reports core events
(**) Option "Protocol" "standard"
(**) Keyboard0: Protocol: standard
(**) Option "AutoRepeat" "500 30"
(**) Option "XkbRules" "xorg"
(**) Keyboard0: XkbRules: "xorg"
(**) Option "XkbModel" "pc105"
(**) Keyboard0: XkbModel: "pc105"
(**) Option "XkbLayout" "de"
(**) Keyboard0: XkbLayout: "de"
(**) Option "CustomKeycodes" "off"
(**) Keyboard0: CustomKeycodes disabled
(II) evaluating device (Keyboard0)
(II) XINPUT: Adding extended input device "Keyboard0" (type: KEYBOARD)



Interestingly, as I restarted xorg after testing with evdev and keyboard, I first got a black screen with lots of characters in line at the top, which looked like what I've typed in blindly the last run of xorg. This could mean that the keyboard was working but the events didn't make it through somehow? This phenomenon was repeatable.



Btw.: what's missing here? I've installed xkbdata and xkbcomp:

(WW) Couldn't load XKB keymap, falling back to pre-XKB keymap

(In reply to comment #30)
> I just lost track of what could be the culprit because one keyboard worked half
> and the other not at all, etc. Still both, my cherry keyboard and my perixx
> mouse, don't want to work at all with evdev (I'm using only latest individual
> packages, like xf86-input-evdev-1.2.0):
> 
> Mouse with evdev:
> 
> Section "InputDevice"
>         Identifier  "Mouse0"
>         Driver      "evdev"
>         Option      "Name"   "HID 04d9:0461"
> EndSection

evdev 1.2.0 doesn't take Name, you have to specify Device /dev/input/eventXXX
 
 
> Keyboard with evdev:
> 
> Section "InputDevice"
>  Identifier "keyboard0"
>   Driver "evdev"
>   Option "Device" "/dev/input/event4"
>   Option "XkbModel" "evdev"
>   Option "XkbRules" "base"
>   Option "XkbLayout" "de"
> EndSection
> 
> (**) Option "CoreKeyboard"
> (**) keyboard0: always reports core events
> (EE) keyboard0: cannot open input pEvdev
> (II) UnloadModule: "evdev"
> (EE) PreInit returned NULL for "keyboard0"

not sure here. only thing I could think of is /dev/input/event4 being the wrong device? Even if so, evdev should recognize it.

I got the mouse running but am wholly confused now. Are you really sure that evdev makes life easier? The problem on my system is that the paths to the event nodes aren't existing though the events are listed in proc. In case of the mouse, event3 worked because it was there. However, event4 and event5, which are both shown as related to the keyboard in proc, aren't existing in /dev/input. I tried the nodes in /dev/input/by-id and /dev/input/by-path but xorg complains about them:

(EE) ioctl EVIOCGBIT 0 failed: Inappropriate ioctl for device

I'd rather like to be able to use the nodes in /dev/input/by-id because they're unique. However, why are there no event4 and event5? There are also mice and mouse0 but no keyboard0 or similar. Is this a udev-related problem?

Update: I checked my old system, which runs an older version of udev. There are event4 and event5 but evdev doesn't work too. There's no by-id directory.

what the ... ????????

(In reply to comment #32)
> I got the mouse running but am wholly confused now. Are you really sure that
> evdev makes life easier? The problem on my system is that the paths to the
> event nodes aren't existing though the events are listed in proc. In case of
> the mouse, event3 worked because it was there. However, event4 and event5,
> which are both shown as related to the keyboard in proc, aren't existing in
> /dev/input. 

they may not be created automatically. an 
mknod event4 c major, minor 
should fix this. major has to be the same as the other event devices, minor is the next one in the sequence. repeat this for event5 as well.


> I tried the nodes in /dev/input/by-id and /dev/input/by-path but
> xorg complains about them:
> 
> (EE) ioctl EVIOCGBIT 0 failed: Inappropriate ioctl for device

if you ls -l /dev/input/by-id, you'll see that some links point to the mouseX nodes. Make sure that the nodes you specify are the ones that point to a eventX node, otherwise the evdev-specific ioctls will fail.


> 
> I'd rather like to be able to use the nodes in /dev/input/by-id because they're
> unique. However, why are there no event4 and event5? There are also mice and
> mouse0 but no keyboard0 or similar. Is this a udev-related problem?

IIRC the eventX nodes are created by the kernel evdev module. the mouseX nodes  by the mousedev module. keyboardX doesn't exist because of - well historical reasons. /dev/input/by-id is created by udev.

It was an udev problem. The keyboard is detected by evdev now. However, the server seems to have chosen the U.S layout. Arrow keys and other keys don't work at all or seem to be misconfigured. The weird thing is that this now happens even when I turn back to the KBD configuration. The server just seems to ignore my settings now. The Xorg.0.log seems to be from hell. There's unbelievable noise from hal in it, and I don't get through. Will disable the event device again, I think!

Created attachment 16335 [details]
the xorg log

Yes, xorg first takes my settings but then checks via hal and overwrites the layout settings with "us". It also recognizes the infrared device of my DVB-T card as a keyboard and sets the layout to "us" ;)

I think, the lines like:

FlushingSerial
WritingSerial: 0xff
ReadingSerial: 0xfa

are related to what I already wrote:

> Interestingly, as I restarted xorg after testing with evdev and keyboard, I
> first got a black screen with lots of characters in line at the top, which
> looked like what I've typed in blindly the last run of xorg. This could mean
> that the keyboard was working but the events didn't make it through somehow?
> This phenomenon was repeatable.

(In reply to comment #34)
> It was an udev problem. The keyboard is detected by evdev now. However, the
> server seems to have chosen the U.S layout. 

this is a hal setup issue. the server simply takes what hal tells it to. the matching file is /etc/hal/fdi/policy/x11-input.fdi, you can switch it to "de" there.


> Arrow keys and other keys don't work at all or seem to be misconfigured. 

this happens to me when gnome overwrites the x keyboard settings. does xfce do something similar? on one of my computers I actually had to remove the settings with gconf-editor and unset everything, for some reason merely setting it in the gnome dialog to evdev-managed-keyboard wasn't enough. 

In your case, could it be a stale configuration file from xfce overwrites the settings?

(In reply to comment #36)
> Yes, xorg first takes my settings but then checks via hal and overwrites the
> layout settings with "us". It also recognizes the infrared device of my DVB-T
> card as a keyboard and sets the layout to "us" ;)

blame the kernel evdev module for that. my mouse also appears as keyboard (and pointer).

I can't live with this answers because they draw the fatal conclusion to obey to whatever comes via hal instead of following the explicit choice of the admin. This is incapaciation! Especially in the case where evdev just kicks off kbd to ignore the admin's wish in full. What's the file xorg.conf for? Is it only a fragment anymore? Now I'm in the same situation Sergio is already in and can only do:

"Option" "AutoAddDevices" "False"

On my system there's the file:

/usr/share/hal/fdi/policy/10osvendor/10-x11-input.fdi

It's content doesn't show up any layout settings:

<?xml version="1.0" encoding="ISO-8859-1"?>
<deviceinfo version="0.2">
  <device>
    <!-- FIXME: Support tablets too. -->
    <match key="info.capabilities" contains="input.mouse">
      <merge key="input.x11_driver" type="string">mouse</merge>
      <match key="/org/freedesktop/Hal/devices/computer:system.kernel.name"
             string="Linux">
        <merge key="input.x11_driver" type="string">evdev</merge>
      </match>
    </match>

    <match key="info.capabilities" contains="input.keys">
      <!-- If we're using Linux, we use evdev by default (falling back to
           keyboard otherwise). -->
      <merge key="input.x11_driver" type="string">keyboard</merge>
      <match key="/org/freedesktop/Hal/devices/computer:system.kernel.name"
             string="Linux">
        <merge key="input.x11_driver" type="string">evdev</merge>
      </match>
    </match>
  </device>
</deviceinfo>

What's the next step here? I slowly loose condition. Seems that you've decided to make mandatory what is only half-baken and can only be known and configured by developers or involved parties. This is a real backstep to free source.

(In reply to comment #39)
> I can't live with this answers because they draw the fatal conclusion to obey
> to whatever comes via hal instead of following the explicit choice of the
> admin. This is incapaciation! Especially in the case where evdev just kicks off
> kbd to ignore the admin's wish in full. What's the file xorg.conf for? Is it
> only a fragment anymore? Now I'm in the same situation Sergio is already in and
> can only do:
> 
> "Option" "AutoAddDevices" "False"

we know of this issue, but our time is limited and we rely on others to prepare patches. the problem is simply that the evdev driver through the use of EVIOCGRAB removes the device from the normal keyboard/mouse. if you auto-add all devices through evdev (which is what the current hotplug code does), no physical device feeds into kbd anymore. It's still there, with all your configuration, but it never sends events.

The only way to avoid that is to stop evdev from adding keyboards.


> On my system there's the file:
> 
> /usr/share/hal/fdi/policy/10osvendor/10-x11-input.fdi
> 
> It's content doesn't show up any layout settings:

[snip]

Have a look at the following:
http://cgit.freedesktop.org/xorg/xserver/tree/config/x11-input.fdi

this is the current fdi file in git master, it shows the keys you can pass in. In your case, it is XkbLayout I guess.
This is your _only_ choice at the moment, other than disabling hotplug. sorry.

 
> What's the next step here? I slowly loose condition. Seems that you've decided
> to make mandatory what is only half-baken and can only be known and configured
> by developers or involved parties. This is a real backstep to free source.

we already know that, and we realise that it was released a bit prematurely. as of yet, there isn't much we can do other than bugfixing, but even there our time is limited.
 

I tried the fdi file and changed "us" to "de". I still get a us-keyboard layout. I installed xfce-xkb-switcher but it only shows "us" and "en_US" in the selection of available languages. I think, we stop here and wait until some of the master thinkers get aware that their path is guiding nowhere.

This sure was a nasty one to find.

The current x11-input.fdi states that the key to be used are input.x11_options.XkbLayout. but changing this to "de" doesn't work.

Turns out that HAL (on FC8 anyway) still sends the now deprecated "input.xkb_layout" key, and this defaults to "us". not sure where this can be changed, but I presume somewhere in hal.
you can test this by running hal-device and then searching for the keyboard and the values.

In the HAL option list, XkbLayout comes before xkb_layout. The way how options are added in the server, xkb_layout comes first in the linked list.

Evdev checks for "xkb_layout" first, and only if that fails for "XkbLayout". This can and should be changed, but doesn't have any effect.

When evdev checks for "XkbLayout", the server semantics for parsing config options result in "xkb_layout" and "XkbLayout" being the same (underscores and capitals are ignored). Thus the first entry that matches is returned, which is the "xkb_layout" entry.

Evdev thus initialises the keyboard with layout "us". Yay, we lose.


Dennis, Sergio:

Add this to your x11-input.fdi to get the correct layout. 
 <merge key="input.xkb.layout" type="string">de</merge>

This works for me (on the mpx branch, but that is close enough to git master that it shouldn't matter)

This sure was a nasty one to find.

The current x11-input.fdi states that the key to be used are input.x11_options.XkbLayout. but changing this to "de" doesn't work.

Turns out that HAL (on FC8 anyway) still sends the now deprecated "input.xkb_layout" key, and this defaults to "us". not sure where this can be changed, but I presume somewhere in hal.
you can test this by running hal-device and then searching for the keyboard and the values.

In the HAL option list, XkbLayout comes before xkb_layout. The way how options are added in the server, xkb_layout comes first in the linked list.

Evdev checks for "xkb_layout" first, and only if that fails for "XkbLayout". This can and should be changed, but doesn't have any effect.

When evdev checks for "XkbLayout", the server semantics for parsing config options result in "xkb_layout" and "XkbLayout" being the same (underscores and capitals are ignored). Thus the first entry that matches is returned, which is the "xkb_layout" entry.

Evdev thus initialises the keyboard with layout "us". Yay, we lose.


Dennis, Sergio:

Add this to your x11-input.fdi to get the correct layout. 
 <merge key="input.xkb.layout" type="string">de</merge>

This works for me (on the mpx branch, but that is close enough to git master that it shouldn't matter)

It even works with 1.4.0.90. However, the special keys (AltGr, PageUP, Arrow keys, etc.) still behave weird. AltGr is enter. PageDown opens the context menu. PageUP gives me a slash. The arrow keys are dead. Del doesn't work, etc. Xfce doesn't offer any special settings and seems to stay neutral here. At least, I don't know what to do next. Will still drop evdev for now...

There's something more...

The mouse cursor first appears at the center of the screen for a second but then jumps to top-center. It works afterwards, but???

The xorg.log is full of weird stuff. For example, event4 belongs to the keyboard, and event5 to, well, the keyboard (multimedia keys??). However, xorg recognizes this device as a keyboard but checks for a pointer and:

(II) HID 046a:0023: Found 1 mouse buttons
(II) HID 046a:0023: Configured 18 mouse buttons.

I don't understand a word in the xorg.log anymore. There's lots of more strange stuff like that the EDID-block is, first, not readable but, some lines later, printed in hex, etc. If you can read that, ok, I append it...

Created attachment 16402 [details]
the next xorg.log

(In reply to comment #45)
> There's something more...
> 
> The mouse cursor first appears at the center of the screen for a second but
> then jumps to top-center. It works afterwards, but???

if you look at the log for HID 04d9:0461, it configures it as relative, then overwrites it as absolute. I recently pushed a patch to evdev git master to avoid this.
This probably causes the jump, where the first event containing something like 0/1 is interpreted as absolute coordinates.

> The xorg.log is full of weird stuff. For example, event4 belongs to the
> keyboard, and event5 to, well, the keyboard (multimedia keys??). 

that's a kernel issue. I have a similar problem, where the multimedia keys of the keyboard are sent through the kernel device of the mouse.  

> However, xorg recognizes this device as a keyboard but checks for a pointer and:
> 
> (II) HID 046a:0023: Found 1 mouse buttons
> (II) HID 046a:0023: Configured 18 mouse buttons.

This may be evdev 1.2 getting a bit too excited. Most of that stuff has been removed from evdev 2.0, it caused more problems than it fixed.

> I don't understand a word in the xorg.log anymore. There's lots of more strange
> stuff like that the EDID-block is, first, not readable but, some lines later,
> printed in hex, etc. If you can read that, ok, I append it...

EDID is monitor data and irrelevant for this bug. Most of the other stuff is irrelevant as well, for us the interesting bits start when the HID messages come along (after all the AIGLX messages)


(In reply to comment #44)
> It even works with 1.4.0.90. 

cool. I found the problem in the server (parsing of arguments that were claimed as deprecated). So this part will be fixed in git master tomorrow or so, I just need to cherry-pick and test it.

> However, the special keys (AltGr, PageUP, Arrow
> keys, etc.) still behave weird. AltGr is enter. PageDown opens the context
> menu. PageUP gives me a slash. The arrow keys are dead. Del doesn't work, etc.
> Xfce doesn't offer any special settings and seems to stay neutral here. At
> least, I don't know what to do next. Will still drop evdev for now...

this means that the keymap is busted and I haven't found a reliable way to figure out why and how that happens. e.g. in my GNOME sometimes UP results in a print-screen command, DOWN is enter, etc. I can fix it by unsetting everything in gconf-editor, but since you use xfce this doesn't apply to you. sorry, I don't know what to do from here.

daniels: any hints?

(In reply to comment #42)
> The current x11-input.fdi states that the key to be used are
> input.x11_options.XkbLayout. but changing this to "de" doesn't work.
> 
> Turns out that HAL (on FC8 anyway) still sends the now deprecated
> "input.xkb_layout" key, and this defaults to "us". not sure where this can be
> changed, but I presume somewhere in hal.
> you can test this by running hal-device and then searching for the keyboard and
> the values.
> 
> In the HAL option list, XkbLayout comes before xkb_layout. The way how options
> are added in the server, xkb_layout comes first in the linked list.
> 
> Evdev checks for "xkb_layout" first, and only if that fails for "XkbLayout".
> This can and should be changed, but doesn't have any effect.
> 
> When evdev checks for "XkbLayout", the server semantics for parsing config
> options result in "xkb_layout" and "XkbLayout" being the same (underscores and
> capitals are ignored). Thus the first entry that matches is returned, which is
> the "xkb_layout" entry.

I'm really not sold on the change here.  Reason being that input.xkb.* is in the HAL spec, and the reason it was explicitly done outside input.x11_options is because projects like cxkb exist to have the same layout in the console as in X, and I'd definitely like to have unified console/X keyboard layouts.  So can we please keep special-casing those five options to this end?

On Tue, May 06, 2008 at 10:58:57PM -0700, bugzilla-daemon@freedesktop.org wrote:
> --- Comment #47 from Peter Hutterer <peter@cs.unisa.edu.au>  2008-05-06 22:58:55 PST ---
> (In reply to comment #45)
> > However, the special keys (AltGr, PageUP, Arrow
> > keys, etc.) still behave weird. AltGr is enter. PageDown opens the context
> > menu. PageUP gives me a slash. The arrow keys are dead. Del doesn't work, etc.
> > Xfce doesn't offer any special settings and seems to stay neutral here. At
> > least, I don't know what to do next. Will still drop evdev for now...
> 
> this means that the keymap is busted and I haven't found a reliable way to
> figure out why and how that happens. e.g. in my GNOME sometimes UP results in a
> print-screen command, DOWN is enter, etc. I can fix it by unsetting everything
> in gconf-editor, but since you use xfce this doesn't apply to you. sorry, I
> don't know what to do from here.

The problem you're seeing with GNOME is that once it's established a
grab, it'll store both the keycode and the keysym, and give the keycode
absolute precedence over the keysym, and refuse to rescan the map and
reassociate keysym -> keycode.  Sigh.

Created attachment 16423 [details] [review]
0001-config-deprecate-and-ignore-the-use-of-input.xkb.patch

This is the patch I put into mpx for the time being.

It removes some code marked as deprecated and stops the server from interpreting the input.xkb.whatever commands.

On Wed, May 07, 2008 at 06:42:03PM -0700, bugzilla-daemon@freedesktop.org wrote:
> Created an attachment (id=16423)
>  --> (http://bugs.freedesktop.org/attachment.cgi?id=16423)
> 0001-config-deprecate-and-ignore-the-use-of-input.xkb.patch
> 
> This is the patch I put into mpx for the time being.
> 
> It removes some code marked as deprecated and stops the server from
> interpreting the input.xkb.whatever commands.

Hrm, I'd prefer to have input.xkb.{m,l,v,o} be the primary keys, and
have input.x11_options be a backup for that, rather than the former
being deprecated, for the reasons I listed earlier ...

(In reply to comment #51)
> On Wed, May 07, 2008 at 06:42:03PM -0700, bugzilla-daemon@freedesktop.org
> wrote:
> > Created an attachment (id=16423) [details]
> >  --> (http://bugs.freedesktop.org/attachment.cgi?id=16423)
> > 0001-config-deprecate-and-ignore-the-use-of-input.xkb.patch
> > 
> > This is the patch I put into mpx for the time being.
> > 
> > It removes some code marked as deprecated and stops the server from
> > interpreting the input.xkb.whatever commands.
> 
> Hrm, I'd prefer to have input.xkb.{m,l,v,o} be the primary keys, and
> have input.x11_options be a backup for that, rather than the former
> being deprecated, for the reasons I listed earlier ...

Ah. Now I get your previous comment. I'll revert and put a different patch in.

Created attachment 16425 [details] [review]
0003-config-override-xkb_-r-m-l-v-with-Xkb-r-m-l-v-if.patch

Next version. Parsing through all option, not adding xkb_ options but tucking them aside for the time being, if necessary overriding them with Xkb options.

After all options were parsed, the xkb options are added manually.
Not pretty, but it works.

pushed as ff013b0da4e6d33b2b69ce1212e9bd62050574e1

did not use git yet and have to ask here. i got the xserver branch with "git clone" and tried to start autogen.sh. this breaks because of undefined constants like XTRANS_CONNECTION_FLAGS. do i first have to do something?

On Thu, May 08, 2008 at 08:36:34PM -0700, bugzilla-daemon@freedesktop.org wrote:
> did not use git yet and have to ask here. i got the xserver branch with "git
> clone" and tried to start autogen.sh. this breaks because of undefined
> constants like XTRANS_CONNECTION_FLAGS. do i first have to do something?

yeah, you'd need to install xorg-macros. Either through the package system or
by git clone git://anongit.freedesktop.org/git/xorg/util/macros and installing
this package.

are you building the whole server or just the driver? If you're building the
whole server, I recommend reading http://wiki.x.org/wiki/Development/git

Dennis, can you give us an update on this bug please? Did you ever manage to
compile the server?

wasn't in reach for some time. i installed evdev 1.99.4 and xorg-server-1.4.2 today--which seems to be the successor of 1.4.99.x ???

things work like always. seems that the server still ships with the old/original fdi-file. configuring it doesn't help, as always. did your patch make it in?

(In reply to comment #58)
> wasn't in reach for some time. i installed evdev 1.99.4 and xorg-server-1.4.2
> today--which seems to be the successor of 1.4.99.x ???
no , 1.4.99.x is pre 1.5, 1.4.2 is the bug fix of 1.4, xserver 1.5 is Xorg 7.4 when xserver 1.4.2 is Xorg 7.3.1 

i tried to install xorg-server 1.4.99.902 but ran into massive problems with dri2 and glx not working with current mesa. i wasn't able to deconfigure the problematic parts. if it doesn't crash here, it crashes there... i think i'll wait for the next release of mesa, which shall be out 'really' soon.

btw., with 1.4.2 it seems that even xkb now busts the keymap. at least some keys like PgUp and PgDn don't work as expected. looking into the xorg.log, evdev is not touching the keyboard config (i deleted the event node in /dev).

> --- Comment #60 from Dennis Heuer <dh@triple-media.com>  2008-06-14 08:32:20 PST ---
> i tried to install xorg-server 1.4.99.902 but ran into massive problems with
> dri2 and glx not working with current mesa. i wasn't able to deconfigure the
> problematic parts. if it doesn't crash here, it crashes there... i think i'll
> wait for the next release of mesa, which shall be out 'really' soon.

--disable-dri --disable-dri2 --disable-glx in the server avoids the problem.
You won't get glx, but at least you can build the server.

> btw., with 1.4.2 it seems that even xkb now busts the keymap. at least some
> keys like PgUp and PgDn don't work as expected. looking into the xorg.log,
> evdev is not touching the keyboard config (i deleted the event node in /dev).

Option "AutoAddDevices" False
in the server layout does the same, no need for deleting the event node :)

(In reply to comment #61)
> > --- Comment #60 from Dennis Heuer <dh@triple-media.com>  2008-06-14 08:32:20 

> --disable-dri --disable-dri2 --disable-glx in the server avoids the problem.
> You won't get glx, but at least you can build the server.

I did that, hrmmm??? However, the server now runs without glx and I can't see a difference. I have a Radeon 9250 and a Sempron 2.8GHz, and compositing just works without difference with or without DRI. Seems that I'd buy some new hardware :(

> Option "AutoAddDevices" False
> in the server layout does the same, no need for deleting the event node :)
> 

Thanks. It was already mentioned above somewhere but I forgot about it :(

Except of that the new install didn't overwrite the old fdi-file automatically, the keyboard now works with german layout--and without missing or misbehaving keys, as I can say so far 8)) and this all without configuration in xorg.conf.

Many thanks

Arghh, was too fast in making statements. AutoAddDevices was set to false. No, I still get the american layout with evdev, despite configuration in the fdi-file and in xorg.conf. We're at the beginning again :((

am not in reach for the next eight weeks. you'll have to solve this without testbed. sorry :(

> --- Comment #58 from Dennis Heuer <dh@triple-media.com>  2008-06-13 18:58:35 PST ---
> wasn't in reach for some time. i installed evdev 1.99.4 and xorg-server-1.4.2
> today--which seems to be the successor of 1.4.99.x ???
> 
> things work like always. seems that the server still ships with the
> old/original fdi-file. configuring it doesn't help, as always. did your patch
> make it in?

my patches are on git master, haven't tried to get them on 1.4. so you have to
apply them manually.

on another note, please post the output of hal-device, so we can make sure
it's feeding the right keys.

don't have the time to care about this anymore. lets wait for other people (hal, udev) to wake up and see the light...

have you had the chance to run a server 1.5 yet? still the same issues?

Created attachment 20012 [details]
hal-device output

yes and no. yes, i run xorg-server 1.5.1. no, nothing changed. attached is the hal-device output. is too long for me. will leave analysis to you.

Oh dear, this one is still open. 

Please download http://people.freedesktop.org/~whot/evtest.c, compile it with
"gcc -o evtest evtest.c" and then run it as root with "./evtest
/dev/input/eventX" where X is the number for the device. You can get the
number by looking at /proc/bus/input/devices. Then attach the output of evtest
here.

That way we can finally figure out if we're getting the right stuff from the
kernel.

Created attachment 21284 [details]
the evtest.c output

You're still working on it. Quite a brave man you are. I didn't care anymore. The old drivers work for me. Btw.: Will Xorg make the step to devkit or is that off topic?

The event is event4. The output always stops as it did in the attached file, no matter how long I wait.

Regards,
Dennis

> The event is event4. The output always stops as it did in the attached file, no
> matter how long I wait.

keep hitting keys, that should fill up the log.

Created attachment 21324 [details]
the next evtest.c output

It seemed to do it all itself. However, now I pressed all keys in no other specific order than beginning from the left (some twice??). This should be complete now...

right. and which keys exactly don't work now?
what's the xev output for these keys?
(that's assuming a vanilla setup without AutoAddDevices "off")
does it work in the us keyboard layout?
what's the output of xprop -root | grep XKB and the output of setxkbmap
-print?

sorry, but there's so many comments in this bug that I've long lost track. 

>> sorry, but there's so many comments in this bug that I've long lost track.

Zes, it seems so. There|s onlz one problem with the kezmap, and that is the american lazout, as zou can see. Considering xorg|s choice of the american lazout, xev shows the correct kez values except for the multimedia kezs, which all show this>

KeyPress event, serial 32, synthetic NO, window 0x2200001,
    root 0x89, subw 0x0, time 1136705, (29,113), root:(740,606),
    state 0x0, keycode 171 (keysym 0x0, NoSymbol), same_screen YES,
    XLookupString gives 0 bytes: 
    XFilterEvent returns: False

However, the real problem is that evdev doesn|t respect mz locale. And, when I trz to switch the locale with the locale switcher on mz panel, the switcher displazs onlz one single option> @UNKNOWN@

Seems that the desktop is reallz confused about what to choose *I use Xfce 4.4(

There|s no output for xprop -root | grep XKB
xsetxkbmap -print shows:

Couldn't interpret _XKB_RULES_NAMES property
Use defaults: rules - 'xorg' model - 'pc105' layout - 'us'
xkb_keymap {
        xkb_keycodes  { include "xfree86+aliases(qwerty)"       };
        xkb_types     { include "complete"      };
        xkb_compat    { include "complete"      };
        xkb_symbols   { include "pc/pc(pc105)+pc/us"    };
        xkb_geometry  { include "pc(pc105)"     };
};

Does evdev need some xorg librarz installed, which is not neccessarilz needed for the old drivers to work_

> Zes, it seems so. There|s onlz one problem with the kezmap, and that is the
> american lazout, as zou can see. Considering xorg|s choice of the american
> lazout, xev shows the correct kez values except for the multimedia kezs, which
> all show this>

we don't pick a keyboard layout (unless none is provided at all). In most
setups, the keyboard layout is either set in the xorg.conf, or it is set in
the FDI file that HAL uses to inform the X server about the devices available.
Fedora for example pulls the keyboard layout from /etc/sysconfig/keyboard.

> KeyPress event, serial 32, synthetic NO, window 0x2200001,
>     root 0x89, subw 0x0, time 1136705, (29,113), root:(740,606),
>     state 0x0, keycode 171 (keysym 0x0, NoSymbol), same_screen YES,
>     XLookupString gives 0 bytes: 
>     XFilterEvent returns: False

this means that you're not pulling in the inet symbols. which is rather
surprising, considering xkeyboard-config pulls them in for all models. please
try installing xkeyboard-config 1.4, it fixes other issues with evdev.
 
> However, the real problem is that evdev doesn|t respect mz locale. And, when I
> trz to switch the locale with the locale switcher on mz panel, the switcher
> displazs onlz one single option> @UNKNOWN@

evdev doesn't have any business with your locale. as said above, it takes
whatever HAL tells it to.

On Sun, Dec 21, 2008 at 03:14:44AM -0800, bugzilla-daemon@freedesktop.org wrote:
> --- Comment #76 from Peter Hutterer <peter.hutterer@who-t.net>  2008-12-21 03:14:44 PST ---
> > However, the real problem is that evdev doesn|t respect mz locale. And, when I
> > trz to switch the locale with the locale switcher on mz panel, the switcher
> > displazs onlz one single option> @UNKNOWN@
> 
> evdev doesn't have any business with your locale. as said above, it takes
> whatever HAL tells it to.

Your switcher is broken.  Make sure xkeyboard-config is 1.4 or above,
then run:
setxkbmap -rules base -model evdev -layout de

And happiness should ensue.

> > > trz to switch the locale with the locale switcher on mz panel, the switcher
> > > displazs onlz one single option> @UNKNOWN@
> > 
> > evdev doesn't have any business with your locale. as said above, it takes
> > whatever HAL tells it to.

Please, zou better start reading from the top of this bug report again because we were through this all alreadz. The fdi file is set to |de|.

> 
> Your switcher is broken.

I doubt that!

>  Make sure xkeyboard-config is 1.4 or above,

Did so. Does it need more or does it conflict with older xkb/installs_

> then run:
> setxkbmap -rules base -model evdev -layout de

I tried the above line, which configures the driver with exactlz the same values as I|ve written in mz xorg.conf file,  but got an error message>

Error loading new keyboard description

In the Xlog, there is>

(EE) Error loading keymap /opt/interface/xorg-7.4/share/X11/xkb/compiled/server-0.xkm

The directorz is emptz

> And happiness should ensue.

not at all!

Please, developers tend to use quite optimistic imperatives. This is in most cases not appropriate. However, thanks for zour help.


Btw.> There are still quite old autoconf macros around. So too in the case of xkezboard/config, for example> I then must edit the configure script manuallz. Possiblz zou can send a call through the xorg developer communitz that some update is outstanding>

checking for intltool >= 0.30... head: `-1' option is obsolete; use `-n 1'
Try `head --help' for more information.
 found
configure: error: Your intltool is too old.  You need intltool 0.30 or later.


Here again we have this problem with the imperatives. There are so manz of them used quite stupidlz out there...

(In reply to comment #78)
> >  Make sure xkeyboard-config is 1.4 or above,
> 
> Did so. Does it need more or does it conflict with older xkb/installs_
> 
> > then run:
> > setxkbmap -rules base -model evdev -layout de
> 
> I tried the above line, which configures the driver with exactlz the same
> values as I|ve written in mz xorg.conf file,  but got an error message>
> 
> Error loading new keyboard description
> 
> In the Xlog, there is>
> 
> (EE) Error loading keymap
> /opt/interface/xorg-7.4/share/X11/xkb/compiled/server-0.xkm
> 
> The directorz is emptz

Right. I _think_ this means that the server and xkeyboard-config use different directories or install paths. Did you configure xkeyboard-config with the same prefix as the x server?

> Btw.> There are still quite old autoconf macros around. So too in the case of
> xkezboard/config, for example> I then must edit the configure script manuallz.
> Possiblz zou can send a call through the xorg developer communitz that some
> update is outstanding>

please open a bugreport for this with the bug attached, or (for patches like this even better) send it to xorg@freedesktop.org

> Right. I _think_ this means that the server and xkeyboard-config use different
> directories or install paths. Did you configure xkeyboard-config with the same
> prefix as the x server?

It|s all in the same directorz. I reinstalled it with all compat/options on and also reinstalled xkbcomp, if that is of anz relation to this problem, but the result is the same.

Is this bug similar to Bug #19395?

i got xorg-server-1.8 with support for udev running and, what shall i say, there is the keyboard and there is the mouse. both work fine for some minutes now. no locale problem at all. ok, i have to set the locale in xorg.conf. the xorg protocol looks quite normal:

[   411.868] (**) Option "CorePointer"
[   411.868] (**) Mouse0: always reports core events
[   411.868] (**) Mouse0: Device: "/dev/input/event2"
[   411.868] (II) Mouse0: Found 3 mouse buttons
[   411.868] (II) Mouse0: Found scroll wheel(s)
[   411.868] (II) Mouse0: Found relative axes
[   411.868] (II) Mouse0: Found x and y relative axes
[   411.868] (II) Mouse0: Found absolute axes
[   411.868] (II) Mouse0: Configuring as mouse
[   411.868] (**) Mouse0: YAxisMapping: buttons 4 and 5
[   411.868] (**) Mouse0: EmulateWheelButton: 4, EmulateWheelInertia: 10, EmulateWheelTimeout: 200
[   411.868] (II) XINPUT: Adding extended input device "Mouse0" (type: MOUSE)
[   411.868] (II) Mouse0: initialized for relative axes.
[   411.868] (WW) Mouse0: ignoring absolute axes.
[   411.868] (**) Option "CoreKeyboard"
[   411.868] (**) keyboard0: always reports core events
[   411.868] (**) keyboard0: Device: "/dev/input/event3"
[   411.868] (II) keyboard0: Found keys
[   411.868] (II) keyboard0: Configuring as keyboard
[   411.868] (II) XINPUT: Adding extended input device "keyboard0" (type: KEYBOARD)
[   411.868] (**) Option "xkb_rules" "evdev"
[   411.868] (**) Option "xkb_model" "evdev"
[   411.868] (**) Option "xkb_layout" "de"
[  1050.658] (II) Mouse0: Device reopened after 1 attempts.
[  1050.659] (II) keyboard0: Device reopened after 1 attempts.

doom to HAL!

i think we can close this bug now...

(In reply to comment #82)
> i think we can close this bug now...
> 
great, thanks for the followup.