[PATCH xf86-input-libinput] Handle capability events after adding a device

[Hans de Goede]

Hi,

On 02/03/2015 12:13 PM, Peter Hutterer wrote:
> On 3/02/2015 18:29 , Hans de Goede wrote:
>> Hi,
>>
>> On 30-01-15 06:31, Peter Hutterer wrote:
>>> Needs a temporary libinput context to get all capability events without
>>> events from other devices interfering.
>>>
>>> This doesn't yet handle true capability changes, only the initial
>>> burst of
>>> events after the DEVICE_ADDED event.
>>>
>>> Signed-off-by: Peter Hutterer <peter.hutterer at who-t.net>
>>
>> Hmm, this one does not give me a warm/fuzzy feeling. Are we sure that
>> having
>> the capabilities of libinput events on the fly is the best way to go ?
>>
>> It is the logical thing to do from a libinput pov, but it seems to put an
>> unnecessary burden on libinput users, we're likely going to see similar
>> problems in compositors. I would prefer to just solve this in libinput,
>> e.g. :
>>
>> 1) Add a heuristic to see if a device may have multiple evdev nodes
>> representing
>> a single device.
>> 2) If 1) is true, then wait for evdev nodes to show up for 0.5 seconds
>> (or maybe
>> we can even know which evdev nodes to wait for) and do not give the
>> device to
>> the libinput user until it is complete.
>>
>> This is more work in libinput, but it seems much easier on libinput
>> users, and
>> thus the right thing to do.
>
> we (Benjamin and I) did consider this at first but the big drawback is
> that we then have to keep a model database of devices in libinput.
> Heuristics are hard and even harder when you have to guess whether a
> tablet is a Intuos 5 or an Intuos 5 Touch - without a model DB you don't
> know. And the database is a big drawback: yet another layer in the stack
> that needs updating for new devices.
>
> The timeout approach could work, but was pretty much dismissed
> immediately, mainly for the usual reasons: not sure how long to wait,
> you can't know if/when the second device will show up, etc.
>
> Pushing this to the caller where the device is handled semantically
> seemed like the most reliable solution, even if it is more complex to
> deal with.

Hmm, I'm still not 100% convinced but if you and Benjamin believe that
this is best, then this patch is:

Reviewed-by: Hans de Goede <hdegoede at redhat.com>

Regards,

Hans