Bug 971

Summary: Input device hotplug
Product: xorg Reporter: Kristian Høgsberg <krh>
Component: Server/Input/CoreAssignee: Daniel Stone <daniel>
Status: RESOLVED FIXED QA Contact:
Severity: enhancement    
Priority: high CC: bero, brant, daniel, dberkholz, erik.andren, esigra, freedesktop2eran, icculus, mightyquinn, nmirthes, olivier.chapuis, peter.kovar, pingc, sam, saw27, the_Arioch, thomas, warp-spam+fdo
Version: gitKeywords: patch
Hardware: All   
OS: All   
URL: http://xorg.freedesktop.org/wiki/XInputHotplug
Whiteboard:
i915 platform: i915 features:
Bug Depends on:    
Bug Blocks: 6144    
Attachments:
Description Flags
tar.gz with new files and patch
none
tar.gz with example programs
none
Patch with an XRemoveInputDevice implementation and evdev
none
Patch with an XRemoveInputDevice implementation and evdev
none
Patch with an XRemoveInputDevice implementation and evdev
none
Patch ported to current CVS (including new files)
none
Patch ported to InputProto
none
patch ported to libXi
none
patch ported to xorg-server
none
xorg-server patch ported to current CVS
none
libXi patch ported to 1.0.1 none

Description Kristian Høgsberg 2004-08-02 09:37:54 UTC
Attached is a first attempt at adding input device hotplug support to the Xorg
server.  Hotplugging is implemented by adding two requests to XInput:
XAddInputDevice() and XRemoveInputDevice().  Also, a DevicePresenceNotify event
is added to XInput; this event is sent to interested client when the list of
present devices change.

The XAddInputDevice() call takes a name for the device and the driver to use as
arguments, and a list of options in the form (name, value), name and value being
strings.  In this implementation, the meaning of the arguments are equivalent to
the contents of the xorg.conf "InputDevice" section, i.e. name maps to the
Identifer option and is used for the XInput device name, driver maps to the
Driver option and the (name, value) options maps to Option "name" "value".

When XAddInputDevice() successfully adds a new input device, this device is
present in the device list and available as if it had been in the xorg.conf file
with the given options, and a DevicePresenceNotify event is sent out.

Issues:

 - XRemoveInputDevice() not yet implemented
 - Security issues when you can ask the server to open any file as a device
 - Is the XAddInputDevice() design too xorg.conf specific?
Comment 1 Kristian Høgsberg 2004-08-02 09:39:49 UTC
Created attachment 557 [details]
tar.gz with new files and patch

Implementation of the hotplug idea.
Comment 2 Kristian Høgsberg 2004-08-02 10:55:18 UTC
Created attachment 558 [details]
tar.gz with example programs

Added small package with some sample applications:

 - xadddev: command line tool to add new input devices
 - xrmdev: command line tool to remove input devices
 - get-event: small application to demonstrate listening for hotplug events
 - input-daemon: use HAL for discovering new input devices and add them
automatically
Comment 3 Kristian Høgsberg 2004-08-02 10:58:33 UTC
Btw. for the HAL sample application, the evdev input driver is required, see bug 968
Comment 4 Olivier Chapuis 2004-11-09 13:48:12 UTC
Created attachment 1259 [details] [review]
Patch with an XRemoveInputDevice implementation and evdev

The attached patch extends previous patchs. It contains an XRemoveInputDevice
implementation. It also fixes some compilation problems related to Xprint, Xdmx
and Xdarwin. The patch contains the evdev patch too (see bug 968) with a few
open/close clean up.

The patch is against current cvs (2004-11-09).

