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.
(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.
