Peter Hutterer <[email protected]> writes: > Avoid creating new devices from within the input thread which was the case for > tablet tools. It requires a lot more care about locking and has a potential to > mess up things. > > Instead, schedule a WorkProc and buffer all events until we have the device > created. Once that's done, replay the event sequence so far. If the device > comes into proximity and out again before we manage to create the new device > we just ditch the whole sequence and wait for the next proximity in. > > Signed-off-by: Peter Hutterer <[email protected]> > --- > src/xf86libinput.c | 259 > +++++++++++++++++++++++++++++++++++++++++------------ > 1 file changed, 202 insertions(+), 57 deletions(-) > > diff --git a/src/xf86libinput.c b/src/xf86libinput.c > index 1ecbc41..9b9ba12 100644 > --- a/src/xf86libinput.c > +++ b/src/xf86libinput.c > @@ -102,6 +102,12 @@ struct xf86libinput_device { > struct xorg_list unclaimed_tablet_tool_list; > }; > > +struct xf86libinput_tablet_tool_event_queue { > + bool need_to_queue; > + struct libinput_event_tablet_tool *events[128]; > + size_t nevents;
Any particular reason to use an array of fixed size here, instead of a
list which wouldn't have any limit?
> -static void
> +static inline void
Yeah, just drop the 'inline' for the huge functions in this file; the
compiler will probably ignore it anyways...
> +xf86libinput_tool_replay_events(struct xf86libinput_tablet_tool_event_queue
> *queue)
> +{
> + size_t i;
> +
> + for (i = 0; i < queue->nevents; i++) {
> + struct libinput_event *event;
> + event =
> libinput_event_tablet_tool_get_base_event(queue->events[i]);
> + xf86libinput_handle_event(event);
> + queue->events[i] = NULL;
> + /* we're not queueing anymore so we expect handle_event to
> + libinput_event_destroy() */
looks like handle_event just returns whether to destroy the event, so
you'd need a call here, or make handle_event handle the event
destruction internally.
The rest of this looks reasonable to me.
--
-keith
signature.asc
Description: PGP signature
_______________________________________________ [email protected]: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: https://lists.x.org/mailman/listinfo/xorg-devel
