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

[Dan Nicholson]

On Thu, May 20, 2010 at 6:05 PM, Peter Hutterer
<peter.hutterer at who-t.net> wrote:
> 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.

Yeah, I thought of this later. I think we should pass the config_info
into NIDR and set it there regardless. Right now, you have the config
backend stupidly resetting after returning from the driver. You could
pass it in as an InputOption. Or, if you're breaking ABI, make it a
member of InputAttributes and drop DeviceIntPtr->config_info since you
want to copy the InputAttributes into DeviceIntPtr anyway. A third ABI
breaking option is just to have config_info be a parameter to NIDR.

I'm not opposed to a flags for DIDR since there could easily be other
things signal to the driver, but it seems like there are better
solutions to this particular problem.

--
Dan