Summary: | x11-drivers/xf86-input-evdev-2.1.0 produces duplicated keyboard events | ||
---|---|---|---|
Product: | Gentoo Linux | Reporter: | Simeon Maryasin <marsoft> |
Component: | Current packages | Assignee: | Gentoo Linux bug wranglers <bug-wranglers> |
Status: | RESOLVED WORKSFORME | ||
Severity: | normal | ||
Priority: | High | ||
Version: | unspecified | ||
Hardware: | All | ||
OS: | Linux | ||
Whiteboard: | |||
Package list: | Runtime testing required: | --- | |
Attachments: |
xorg.conf
my HAL policy for input devices (in fact, it is only file in /etc/hal/fddi/policy/) HAL policy (correct mime-type) |
Description
Simeon Maryasin
2008-12-20 16:48:03 UTC
Most likely not a bug, but a problem with your configuration. If you still have entries in your xorg.conf for your keyboard, instead of simply configuring it in hal, that's probably the source of those duplicates. no, i have already commented out all input-related parts of xorg.conf, and configured that via hal. i'll attach my xorg.conf and 10-x11-input.fdi policy. Created attachment 175963 [details]
xorg.conf
Created attachment 175964 [details]
my HAL policy for input devices (in fact, it is only file in /etc/hal/fddi/policy/)
Created attachment 175965 [details]
HAL policy (correct mime-type)
Did you restart X after those changes, cause your xorg.cong looks unusable: 'Option "AllowEmptyInput" "false"' and no input sections don't go together ? Try removing the Option. Furthermore, evdev driver doesn't have SHMConfig option. That one is for synaptics, AFAIK. That is strange, but I am using exactly this configuration, and it works. AFAIK, X-server connects HAL input devices before checking "EmptyInputs", and it will fail only if there aren't any InputDevice section AND Hal couldn't detect any device. I placed this option in order to not get started X which doesn't see my keyboard. And, yes, I placed SHMConfig when I used synaptics driver for my touchpad, but later I changed it to evdev but forgot about that option. OK, you're probably right, but I think that recently (IOW in 1.5.3) that option began to mean something more. Anyway see how many devices are printed by 'hal-find-by-capability --capability input.keys' and check the settings of those devices. See also your xorg log for multiple adding of a single device. If it looks trivial for you, it should be mentioned that 'Option "AllowEmptyInput" "false"' should *not* be added to xorg.conf when all InputDevice setions have been erased -- hence when already using evdev. I've been caught in that trap because I saw all over the place that Option had to be added. But the reason why *I* had no keyboard was because I had emerged >udev-125 (indirectly required for OpenRC-4*). And those udev versions don't play well with HAL. The result and symptoms, even if X uses evdev, are the same: no input device. So it should be noted that if xorg is already using evdev *and* there is no InputDevice section in xorg.conf, the problem won't be fixed by adding the former Option and it'll be even worse to add it. Just wanted to add my 2¢... It's very strange, but I removed "Option AllowEmptyInput" line, and now all works OK... |