From Fedora Project Wiki
(mark as ready for wrangler)
(update to reflect the new behaviours (no grabbing from evdev))
 
(2 intermediate revisions by one other user not shown)
Line 11: Line 11:
== Current status ==
== Current status ==
* Targeted release: [[Releases/{{FedoraVersion||next}} | {{FedoraVersion|long|next}} ]]  
* Targeted release: [[Releases/{{FedoraVersion||next}} | {{FedoraVersion|long|next}} ]]  
* Last updated: 2008-09-01
* Last updated: 2008-10-22
* Percentage of completion: 100%
* Percentage of completion: 100%


Line 19: Line 19:
(The original version of this text is available [http://who-t.blogspot.com/2008/07/input-configuration-in-nutshell.html here].)
(The original version of this text is available [http://who-t.blogspot.com/2008/07/input-configuration-in-nutshell.html here].)


Traditionally, the X server used the mouse or the keyboard input drivers. With X11R7.3, the evdev driver became more prominent. F10 now uses the evdev driver as standard driver for all mouse and keyboard devices and provides the necessary hotplugging facilities to detect the devices at run-time. The mouse and kbd drivers are essentially obsolete now.
Traditionally, the X server used the mouse or the keyboard input drivers. With X11R7.3, the evdev driver became more prominent. F10 now uses the evdev driver as standard driver for all mouse and keyboard devices and provides the necessary hotplugging facilities to detect the devices at run-time. The mouse and kbd drivers are essentially obsolete now and are disabled in the default settings.  


=== A quick overview of the evdev input driver ===
=== A quick overview of the evdev input driver ===
[http://cgit.freedesktop.org/xorg/driver/xf86-input-evdev/ xf86-input-evdev] is the hotplugging-capable input driver to be used for mice and keyboards (and other devices, if appropriate). One main difference is that it uses devices files such as /dev/input/event0 instead of /dev/input/mouse0 (like the mouse driver does for example). The other big difference is that it can query the kernel about the capabilities about each device and set up itself correctly. So if you point a device to /dev/input/event0, it will automatically set itself up as mouse or keyboard, as appropriate.
[http://cgit.freedesktop.org/xorg/driver/xf86-input-evdev/ xf86-input-evdev] is the hotplugging-capable input driver to be used for mice and keyboards (and other devices, if appropriate). One main difference is that it uses devices files such as /dev/input/event0 instead of /dev/input/mouse0 (like the mouse driver does for example). The other big difference is that it can query the kernel about the capabilities about each device and set up itself correctly. So if you point a device to /dev/input/event0, it will automatically set itself up as mouse or keyboard, as appropriate.
The second important thing is that it puts a grab on the device file (not the same as a pointer/keyboard grab in X!). This grab gives us two benefits: the device will not send events to the collector devices (e.g. /dev/input/mice) anymore. And if anyone else tries to grab the device they will fail. So we can ensure that only one process receives events from this device.


=== How to set up input hotplugging ===
=== How to set up input hotplugging ===
Line 37: Line 36:
=== What to do with the xorg.conf ===
=== What to do with the xorg.conf ===
Input device configuration in the xorg.conf is obsolete if hotplugging is used.
Input device configuration in the xorg.conf is obsolete if hotplugging is used.
Remember, we have two configuration files now. One is xorg.conf, the other one is the fdi file. Since they don't know about each other, interesting results can be observed. The server parses xorg.conf first, then gets the devices through HAL. And here we have a big culprit: if add a InputDevice section with the mouse driver, it will conflict with the evdev driver. Evdev grabs the files, remember? So when all mice are added through the HAL evdev hotplugging mechanism, all mice stop sending to the /dev/input/mice file. So although you still have a valid input device in the server, it will never emit any events.
Remember, we have two configuration files now. One is xorg.conf, the other one is the fdi file, but both don't know about each other. The server parses xorg.conf first, then gets the devices through HAL. And here we have a big culprit: if you add a InputDevice section with the mouse driver, it will conflict with the evdev driver.
So when all mice are added through the HAL evdev hotplugging mechanism, their events are not only sent through the respective /dev/input/eventX file, but also through /dev/input/mouseX and /dev/input/mice. Hence, if you have devices using the mouse or kbd driver in your xorg.conf, you will get duplicate events. As a result, by default devices using the mouse/kbd drivers are disabled and only those devices added through HAL are enabled.


The best solution for most configuration is to simply remove the input-related configurations in the ServerLayout and the xorg.conf file. If you have specific options for devices, you can add them by merging the respective keys in the fdi file.
The best solution for most configurations is to simply remove the input-related configurations in the ServerLayout and the xorg.conf file. If you have specific options for devices, you can add them by merging the respective keys in the fdi file.
Alternatively, if you need to use the kbd or mouse drivers, you can disable hotplugging alltogether by adding Option "AutoAddDevices" "off" in your ServerLayout.
Alternatively, if you need to use the kbd or mouse drivers, you can disable hotplugging altogether by adding Option "AutoAddDevices" "off" in your ServerLayout.
 
You can still configure evdev, wacom or synaptics devices in the xorg.conf but it is discouraged. Devices specified in the xorg.conf are not hotplug-capable and you cannot add the device at runtime.


You are free to configure evdev, wacom or synaptics devices in the xorg.conf. These drivers won't interfere with the hotplugging as they all grab the event device. Note that if you specify a device in the xorg.conf, it will not be hotplug-capable and you cannot add the device at runtime.


== Benefit to Fedora ==
== Benefit to Fedora ==
Line 85: Line 86:
=== I have no input devices. ===
=== I have no input devices. ===
The HAL setup seems to be broken. Make sure the 10-x11-input.fdi file is in /usr/share/hal/fdi/policy/10osvendor and that hal-device lists mice and keyboards with input.x11_driver = "evdev".
The HAL setup seems to be broken. Make sure the 10-x11-input.fdi file is in /usr/share/hal/fdi/policy/10osvendor and that hal-device lists mice and keyboards with input.x11_driver = "evdev".
=== The Xorg.log claims that some devices are disabled ===
X will disable all devices using the mouse or kbd driver to avoid duplicate events. This does not affect you if HAL is working correctly. You can just remove the devices from your xorg.conf.
=== The Xorg.log claims that some device files are already in use ===
The evdev driver can detect if the same device file is added twice. If you have an evdev device in your xorg.conf, and the same device is added through HAL, you get the warning "(WW) <device name>: device file already in use. Ingoring." This doesn't affect you, your xorg.conf device keeps working. However, since xorg.conf devices are not hotplug-capable we suggest to just remove the respective InputDevice section from your xorg.conf.


=== My xorg.conf settings are ignored. ===  
=== My xorg.conf settings are ignored. ===  
HAL adds your devices without settings, and evdev grabs all devices away. Modify the fdi and add your settings there. You can then remove the mouse/keyboard specifications in your xorg.conf.
Devices using the drivers kbd or mouse are ignored by default, and HAL adds your devices without settings. Modify the fdi and add your settings there. You can then remove the mouse/keyboard specifications in your xorg.conf.
Alternatively. add Option "AutoAddDevices" "off" to your ServerLayout. Note that this will stop input hotplugging.
Alternatively. add Option "AutoAddDevices" "off" to your ServerLayout. Note that this will stop input hotplugging.
=== I'm getting a "Grab failed" in the logs. ===
You have two evdev input devices pointing to the same device file. This usually only happens if you have a xorg.conf entry with an evdev, and then HAL tries to add the same device again. You can ignore this warning.


=== I have devices in my xorg.conf but still don't get any devices. ===
=== I have devices in my xorg.conf but still don't get any devices. ===
Your ServerLayout doesn't reference the input devices and your HAL setup is broken. This shouldn't happen and is almost certainly a bug.
Your ServerLayout doesn't reference the input devices and your HAL setup is broken. This shouldn't happen and is almost certainly a bug.
However, add Option "AllowEmptyInput" "off" to your ServerLayout or simply reference the InputDevice sections in the ServerLayout.
However if fixing HAL is not an option, add Option "AllowEmptyInput" "off" to your ServerLayout or simply reference the InputDevice sections in the ServerLayout.


=== My touchpad is slow. ===
=== My touchpad is slow. ===
Check the logs if the touchpad is added with the evdev driver. If so, modify the fdi file to merge synaptics as input.x11_driver, or add a InputDevice section in your xorg.conf (must be referenced by the ServerLayout). Note that synaptics provides the required fdi file so this should not occur. Please file a bug against the xorg-x11-drv-synaptics component.
Check the logs if the touchpad is added with the evdev driver. If so, modify the fdi file to merge synaptics as input.x11_driver, or add a InputDevice section in your xorg.conf (must be referenced by the ServerLayout). Note that synaptics provides the required fdi file so this should not occur. Please file a bug against the xorg-x11-drv-synaptics component.


=== Macintosh mouse button emulation stops working ===
=== I get duplicate events ===
This is a serious issue that cannot be fixed right now. Grabbing the event device stops in-kernel event forwarding and we are waiting for a kernel patch to fix this. For now, the only solution is to disable input hotplugging and use mouse/kbd in the traditional way.
You have AllowEmptyInput disabled in your xorg.conf but you're also adding the devices through HAL. The best way to stop this issue is to remove input devices from the xorg.conf completely and let HAL do its job. Alternatively, enable AllowEmptyInput, or stop input hotplugging by disabling AutoAddDevices.  
Add Option "AutoAddDevices" "off" to your ServerLayout section.
 


== Dependencies ==
== Dependencies ==
Line 132: Line 134:
* See [[Talk:Features/EvdevInputDriver]]  <!-- This adds a link to the "discussion" tab associated with your page.  This provides the ability to have ongoing comments or conversation without bogging down the main feature page -->
* See [[Talk:Features/EvdevInputDriver]]  <!-- This adds a link to the "discussion" tab associated with your page.  This provides the ability to have ongoing comments or conversation without bogging down the main feature page -->


[[Category:FeatureReadyForWrangler]]
[[Category:FeatureAcceptedF10]]

Latest revision as of 01:35, 22 October 2008

Feature Name

EvdevInputDriver

Summary

Evdev is being used as the default input driver for X.Org.

Owner

Current status

  • Targeted release: Fedora 42
  • Last updated: 2008-10-22
  • Percentage of completion: 100%


Detailed Description

(The original version of this text is available here.)

Traditionally, the X server used the mouse or the keyboard input drivers. With X11R7.3, the evdev driver became more prominent. F10 now uses the evdev driver as standard driver for all mouse and keyboard devices and provides the necessary hotplugging facilities to detect the devices at run-time. The mouse and kbd drivers are essentially obsolete now and are disabled in the default settings.

A quick overview of the evdev input driver

xf86-input-evdev is the hotplugging-capable input driver to be used for mice and keyboards (and other devices, if appropriate). One main difference is that it uses devices files such as /dev/input/event0 instead of /dev/input/mouse0 (like the mouse driver does for example). The other big difference is that it can query the kernel about the capabilities about each device and set up itself correctly. So if you point a device to /dev/input/event0, it will automatically set itself up as mouse or keyboard, as appropriate.

How to set up input hotplugging

At startup, the server queries HAL over DBus for a list of devices and adds them one-by-one. This method is preferable over specifying devices in the xorg.conf. F10 provides the necessary .fdi files to add the devices with the right options (see /usr/share/hal/fdi/policy/10osvendor/10-x11-input.fdi).

The central key to add a device to the server is to specify input.x11_driver. Other options may be specified if desired, but x11_driver is mandatory. Important: the server will not add devices unless they have input.x11_driver set. If you end up with no devices at all, then your HAL setup is probably broken. To test your installation, run hal-device to obtain a list of all devices and look for the input.x11* keys. If they are not present, modify the fdi file and restart HAL.

The X server is now hot-plug capable. It will add all mice and keyboards automatically, even if you add/remove them at runtime. Other drivers such as wacom and synaptics provide their own fdi files to ensure that they are hotplug-capable as well.

What to do with the xorg.conf

Input device configuration in the xorg.conf is obsolete if hotplugging is used. Remember, we have two configuration files now. One is xorg.conf, the other one is the fdi file, but both don't know about each other. The server parses xorg.conf first, then gets the devices through HAL. And here we have a big culprit: if you add a InputDevice section with the mouse driver, it will conflict with the evdev driver. So when all mice are added through the HAL evdev hotplugging mechanism, their events are not only sent through the respective /dev/input/eventX file, but also through /dev/input/mouseX and /dev/input/mice. Hence, if you have devices using the mouse or kbd driver in your xorg.conf, you will get duplicate events. As a result, by default devices using the mouse/kbd drivers are disabled and only those devices added through HAL are enabled.

The best solution for most configurations is to simply remove the input-related configurations in the ServerLayout and the xorg.conf file. If you have specific options for devices, you can add them by merging the respective keys in the fdi file. Alternatively, if you need to use the kbd or mouse drivers, you can disable hotplugging altogether by adding Option "AutoAddDevices" "off" in your ServerLayout.

You can still configure evdev, wacom or synaptics devices in the xorg.conf but it is discouraged. Devices specified in the xorg.conf are not hotplug-capable and you cannot add the device at runtime.


Benefit to Fedora

The evdev driver is the upstream driver of choice, and using it allows us to stay closer to upstream. Evdev not only allows separate configuration for each device, it also maintains these configurations if the device is added at runtime.

Scope

This feature is already present in the current versions of Rawhide. The evdev driver was used for mouse input devices in F9 already, F10 expands this to keyboard usage as well. In fact, F9 added a patch to xorg-x11-server to disable evdev keyboards, the scope for F10 is removing this patch and fixing the bugs arising from this issue.


Test Plan

Hardware needed: mice and/or keyboards.

Packages required: xorg-x11-server, xorg-x11-drv-evdev, hal.

Configuration files: /usr/share/hal/fdi/policy/10osvendor/10-x11-input.fdi Per-device configuration may be added to this file, if necessary. The default configuration provides the standard options for both keyboard and mice. It is recommended that input devices using the mouse or kbd driver are removed from the xorg.conf.

Check: hal-device | grep "input.x11_driver" should show a number of lines stating evdev as driver. If specific options were added to the 10-x11-input.fdi file, these options should show up for the device when running hal-device.

Expected Results: mouse + keyboard works in X. If it doesn't but HAL shows the driver to be configured, this is a high-priority bug.

User Experience

For you as a user, the change to evdev should be completely transparent. However, if you experience any changes, the following hints may help:

I have no input devices.

The HAL setup seems to be broken. Make sure the 10-x11-input.fdi file is in /usr/share/hal/fdi/policy/10osvendor and that hal-device lists mice and keyboards with input.x11_driver = "evdev".

The Xorg.log claims that some devices are disabled

X will disable all devices using the mouse or kbd driver to avoid duplicate events. This does not affect you if HAL is working correctly. You can just remove the devices from your xorg.conf.

The Xorg.log claims that some device files are already in use

The evdev driver can detect if the same device file is added twice. If you have an evdev device in your xorg.conf, and the same device is added through HAL, you get the warning "(WW) <device name>: device file already in use. Ingoring." This doesn't affect you, your xorg.conf device keeps working. However, since xorg.conf devices are not hotplug-capable we suggest to just remove the respective InputDevice section from your xorg.conf.

My xorg.conf settings are ignored.

Devices using the drivers kbd or mouse are ignored by default, and HAL adds your devices without settings. Modify the fdi and add your settings there. You can then remove the mouse/keyboard specifications in your xorg.conf. Alternatively. add Option "AutoAddDevices" "off" to your ServerLayout. Note that this will stop input hotplugging.

I have devices in my xorg.conf but still don't get any devices.

Your ServerLayout doesn't reference the input devices and your HAL setup is broken. This shouldn't happen and is almost certainly a bug. However if fixing HAL is not an option, add Option "AllowEmptyInput" "off" to your ServerLayout or simply reference the InputDevice sections in the ServerLayout.

My touchpad is slow.

Check the logs if the touchpad is added with the evdev driver. If so, modify the fdi file to merge synaptics as input.x11_driver, or add a InputDevice section in your xorg.conf (must be referenced by the ServerLayout). Note that synaptics provides the required fdi file so this should not occur. Please file a bug against the xorg-x11-drv-synaptics component.

I get duplicate events

You have AllowEmptyInput disabled in your xorg.conf but you're also adding the devices through HAL. The best way to stop this issue is to remove input devices from the xorg.conf completely and let HAL do its job. Alternatively, enable AllowEmptyInput, or stop input hotplugging by disabling AutoAddDevices.

Dependencies

xorg-x11-drv-evdev

xorg-x11-server

Contingency Plan

None necessary, revert to previous release behaviour.

Documentation

Input configuration in a nutshell

evdev(4)

Release Notes

F10 now uses the evdev input driver as standard mouse and keyboard driver for the X server. This driver together with HAL provides a persistent per-device configuration that allows devices to be added or removed at runtime.

Comments and Discussion