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

[Dan Nicholson]

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?

--
Dan