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 _______________________________________________ wayland-devel mailing list [email protected] http://lists.freedesktop.org/mailman/listinfo/wayland-devel
