[PATCH] Add a "flags" field to DeleteInputDeviceRequest.

[Peter Hutterer]

On Thu, May 20, 2010 at 03:33:41PM -0700, Dan Nicholson wrote:
> On Thu, May 20, 2010 at 1:07 AM, Peter Hutterer
> <peter.hutterer at who-t.net> wrote:
> > Some input drivers need to implement an internal hotplugging scheme for
> > dependent devices to provide multiple X devices off one kernel device file.
> > Such dependent devices can be added with NewInputDeviceRequest() but they are
> > not removed when the config backend calls DeleteInputDeviceRequest(),
> > leaving the original device to clean up.
> >
> > Example of the wacom driver:
> >
> > config/udev calls NewInputDeviceRequest("stylus")
> >
> > wacom PreInit calls
> >        NewInputDeviceRequest("eraser")
> >        NewInputDeviceRequest("pad")
> >        NewInputDeviceRequest("cursor")
> >        PreInit finishes.
> >
> > When the device is removed, the config backend only calls
> > DeleteInputDeviceRequest for "stylus". The driver needs to call
> > DeleteInputDeviceRequest for the dependent devices eraser, pad and cursor to
> > clean up properly.
> > However, when the server terminates, DeleteInputDeviceRequest is called for
> > all devices - the driver must not remove the dependent devices to avoid
> > double-frees. There is no method for the driver to detect why a device is
> > being removed, leading to elaborate guesswork and some amount of wishful
> > thinking.
> >
> > Though the input driver's UnInit already supports flags, they are unused.
> > This patch uses the flags to supply information where the
> > DeleteInputDeviceRequest request originates from, allowing a driver to
> > selectively call DeleteInputDeviceRequest when necessary.
> 
> Here's a question that's always bothered me about this. If you set
> DeviceIntPtr->config_info equal to the parent in the subdevices, won't
> a single call to DeleteInputDeviceRequest in the server clean up all
> the devices? See remove_devices() in config/config.c.
> 
> Then you wouldn't have to call DeleteInputDeviceRequest from the
> driver at all. Either we'd get a uevent, call DIDP for all devices
> matching config_info, or the server terminates and we call DIDP for
> all devices.
> 
> Is there a reason this approach wasn't taken?

hmm, good suggestion. I need to investigate this, I just never thought of
it. AFAICT from a glance at the source, this still requires server patches
though. config_info on the device isn't set until after NIDR which spawns
off the dependent devices.

So unless we set a Block or Wakeup handler to create the devices, I'm not
quite sure how to do this. Of course, we could also pass this as an
InputOption into NIDR and just set it there, we already have a few special
options anyway.

Cheers,
  Peter