wl_tablet specification draft

Wed Jun 25 23:59:51 PDT 2014

On Thu, Jun 26, 2014 at 09:23:51AM +0300, Pekka Paalanen wrote:
> On Thu, 26 Jun 2014 14:14:33 +1000
> Peter Hutterer <peter.hutterer at who-t.net> wrote:

[...]

> > > >good point, thanks!
> > > >>>         - Name: time
> > > >>>           Type: uint
> > > >>>           The time of the event with millisecond granularity.
> > > >>>
> > > >>>         - Name: changed_axes
> > > >>>           Type: bitfield
> > > >>>           Indicates which axes have changed.
> > > >>>
> > > >>>         - Name: axes
> > > >>>           Type: array
> > > >>>	  The current values of each of the tablet axes starting at
> > > >>>	  WL_TABLET_AXIS_DISTANCE. The length of the array is equal to the
> > > >>>	  number of axes that are reported. Any axes >= WL_TABLET_AXIS_CNT
> > > >>>	  must be ignored.
> > > Is there a reason we are using an array rather than sending different
> > > events?  It's tempting to try and save something by using an array, but
> > > extra events don't really cost anything significant. Also, once you use an
> > > enum value in a public protocol, you can NEVER change it.  In particular,
> > > you can't change WL_TABLET_AXIS_CNT and you are locked into only ever using
> > > those axes and never extending the protocol to include more.  I don't think
> > > this is what you intended.
> >  
> > the basic idea here was to simply provide the client with a single event
> > containing all the data at all times rather than a flurry of events with the
> > deltas, terminated by a FRAME event. A few calculations showed that sending
> > all axes every time in one event is still smaller than sending frame events
> > (given "average" axis usage) so we're not losing anything here.
> > 
> > the basic idea behind the array is that we can add to it in later revisions.
> > a client gets the array size and up to that size axes are included. If the
> > compositor uses a higher _CNT, then the client is supposed to ignore
> > anything above that value.
> > 
> > also, though that isn't clear: I don't think _CNT is something that's
> > actually in the protocol, a client would #define that themselves or just use
> > whatever the highest axis is they want to deal with.
> 
> Are you sure this won't lead to problems, like running out of bits in
> the changed_axes bitfield?

I am honestly hoping that 32 axes per device are enough...
(cue the laughter)

[...]

> > > >It's possible, look at this RFC from last september.
> > > >http://lists.freedesktop.org/archives/wayland-devel/2013-September/011173.html
> > > >
> > > >The gist of that was that the wl_seat::get_tablet_manager request that
> > > >returned a tablet manager object. that object was then the one that sent
> > > >wl_tablet_manager::device_added events with the new tablet object. And that
> > > >object had the wl_tablet interface as above (without the IDs).
> > > >
> > > >Lyude and I talked about this and couldn't decide which approach was the
> > > >correct-er one for wayland :)
> > > I'll second what pekka said.  We already have a way of handling IDs and
> > > agressively recycling them; it's called object IDs.  I'm guessing the IDs
> > > thing came from the wl_touch interface.  There we have a wl_touch object for
> > > the physical device and IDs for the different touchpoints.  Here we have one
> > > pen per physical device (I think).
> > 
> > that's not quite true, and it's the biggest difference between pointer/touch
> > and tablet. For pointer/touch we don't care that there are more devices,
> > they all mangle together. For tablets, it does matter if the event came from
> > the Cintiq or the attached Bamboo, both may be assigned different functions,
> > configurations, behaviours, etc.
> > So I do think we need multiple tablet objects instead of just one like
> > wl_pointer has.
> 
> I'm not sure that was really the question here. If we compare to
> multitouch touchscreen, the question above was about separating multiple
> touchscreens, not separating multiple fingers on one touchscreen. The
> latter is what you talk about below. Is this analogy correct?

The analogy is correct, but I do think we need to differ between multiple
tablets _and_ multiple tools (i.e. pens).

