Summary: | x11-drivers/xf86-input-evdev-1.2.0: cursor keys cease to work | ||
---|---|---|---|
Product: | Gentoo Linux | Reporter: | Martin von Gagern <Martin.vGagern> |
Component: | [OLD] Unspecified | Assignee: | Piotr JaroszyĆski (RETIRED) <peper> |
Status: | RESOLVED DUPLICATE | ||
Severity: | major | CC: | m.geerlings |
Priority: | High | ||
Version: | 2007.0 | ||
Hardware: | All | ||
OS: | Linux | ||
Whiteboard: | |||
Package list: | Runtime testing required: | --- | |
Attachments: |
Diff of startx -- -logverbose
xorg.conf |
Description
Martin von Gagern
2008-01-09 15:33:02 UTC
(In reply to comment #0) > Might be because of a ButtonMapping that stopped working, I don't know. Yes, that's it, the official second mouse button works all right. I could reproduce this button mapping issue with a simple Xsession using XSESSION=/etc/X11/Sessions/Xsession. The cursor keys, however, worked all right in this environment, so I guess my default WM, KDE, might be involved somehow as well. On KDE the issue is perfectly reproducable and seems to affect all applications. Created attachment 140549 [details, diff]
Diff of startx -- -logverbose
This diff shows the relevant differences between two runs of Xorg. The first one is with the new evdev-1.2.0, exhibiting the issues described above. The second run is with the working evdev-1.1.5-r2. I stripped out irrelevant differences like different time and changed video memory addresses.
Created attachment 140551 [details]
xorg.conf
This is my xorg.conf. I didn't feel like cleaning it up, so please don't get confused by all the junk in this file.
I read a bit of man page and now I've got the impression that the main problem is that evdev grabs the devices before kbd or mouse do, but the old configuration sections don't apply, and stuff like button mapping isn't even supported by the evdev driver. Thus the main question is: how to prevent evdev from stealing devices from other, more seasoned drivers, and can this be done by default or do we need a message in the ebuild? This is related to bug #200087. Upgrading to hal-0.5.10 introduced the same behavior for me. The evdev module is loaded by hal, and mixes up various keycodes. I temporarily solved this by unmerging xf86-input-evdev (my setup doesn't need it), but blocking >=hal-0.5.10 should also work. In my opinion it is unacceptable to depend on a hal xml-config file for the X11 keyboard layout, that's just crap. xorg.conf is ok and should be the prime configuration source. One further reason against HAL. Unfortunately it's their opinion that matters, and we're stuck with configuring input separately from everything else in a HAL FDI file. *** Bug 208424 has been marked as a duplicate of this bug. *** Well, this is not an evdev bug. See Bug 204128 Comment #20, namely the NO "InputDevice" section in xorg.conf at all - IMPORTANT!!! part ;) *** This bug has been marked as a duplicate of bug 200061 *** I had disabled evdev-1.2.0 back then, and hit the issue today again with x11-drivers/xf86-input-evdev-1.99.2-r2. I found the correct solution for me in bug 200061 comment 18: KDE has to have keyboard model set to evdev. Just to give people reading this here one more reference. |