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?
Created attachment 557 [details] tar.gz with new files and patch Implementation of the hotplug idea.
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
Btw. for the HAL sample application, the evdev input driver is required, see bug 968
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
(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
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
Created attachment 1270 [details] Patch with an XRemoveInputDevice implementation and evdev Fixed warning in a previous version of the patch
I hate to bug you again, but the tarball is missing rmdev.h
Created attachment 1277 [details] Patch with an XRemoveInputDevice implementation and evdev Added the missing rmdev.h file.
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.
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?
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...)
*** Bug 1199 has been marked as a duplicate of this bug. ***
*** Bug 3548 has been marked as a duplicate of this bug. ***
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.
Created attachment 4168 [details] [review] patch ported to libXi And here is the patch to libXi.
Created attachment 4169 [details] [review] patch ported to xorg-server And finally the patch for xorg-server.
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 :(
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).
i'll work on getting this in for 7.2
mandatory comment o'clock
Created attachment 4825 [details] [review] xorg-server patch ported to current CVS xorg-server patch updated to apply to current CVS
Created attachment 5722 [details] [review] libXi patch ported to 1.0.1 New patch for libXi -- applies to libXi 1.0.1 (X11R7.1)
the current patch is not workable, mainly because of the security issues introduced by having the add/remove calls go over the wire.
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.
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.