Bug 971

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