From Fedora Project Wiki
< Xorg
m (collapse items) |
mNo edit summary |
||
| Line 12: | Line 12: | ||
# is the device listed in <code>lshal</code>? no? -> '''kernel''' | # is the device listed in <code>lshal</code>? no? -> '''kernel''' | ||
# is the devices listed with an <code>input.x11_driver</code> in <code>lshal</code>? no? -> '''hal configuration issue''' | # is the devices listed with an <code>input.x11_driver</code> in <code>lshal</code>? no? -> '''hal configuration issue''' | ||
# any <code>input.x11_options</code> by the user? no? - '''hal configuration issue'''. | # any <code>input.x11_options</code> by the user? no? - '''hal configuration issue'''. These are hard because they’re usually typos that are hard to spot, but you can probably punt the user to the input device configuration wiki page and let them sort it out themselves. | ||
These are hard because they’re usually typos that are hard to spot, but you can probably punt the user to the input device configuration wiki page and let them sort it out themselves. | |||
# if the Xorg.log lists the device when it appears and says “don’t know how to use device” that means the device is not detected by <code>evdev</code>. It shouldn’t happen with <code>>= F11</code> or rawhide, can still happen with <code>F10</code>. If it happens with <code>> F11</code>, its a bug that needs to be fixed upstream (and in that case I always need the output from http://people.freedesktop.org/~whot/evtest.c) I use output of <code>evtest</code> to write software test devices to simulate the hardware. the repository for that is at [git://people.freedesktop.org/~whot/testdevices.git git://people.freedesktop.org/~whot/testdevices.git], if the user can program, it’s quite simple to add new devices. (but of course, we should ask them first, and not push mere users to programming). If the device doesn’t send events or doesn’t behave properly, always check the evtest output too. If that one is busted, it’s a kernel or hardware issue. If evtest looks normal, but the server jumps it’s a server issue, often pointer acceleration or scaling | # if the Xorg.log lists the device when it appears and says “don’t know how to use device” that means the device is not detected by <code>evdev</code>. It shouldn’t happen with <code>>= F11</code> or rawhide, can still happen with <code>F10</code>. If it happens with <code>> F11</code>, its a bug that needs to be fixed upstream (and in that case I always need the output from http://people.freedesktop.org/~whot/evtest.c) I use output of <code>evtest</code> to write software test devices to simulate the hardware. the repository for that is at [git://people.freedesktop.org/~whot/testdevices.git git://people.freedesktop.org/~whot/testdevices.git], if the user can program, it’s quite simple to add new devices. (but of course, we should ask them first, and not push mere users to programming). If the device doesn’t send events or doesn’t behave properly, always check the evtest output too. If that one is busted, it’s a kernel or hardware issue. If evtest looks normal, but the server jumps it’s a server issue, often pointer acceleration or scaling | ||
Revision as of 15:37, 25 June 2009
Most evdev bugs aren’t actually evdev bugs. they tend to get caught before the releases. They’re either configuration issues (HAL, usually) or server bugs. especially when it comes to keyboard layouts etc., it’s nearly always server.
Also, there are almost no xorg-x11-drv-{mouse,keyboard} bugs. User has to have AutoAddDevices "off", or "AllowEmptyInput" "off" in the config file, so nobody without xorg.conf will use them.
Real evdev bugs are usually when over time something degenerates, when the pointer jumps after pressing a button, things like that, or when the server says “don’t know how to use device” (in Xorg.*.log).
Therefore most input device bugs are in the xorg-x11-server component, assigned to peter.
How to spread bugs between evdev and -mouse or -keyboard
- is the device listed in
/proc/bus/input/devices? no? -> kernel - is the device listed in
lshal? no? -> kernel - is the devices listed with an
input.x11_driverinlshal? no? -> hal configuration issue - any
input.x11_optionsby the user? no? - hal configuration issue. These are hard because they’re usually typos that are hard to spot, but you can probably punt the user to the input device configuration wiki page and let them sort it out themselves. - if the Xorg.log lists the device when it appears and says “don’t know how to use device” that means the device is not detected by
evdev. It shouldn’t happen with>= F11or rawhide, can still happen withF10. If it happens with> F11, its a bug that needs to be fixed upstream (and in that case I always need the output from http://people.freedesktop.org/~whot/evtest.c) I use output ofevtestto write software test devices to simulate the hardware. the repository for that is at git://people.freedesktop.org/~whot/testdevices.git, if the user can program, it’s quite simple to add new devices. (but of course, we should ask them first, and not push mere users to programming). If the device doesn’t send events or doesn’t behave properly, always check the evtest output too. If that one is busted, it’s a kernel or hardware issue. If evtest looks normal, but the server jumps it’s a server issue, often pointer acceleration or scaling
Synaptics bugs
Another thing about evtest—synaptics won’t spit out any events to evtest while X is running because the device file is grabbed. so you need to VT switch away to get the events from the hardware. For evdev devices, that’s not a problem (now, evdev used to grab too until mid-F10).
- anything that says input.capabilities input.touchpad in lshal uses synaptics.
- anything else, evdev