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

[Peter Hutterer]

On Wed, Jun 18, 2014 at 10:07:12AM +0200, Jonas Ådahl wrote:
> 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?

for the archives, i've done a s/set_seat/assign_seat/ on these functions,
and added the code to fail if the function is called once a seat has been
assigned.

Cheers,
   Peter