[PATCH libinput 3/3] Change the logging system to be per-context

Jonas Ådahl jadahl at gmail.com
Wed Jun 18 01:07:12 PDT 2014


On Wed, Jun 18, 2014 at 05:52:04PM +1000, Peter Hutterer wrote:
> On Wed, Jun 18, 2014 at 09:24:03AM +0200, Jonas Ådahl wrote:
> > > > The purpose of the struct was to provide an interface with the
> > > > functionality that libinput would require to have to function without
> > > > having to be root, and it doesn't feel logging function fits this
> > > > purpose. It was already a set/get, wouldn't it fit better to just make
> > > > them per context, while keeping the interface struct minimal?
> > > 
> > > yeah, fair enough. I arrived at this solution at a bit of a roundabout way
> > > since I wanted to make the current udev_create work without changes and then
> > > failed anyway. with the create_context function it's possible now to do the
> > > following:
> > > 
> > >     li = libinput_udev_create_context();
> > >     libinput_set_log_handler(li, ...);
> > >     libinput_set_log_priority(li, ...);
> > >     libinput_udev_set_set(li, seat);
> > > 
> > > That's what you're proposing, right?
> > 
> > Yes, something like that. We could also possibly do what I think we
> > discussed a while ago and default to suspended, i.e. _create_for_seat(),
> > _set_(), _enable(), but either way really. The problem with _set_seat()
> > though I guess is that it makes it look like we can actually switch seat
> > of a context, which I don't know if we should support.
> 
> well, we could do it as add/remove like in the path backend, I just don't
> know if there's a use-case for that?

Not sure. A user could just create multiple contexts if libinput only
would can handle one physical seat per context.

> 
> for the current code I'll just add a check, right now it just overwrites it
> which is a bug.
> 
> other name suggestions: assign_seat() or bind_seat()
>

Any of these two would be best IMHO. If we'd want to support multiple
physical backends some day, we could just add the unbind/unassign
function, but for now, lets just support one. Maybe just fail if it's
called twice instead of overwrite?


Jonas

> 
> Cheers,
>    Peter


More information about the wayland-devel mailing list