Gentoo Websites Logo
Go to: Gentoo Home Documentation Forums Lists Bugs Planet Store Wiki Get Gentoo!
Bug 205077 - x11-drivers/xf86-input-evdev-1.2.0: cursor keys cease to work
Summary: x11-drivers/xf86-input-evdev-1.2.0: cursor keys cease to work
Status: RESOLVED DUPLICATE of bug 200061
Alias: None
Product: Gentoo Linux
Classification: Unclassified
Component: [OLD] Unspecified (show other bugs)
Hardware: All Linux
: High major (vote)
Assignee: Piotr Jaroszyński (RETIRED)
: 208424 (view as bug list)
Depends on:
Reported: 2008-01-09 15:33 UTC by Martin von Gagern
Modified: 2008-06-14 09:24 UTC (History)
1 user (show)

See Also:
Package list:
Runtime testing required: ---

Diff of startx -- -logverbose (Xorg.log.evdev.diff,2.19 KB, patch)
2008-01-09 16:00 UTC, Martin von Gagern
Details | Diff
xorg.conf (xorg.conf,7.92 KB, text/plain)
2008-01-09 16:03 UTC, Martin von Gagern

Note You need to log in before you can comment on or make changes to this bug.
Description Martin von Gagern 2008-01-09 15:33:02 UTC
After updating xf86-input-evdev to 1.2.0, my X started to behave strangely:
* Cursor keys or anything else from that block between the letter block and the
  numeric block didn't work.
* The numeric block with NumLock off seemed to work at times, but not reliably.
* I managed to get the NumLock state and LED out of sync, so I reached a state
  where the LED was off but the keys still typed numbers.
* Pasting with my mouse didn't work either, though scrolling worked all right.
  Might be because of a ButtonMapping that stopped working, I don't know.

Both my keyboard and mouse are old-fashioned PS/2. The USB Wacom Graphire for which I have the evdev driver installed wasn't even connected at that time.
Downgrading to 1.1.5-r2 solved the issue.

I guess you'll probably need more information to investigate this issue. Right now I haven't even the slightest clue as to how this could happen, so I don't know what kind of information I could provide you with. I'll attach information as I can think of it, but if there is anything you could use, simply tell me.
Comment 1 Martin von Gagern 2008-01-09 15:58:01 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.
Comment 2 Martin von Gagern 2008-01-09 16:00:56 UTC
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.
Comment 3 Martin von Gagern 2008-01-09 16:03:30 UTC
Created attachment 140551 [details]

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.
Comment 4 Martin von Gagern 2008-01-09 16:22:44 UTC
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?
Comment 5 Andreas Arens 2008-01-09 18:15:41 UTC
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.

Comment 6 Donnie Berkholz (RETIRED) gentoo-dev 2008-01-10 01:15:01 UTC
Unfortunately it's their opinion that matters, and we're stuck with configuring input separately from everything else in a HAL FDI file.
Comment 7 Mike Auty (RETIRED) gentoo-dev 2008-02-01 18:58:45 UTC
*** Bug 208424 has been marked as a duplicate of this bug. ***
Comment 8 Jakub Moc (RETIRED) gentoo-dev 2008-02-21 19:54:32 UTC
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 ***
Comment 9 Martin von Gagern 2008-06-14 09:24:11 UTC
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.