[PATCH wayland-protocols] Add the tablet protocol

[Peter Hutterer]

On Mon, Nov 16, 2015 at 12:07:12PM +0000, Daniel Stone wrote:
> Hi Jonas,
> 
> On 16 November 2015 at 11:59, Jonas Ådahl <jadahl at gmail.com> wrote:
> > On Mon, Nov 16, 2015 at 11:21:36AM +0000, Daniel Stone wrote:
> >> On 6 November 2015 at 04:24, Peter Hutterer <peter.hutterer at who-t.net> wrote:
> >> > +    More than one tablet may exist, and device-specifics matter. Tablets are
> >> > +    not represented by a single virtual device like wl_pointer. A client
> >> > +    binds to the tablet manager object which is just a proxy object. From
> >> > +    that, the client requests wp_tablet_manager.get_tablet_seat(wl_seat)
> >> > +    and that returns the actual interface that has all the tablets. With
> >> > +    this indirection, we can avoid merging wp_tablet into the actual wayland
> >> > +    protocol, a long-term benefit.
> >>
> >> Yes, it turns out the wl_seat.get_* model was probably a pretty bad
> >> anti-pattern. Oh well. To avoid too much object proliferation though,
> >> how about something like:
> >> <interface name="wp_tablet_manager">
> >>   <request name="add_seat">
> >>     <description summary="Add seat of interest">
> >>       Add a seat of interest to this tablet manager. The client will
> >> receive events for all tablets currently on this seat, as well as
> >> tablets added to this seat in future.
> >>     </description>
> >>     <arg name="seat" type="object" interface="wl_seat"/>
> >>   </request>
> >>   [inline wp_tablet_seat here ...]
> >> </interface>
> >>
> >> Then you can just bin wp_tablet_seat.
> >>
> >> Not a pattern we've previously employed, but I think it's a good one
> >> that avoids one extra step of indirection, as well as making it a bit
> >> easier for clients to do the right thing.
> >
> > How would it be easier for clients to do the right thing? It'd just make
> > it easy to mix different seats' tools and tablets as there would be no
> > more separation (except if one would bind a tablet manager per seat). Or
> > should tools and tablets be considered on the same "super seat", i.e.
> > would it be possible to see tool A from seat X on tablet V on seat Y?
> 
> It makes it easier, because right now we expect them to hold a
> wp_tablet_manager, respond to new seats by creating a new
> wp_tablet_seat, and having them respond to events on that as well. We
> already make people hold absolute piles of objects, so one less seems
> like it could be a good thing.

I have to say it sounds a lot worse in the protocol than it is in the
implementation. But this was the easiest bit of the implementation, clients
already have some wrapper object for the wl_seat anyway, this just adds one
pointer for the tablet seat to that object, plus one global one for the
tablet manager. [1] And that too is just adding one more pointer to existing
infrastructure.

And the effective cost is minimal - how many wl_seats do we expect in the
worst case? 10? In the 99% case we only have one and that's what IMO we
should optimise for (and the code would look identical anyway since in the
client it'll all hang off the struct seat_something). I think that the
potential confusion of mixing tablets from different seats is a lot worse
than the extra objects here.

Cheers,
   Peter

[1]
https://github.com/whot/weston/commit/64dc64a4dbabd7fbe1b6b80a2a08ff2cc8c0c288#diff-87a1da5a7e6453c81e19091e66a9015dR5757
 
> > Seems to me that making it possible to shove all seats in one pile is
> > more error prone than having them clearly separated.
> 
> Possibly. I guess it depends on the failure mode. I can see it either way.