From Fedora Project Wiki
(remove hal bits, hal's dead. whoopdidoo.)
(move hal bits to a fedora 12 section)
Line 23: Line 23:


# is the device listed in <code>/proc/bus/input/devices</code>? no? -> '''kernel'''
# is the device listed in <code>/proc/bus/input/devices</code>? no? -> '''kernel'''
# is the device listed in <code>lshal</code>? no? -> '''kernel'''
# does the device match any InputClass sections in /etc/xorg.conf.d/? no? -> '''configuration issue'''
# are there any user-configured options in the xorg.conf or /etc/xorg.conf.d but they're not merged? -> '''configuration issue''' or '''xorg-x11-server'''
# 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 <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) 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]], 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
 
=== Fedora 12 or earlier ===
# 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'''. These are hard because they’re usually typos that are hard to spot, but you can probably punt the user to the [https://fedoraproject.org/wiki/Input_device_configuration input device configuration] wiki page and let them sort it out themselves.
# 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 [https://fedoraproject.org/wiki/Input_device_configuration 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 <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) 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]], 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 ==
== Synaptics bugs ==

Revision as of 23:35, 16 February 2010

General overview

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 these drivers.

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.

Keyboard layouts

  • Some modifier keys stop working, some keys don't repeat, etc. => xorg-x11-server. This must have a simple, seproducible test case, it's near-impossible to debug otherwise. Things like "do something for 20 minutes and then it stops working" isn't enough.
  • A keyboard layout works, but one or two keys provide the wrong symbols => xkeyboard-config, should usually be upstreamed, Peter hands the decisions on layout changes to the upstream maintainer.
  • The user-selected layout does not apply => configuration issue, gnome-settings-daemon, gdm or xorg-x11-server.
    • Does the layout from /etc/sysconfig/keyboard show up in the Xorg.log file (only for keyboard devices, devices like the Power Button or Video Bus stay on 'us')? no? => system-setup-keyboard
    • Do user-configured options (in custom .fdi files) show up in the Xorg.log file? no? => hal configuration needs porting to xorg.conf format.
    • Do user-configured options (in xorg.conf/xorg.conf.d) show up in the Xorg.log file? no? => xorg-x11-server
    • Does the layout work in a plain X session (yum install xterm && sudo init 3 && xinit --)? no? => xorg-x11-server
    • Does the layout work in a plain X session but stops working after login? => gnome-settings-daemon or possibly gdm
  • Arrow keys broken (up == printscreen): this is caused by an xfree86 (or "base") ruleset for an evdev device. The cause of this is almost always a stray AllowEmptyInput "off" in the config (which is nearly always a wrong configuration). Removing the option fixes it.

How to spread bugs between evdev, -mouse or -keyboard and kernel

  1. is the device listed in /proc/bus/input/devices? no? -> kernel
  2. does the device match any InputClass sections in /etc/xorg.conf.d/? no? -> configuration issue
  3. are there any user-configured options in the xorg.conf or /etc/xorg.conf.d but they're not merged? -> configuration issue or xorg-x11-server
  4. 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 >= F11 or rawhide, can still happen with F10. 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) I use output of evtest to write software test devices to simulate the hardware. the repository for that is at [[1]], 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

Fedora 12 or earlier

  1. is the devices listed with an input.x11_driver in lshal? no? -> hal configuration issue
  2. any input.x11_options 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.

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

  1. anything that says input.capabilities input.touchpad in lshal uses synaptics.
  2. anything else, evdev
Retrieved from "https://fedoraproject.org/w/index.php?title=Xorg/Input_Triage_Algorithm&oldid=153780"