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