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

Peter Hutterer peter.hutterer at who-t.net
Tue Feb 3 14:13:06 PST 2015

On Tue, Feb 03, 2015 at 07:01:55PM +0100, Hans de Goede wrote:
> 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>

Thanks. I should also note that the current plan is to hold these back
until we have the rest of the tablet bits in place. That should give us an
idea whether all this actually works and fixes the issues or whether it's a
wild goose chase anyway :)


More information about the xorg-devel mailing list