Olivier
Comment 5 Olivier Chapuis 2004-11-09 14:01:55 UTC
(In reply to comment #0)
> 
> Issues:
> 
>  - XRemoveInputDevice() not yet implemented

A simple implementation (maybe not perfect) in the patch I just send.

>  - Security issues when you can ask the server to open any file as a device

I think that this can be solved by adding a new path option in the
File section of the configuration file:

Section "Files"
 ....
  XInputDevicePath /dev/input
  XInputDevicePath /foo/xyz
 ...
EndSection

XAddInputDevice() will be allowed to open devices only
in the /dev/input and /foo/xyz directories.

Regards, Olivier

Comment 6 Dave Ahlswede 2004-11-09 17:33:13 UTC
I tried applying Olivier's patch to both current stable release and a fresh CVS
tree, and they both fail compiling at the same point in
xc/programs/Xserver/Xi/extinit.c



extinit.c: In function `ProcIDispatch':
extinit.c:343: warning: implicit declaration of function `ProcXRemoveInputDevice '
extinit.c:343: warning: nested extern declaration of `ProcXRemoveInputDevice'
extinit.c: In function `SProcIDispatch':
extinit.c:438: warning: implicit declaration of function `SProcXRemoveInputDevic e'
extinit.c:438: warning: nested extern declaration of `SProcXRemoveInputDevice'
extinit.c: In function `SReplyIDispatch':
extinit.c:509: warning: implicit declaration of function `SRepXRemoveInputDevice '
extinit.c:509: warning: nested extern declaration of `SRepXRemoveInputDevice'
extinit.c: In function `SEventIDispatch':
extinit.c:583: warning: implicit declaration of function `SDevicePresenceNotifyE
vent'
extinit.c:583: warning: nested extern declaration of `SDevicePresenceNotifyEvent '
extinit.c: At top level:
extinit.c:695: warning: function declaration isn't a prototype
extinit.c:695: error: conflicting types for 'SDevicePresenceNotifyEvent'
extinit.c:583: error: previous implicit declaration of 'SDevicePresenceNotifyEve
nt' was here
make[5]: *** [extinit.o] Error 1
Comment 7 Olivier Chapuis 2004-11-10 01:55:21 UTC
Created attachment 1270 [details]
Patch with an XRemoveInputDevice implementation and evdev

Fixed warning in a previous version of the patch
Comment 8 Dave Ahlswede 2004-11-10 03:25:55 UTC
I hate to bug you again, but the tarball is missing rmdev.h
Comment 9 Olivier Chapuis 2004-11-10 13:08:27 UTC
Created attachment 1277 [details]
Patch with an XRemoveInputDevice implementation and evdev

Added the missing rmdev.h file.
Comment 10 Ted Kaminski 2004-11-29 19:14:33 UTC
Is there a good reason for not including information about the notification
event? If an application is listening for DevicePresenceNotify, wouldn't it want
information about what changed? We have all the information when we send the
event... There's no need to force them to cache XListInputDevices if they want
the delta.
Comment 11 Nick Morsillo 2005-03-28 07:12:28 UTC
I successfully patched and installed xorg 6.8.2, and built xadddev and xrmdev
helper programs.  I can use xadddev to add input devices with no problem, but
xrmdev absolutely refuses to work.  It always returns one of two error messages:  

./xrmdev TC1000pen
X Error of failed request:  BadName (named color or font does not exist)
  Major opcode of failed request:  146 (XInputExtension)
  Minor opcode of failed request:  36 ()
  Serial number of failed request:  11
  Current serial number in output stream:  11

--or--

input-daemon-0.1.0 # ./xrmdev TC1000mouse
X Error of failed request:  BadMatch (invalid parameter attributes)
  Major opcode of failed request:  146 (XInputExtension)
  Minor opcode of failed request:  36 ()
  Serial number of failed request:  11
  Current serial number in output stream:  11

TC1000pen and TC1000mouse are both currently installed and working input
devices.   Have I done something wrong?  Is xrmdev broken?
Comment 12 Bernhard Rosenkraenzer 2005-05-29 08:40:46 UTC
Created attachment 2789 [details] [review]
Patch ported to current CVS (including new files)

Attaching modified version of the patch:
- Applies to current CVS
- Removes the evdev driver from the patch, a newer version is already in CVS
- Puts the new files in the patch too, I don't like the idea of untarring
  extra files too much (other, already committed, files might be overwritten
  if ppl keep applying this from a script after it is merged...)
Comment 13 Adam Jackson 2005-06-28 13:38:47 UTC
*** Bug 1199 has been marked as a duplicate of this bug. ***
Comment 14 Adam Jackson 2005-06-28 14:21:38 UTC
*** Bug 3548 has been marked as a duplicate of this bug. ***
Comment 15 Chris Santero 2005-12-27 04:52:32 UTC
Created attachment 4167 [details] [review]
Patch ported to InputProto

I split up the patch for integration into the modular tree. Here is the patch
for InputProto.
Comment 16 Chris Santero 2005-12-27 04:53:34 UTC
Created attachment 4168 [details] [review]
patch ported to libXi

And here is the patch to libXi.
Comment 17 Chris Santero 2005-12-27 04:54:38 UTC
Created attachment 4169 [details] [review]
patch ported to xorg-server

And finally the patch for xorg-server.
Comment 18 Arioch 2006-01-29 06:29:21 UTC
i wonder what share of patches is built into X.org 7 release ?

It seems it broken some thiing that worked on X.org 6.9 / AltLinux

hence HotPlug cooperation becomes of immportance to me :(
Comment 19 Bernhard Rosenkraenzer 2006-01-29 09:09:01 UTC
Arioch: None of this has gone into R7 -- for R7, apply the last 3 patches 
attached to this bug (and don't forget to run automake afterwards - the patch 
adds files).  
Comment 20 Daniel Stone 2006-03-05 20:27:29 UTC
i'll work on getting this in for 7.2
Comment 21 Daniel Stone 2006-03-05 20:27:47 UTC
mandatory comment o'clock
Comment 22 Bernhard Rosenkraenzer 2006-03-05 23:00:15 UTC
Created attachment 4825 [details] [review]
xorg-server patch ported to current CVS

xorg-server patch updated to apply to current CVS
Comment 23 Bernhard Rosenkraenzer 2006-05-24 03:39:39 UTC
Created attachment 5722 [details] [review]
libXi patch ported to 1.0.1

New patch for libXi -- applies to libXi 1.0.1 (X11R7.1)
Comment 24 Daniel Stone 2006-06-05 12:45:23 UTC
the current patch is not workable, mainly because of the security issues
introduced by having the add/remove calls go over the wire.
Comment 25 Daniel Stone 2006-07-21 12:34:25 UTC
my implementation is sitting in the input-hotplug branches of inputproto, libxi,
xsetpointer, and xserver.  there's also a phenomenally lame configuration client
sitting in /git/users/daniels/respeclaration.

the server currently has a few issues now, like xephyr being completely broken
(but that's fixable: it was working before I started playing with the xorg ddx,
and I have a reasonable idea as to what the problem is), and multi-screen (in
the sense of Screens, not monitors) support having disappeared; it clips to the
boundaries of the first screen.  but that's relatively easy to fix, it just
needs some testing and mipointer semantics.

share and enjoy.
Comment 26 Daniel Stone 2006-11-01 19:42:07 UTC
merged in yay

Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.