[PATCH v3 wayland-protocols] Add the tablet protocol

[Peter Hutterer]

On Thu, Feb 18, 2016 at 12:00:09PM +0000, Daniel Stone wrote:
> Hi,
> No real opinion on the angles/units thing, and indeed we can't really
> add native 64-bit integers now (even if we did, it rapidly descends
> into a padding/alignment nightmare; much easier to keep _everything_
> on the wire as 32-bit units for that reason). Aside from that:
> 
> On 29 January 2016 at 04:32, Peter Hutterer <peter.hutterer at who-t.net> wrote:
> > +    When the tool leaves proximity, a proximity_out event is sent. If any
> > +    button is still down, a button release event is sent before this
> > +    proximity event. These button events are sent in the same frame as the
> > +    proximity event to signal to the client that the buttons were held when
> > +    the tool left proximity.
> > +
> > +    If the tool moves out of the surface but stays in proximity (i.e.
> > +    between windows), compositor-specific grab policies apply. This usually
> > +    means that the proximity-out is delayed until all buttons are released.
> 
> This took me a couple of reads to convince myself; it might be useful
> to explicitly make the difference between physically out of proximity,
> and a logical event (for the second paragraph) here. But it seems
> fine.

It may be, but I think we'll leave it at this for now. the touch events
which have the same ability of appearing in random places don't have
anything specific here either. so unless we have a specific demand for it, I
think it's better to leave it out.

rest is addressed in the patch coming up in a tick

Cheers,
   Peter

> > +  <interface name="zwp_tablet_manager_v1" version="1">
> > +    <description summary="controller object for graphic tablet devices">
> > +      An object that provides access to the graphics tablets available on this
> > +      system. Any tablet is associated with a seat, to get access to the
> > +      actual tablets, use wp_tablet_manager.get_tablet_seat.
> > +    </description>
> > +
> > +    <request name="get_tablet_seat">
> > +      <description summary="get the tablet seat">
> > +       Get the wp_tablet_seat object for the given seat. This object
> > +       provides access to all graphics tablets in this seat.
> > +      </description>
> > +      <arg name="tablet_seat" type="new_id" interface="zwp_tablet_seat_v1"/>
> > +      <arg name="seat" type="object" interface="wl_seat" summary="The wl_seat object to retrieve the tablets for" />
> > +    </request>
> > +
> > +    <request name="destroy" type="destructor">
> > +      <description summary="release the memory for the tablet manager object">
> > +       This destroys the resources associated with the tablet manager.
> 
> Which associated resources? Does it imply that all tablet_seats will
> (by the server) or should (by the client) be destroyed by this point?
> Or is it just purely the object itself?
> 
> > +  <interface name="zwp_tablet_seat_v1" version="1">
> > +    <description summary="controller object for graphic tablet devices of a seat">
> > +      An object that provides access to the graphics tablets available on this
> > +      seat. After binding to this interface, the compositor sends a set of
> > +      wp_tablet_seat.tablet_added and wp_tablet_seat.tool_added events.
> > +    </description>
> > +
> > +    <request name="destroy" type="destructor">
> > +      <description summary="release the memory for the tablet seat object">
> > +       This destroys the resources associated with the tablet seat.
> 
> Same question, but for tablet/tablet_tools.
> 
> > +    <request name="destroy" type="destructor">
> > +      <description summary="destroy the tool object">
> > +       This destroys the client's resource for this tool object.
> > +
> > +       A client must not issue this request until it receives a
> > +       wp_tablet_tool.remove event.
> > +      </description>
> > +    </request>
> 
> From last time (two levels in me, one level in you):
> > > Egads. What happens when a client no longer wants to know about tablet
> > > events (e.g. you have an embedded drawing program in a browser but
> > > then close the tab): it just has to ignore the stream of events
> > > forever? A bit hostile.
> >
> > you can drop the tablet manager and re-bind. I think filtering specific
> > devices at the protocol level is a bit of a niche usecase and better handled
> > in the toolkit.
> 
> So, this ties in with the questions above, about what gets destroyed /
> is required to have been destroyed. For me, it's less about
> filtering/ignoring particular tools, than a clean takedown sequence.
> Say you switch from a mode where tablet events are useful/important
> (you're in a browser and drawing sequence diagrams) to not (sequence
> diagrams are really boring so you're watching highlights of the 1990
> World Cup on YouTube). What's - ideally described in $WAYLAND_DEBUG
> form - the sequence for a client cleanly exiting from all tablet
> events?
> 
> (Assuming that destroy before removed is supported, presumably it'd
> need to follow the same proximity_out+up+frame sequence so the client
> knew when it would no longer receive any events.)
> 
> > +    <enum name="capability">
> > +      [...]
> > +      <entry name="slider" value="5" summary="Slider axis"/>
> > +      <entry name="wheel" value="6" summary="Slider axis"/>
> 
> Whoops. :)
> 
> > +    <event name="removed">
> > +      <description summary="tool removed">
> > +       This event is sent when the tool is removed from the system and will
> > +       send no further events. Should the physical tool comes back into
> > +       proximity later, a new wp_tablet_tool object will be created.
> > +
> > +       It is compositor-dependent when a tool is removed. A compositor may
> > +       remove a tool on proximity out, tablet removal or any other reason.
> > +       A compositor may also keep a tool alive until shutdown.
> > +
> > +       If the tool is currently in proximity, a proximity_out event will be
> > +       sent before the removed event.
> 
> ... and an up event?
> 
> > +    <enum name="error">
> > +      <entry name="role" value="0" summary="given wl_surface has another role"/>
> > +    </enum>
> 
> ?!
> 
> > +    <request name="destroy" type="destructor">
> > +      <description summary="destroy the tablet object">
> > +       This destroys the client's resource for this tablet object.
> > +
> > +       A client must not issue this request until it receives a
> > +       wp_tablet.remove event.
> > +      </description>
> > +    </request>
> 
> All the same questions apply.
> 
> Cheers,
> Daniel