[PATCH v3 wayland-protocols] Add the tablet protocol

[Daniel Stone]

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.

> +  <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