[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