[PATCH libinput] Note that libinput_unref() really destroys everything

[Peter Hutterer]

On Fri, Sep 04, 2015 at 08:29:07AM +0200, Andreas Pokorny wrote:
> Hi,
> To some degree this does not sound like a bug. At least for resources that
> are not presented to the user as being ref counted. But I would have
> expected that libinput_path_add_device would increase the ref count of the
> libinput_context and similar for seats. So as long as the device is not
> unref-ed to zero it would keep the context alive.

right, the problem here is that keeping the context alive also means you
keep _everything_ alive, and that means you keep receiving events.
Otherwise, you'd have libinput_unref() disable event receiving only, but
that makes it a bit ambiguous. And forcing callers to add
libinput_dispatch() isn't an option eiterh.

any solution would be a behaviour change where one way or another you'd be
leaking memory in current callers.

> Additionally..
> 
> 2015-09-04 6:17 GMT+02:00 Peter Hutterer <peter.hutterer at who-t.net>:
> 
> > + * [...]
> > + * @code
> > + * li = libinput_path_create_context(&interface, NULL);
> > + * device = libinput_path_add_device(li, "/dev/input/event0");
> > + * // get extra reference to device
> > + * libinput_device_ref(device);
> >
> 
> why is libinput_path_add_device not creating a device with a ref count of
> 1, just like the init function of the libinput context?
> The current behavior looks inconsistent. Although that behavior does not
> cause trouble if the user sticks to a shut down sequence that unrefs
> devices first...

two reasons:
libinput's API generally returns the unmodified struct, if you need it
refcounted, you need to ref it yourself. libinput has libinput_dispatch(),
so you're guaranteed the struct is alive until then, i.e. a ref() isn't
always necessary. That goes for the other structs too, not just the device.
In this case, the refcount is 1, the proper way to remove the device isn't
with unref but with libinput_path_remove_device(). The example is just to
get yet another reference, i.e. the refcount here is at least 2.

the other reason: the return value here is a bit of a side-effect, mostly
for the libinput xorg driver and the test suite. you can let it drop to the
floor and get the device from the DEVICE_ADDED event later. This would be
the proper way to do it, but makes tests and the xorg driver very
complicated. returning the device here is a shortcut, but otherwise within
the API behaviour.

Cheers,
   Peter