[PATCH v2 wayland-protocols] Add pad support to the tablet protocol

[Peter Hutterer]

On Fri, Apr 22, 2016 at 12:30:11PM +0200, Carlos Garnacho wrote:
[...]
> >> > +    <event name="buttons" since="2">
> >> > +      <description summary="buttons announced">
> >> > +       Sent on wp_tablet_pad initialization to announce the available buttons.
> >> > +       Compositors may consume some buttons for global actions, those
> >> > +       will not be announced in this event (e.g. the button to switch
> >> > +       between modes, if any).
> >> > +
> >> > +       This event is sent in the initial burst of events before the
> >> > +       wp_tablet_tool.done event.
> >> > +      </description>
> >>
> >> Do we need to have the ability to change the set of announced buttons
> >> on the fly? Its possible the compositor would want to change which
> >> buttons it reserves by user request. For example, right now it is
> >> possible to configure GNOME to have a button pop up an OSD of button
> >> assignments (which is a global compositor action). The choice of the
> >> button is up to the user, and if the user later changes their mind
> >> then applications will have to be informed that the set of available
> >> buttons has changed. I might be thinking about this case
> >> wrong-headedly and that there's no need for the list of available
> >> buttons to change, but I don't think so...
> >>
> >> Its also not entirely clear to me what the array that would be
> >> received is supposed to contain or how clients are supposed to
> >> interpret it.
> >
> > hmm, good point. This is from before we switched libinput over to report
> > numerical buttons, it makes sense to do the same here and change this event
> > into a simple "here's the number of buttons" event and change the value of
> > the "button" event into a button index.
> 
> Hmm, I most probably didn't encode that properly in docs in the early
> drafts, but I expected this to work by announcing clients the
> available button array on focus in, kinda similar in spirit to
> wl_keyboard.modifiers (with the obvious "the ones active" vs "the ones
> you might expect to receive" differences).
>
> Presumably, in order to get a change in the buttons available to the
> client the user will need to configure those to perform
> compositor-level actions, and thus focus out the current client and
> switch to a different UI. With this scheme, the only UI that might get
> buttons (un)reserved while focused is the one mapping buttons itself,
> and it should arguably be a compositor facility (or closely tied to
> it).

tbh, this seems a bit like overkill. compared to the number of focus events,
button reconfigurations are quite rare. I suspect most users would configure
the buttons for an application maybe once, but now you're sending the button
array on every focus event just in case they got reconfigured?

it provides more flexibility but since events are per-client anyway a global
button-mask event should be sufficient.

how about these two events:
<event name="buttons">
   Number of buttons, sent before wl_tablet_pad.done event. Buttons are 
   sequentially indexed starting at 0. [...]
   <arg name="buttons" type="uint" summary="the number of buttons"/>
</event>

<event name="button_mask">
   An array with button indices available to the client. Some buttons may be
   claimed by the compositor or other clients and thus unavailable to the
   client. Events from these buttons are consumed by the compositor and the
   client will not see these events. A client should accommodate for
   physically present but unavailable buttons in the user interface.

   The protocol guarantees that the wl_tablet_pad.buttons event is sent
   before the wl_tablet_pad.button_mask event. The wl_tablet_pad.button_mask
   event may be sent during the initial burst of events before the
   wp_tablet_pad.done event and whenever the compositor reconfigures the
   buttons.
   <arg name="buttons" type="array"
       summary="the number of buttons available to the client"/>
</event>

since events are per-client this still gives us the ability to have the
configuration client see a different button mask than everyone else.

Cheers,
   Peter

> 
> >
> > if we need to change the set of announced buttons I think a better option
> > would be a "button_reserved" event later down the track that tells the
> > client that they cannot expect that particular button to send events.
> 
> We can also go this way, although there should be probably events to
> notify both ways.
> 
> Cheers,
>   Carlos