> > You usually have more than one pen as well: the physical pen that comes with
> > a tablet already has two tools built-in (pen + eraser) and both have
> > separate serial numbers. You can buy extra tools and the unique serial means
> > that with appropriate client support you can use the same physical tool on
> > different tablets and always get the same settings. Having said that, those
> > tools currently abstracted in the serial/tool type fields so it's not a wl
> > object as such anyway.
> 
> Sounds like you would have these identifications:
> - a protocol object per tablet device, under which each tool has
>   * an ID to distinguish multiple tools (pens) from each other
>   * tool type
> 
> Does that seem right?
> Would you need to model tools in the protocol with more than just an
> abstract uint ID & type embedded in per-tablet events?

Hmm, good question. tool id and serial is how we tell them apart in the
lower levels. Each tool has different properties, with the default
tools just having pressure/distance/tilt, other tools having extra
features such as a wheel.

Which could potentially turn the protocol on its head: make the tool a
first-level object that sends event and have the tablet a sub-object to
identify where the event is being generated on.

Regardless of that, the tools could be made a top-level object next to the
wl_tablets. First time you use a tool you get a wl_tablet_manager::new_tool
and that object ID is then used for the tool regardless of the tablet it is
being used on.
Gets a bit tricky with those tools that don't have identifiers (the ones on
bamboos).

> From what I read in the proposal, I understood that the "id of the
> tablet sending this event" referred to the tablet device, not the tool,
> hence my comments.

that is correct, that's what the ID stands for in this proposal.

Cheers,
   Peter

> > > >>I'm not sure how you want to advertise and create the wl_tablet objects.
> > > >>How do tablet devices relate to wl_seat protocol objects?
> > > >tablets control the cursor, so we definitely need to couple them
> > > >with the seats somehow.
> > > Does it control THE cursor or A cursor?  I question whether we really want
> > > it to be that intertwined with wl_pointer.
> > > 
> > > This brings up another point: tablet focus.  How do you usually tell the
> > > compositor what window you want to receive tablet input?  For a tablet with
> > > a screen, you can treat it more-or-less like a single-point touch-screen,
> > > but what about tablets that aren't attached to a screen?  In the past,
> > > tablets frequently existed as a more natural way to move the mouse around
> > > with a little extra meta-data for an app if it wanted it.  Is that the way
> > > they SHOULD work?  That's a different question.
> > 
> > Yes, but that doesn't change that tablets belong to one seat at a time :)
> > How the compositor moves the cursor/controls the focus around is none of the
> > protocol's business.
> > 
> > Cheers,
> >    Peter
> > 
> > > >>While the protocol is experimental, you could have your own (temporary)
> > > >>global interface for advertising tablets, so that you don't need to
> > > >>modify the Wayland core protocol (wl_seat). Or you could advertise each
> > > >>tablet device as a separate global wl_tablet that a client can bind to.
> > > >>The proper approach finally depends on the relation to wl_seat once you
> > > >>are ready to set the protocol in stone.
> > > >good point, thanks.
> > > >
> > > >>Would clients need some information to differentiate between multiple
> > > >>tablets in a human-friendly way?
> > > >yes, we'll at least need to add PID/VID. From then on the clients can look
> > > >up all they need in libwacom. I don't think we need much more than that.
> > > >
> > > >>Or should all clients always subscribe to all tablets?
> > > >Yes, I think that's the sensible option. in 99% of the cases there is only
> > > >one tablet anyway, sometimes there are 2 (laptops have wacom tablets
> > > >built-in or a Cintiq+Intuos combo), I haven't seen a real-world setup with 3
> > > >tablet yet.
> > > >
> > > >Cheers,
> > > >    Peter
> > _______________________________________________
> > wayland-devel mailing list
> > wayland-devel at lists.freedesktop.org
> > http://lists.freedesktop.org/mailman/listinfo/wayland-devel
> 
> 