I've been working on a protocol extension to support graphics tablets such
as the Wacom set of tablets, and I'm now at the stage where I'd like a few
comments. I was hoping that I'd get a full implementation before XDC but
unfortunately that didn't happen, so for now I'll just show the protocol.
I've got a PoC implementation, but it's missing a few too many pieces to be
actually usable just yet.
Any feedback appreciated. This is a relatively early stage, so there are
still many changes expected.
The goal is to make it possible to access graphics tablets. One important
thing to note is that this interface does _not_ cover the touch ability of
some tablets. This should go through wl_touch (for touchscreen-like tablets)
or wl_pointer (for external touchpad-like tablets).
There are a few notable differences to the wl_pointer interface:
* tablets have a tool type that matters, it lets applications such as the
GIMP select paint tools based on the physical tool. those tools also often
have HW serial numbers to uniquely identify them.
* extra axes mattter: pressure, tilt, distance - all influence the stylus
behaviour
* more than one device may be present, so it's important to have access to
all devices on a one-by-one basis. unlike wl_pointer, where we just have
one virtual pointer.
* proximity matters since we can leave proximity from directly above a
surface. the pointer can't do that, it moves from one surface to the next.
so in some ways it's closer to wl_touch in that regard.
Some design notes:
* generally most axes change at the same time, hence the choice to send a
wl_array instead of separate events.
* x/y would have to be adjusted relative to the surface, but technically the
same would have to be done to e.g. distance on a true 3D desktop.
* not sure at all about the relative events at all or if there's a need for
it. iirc only some styly have REL_*WHEEL, do we need something else? Ping,
Jason?
* I don't have a specific touch event, I figured BTN_TOUCH would do the job.
* focus handling for the stylus is easy. focus handling for the buttons on
the pad isn't. they could technically be focused elsewhere, like a
keyboard focus. some buttons are definitely stylus based (BTN_STYLUS,
BTN_STYLUS2, etc.) so should go where the stylus is. Should look at what
Win/OSX do here.
* bind/binding/unbind - this is like windowed mode in GIMP. do we still need
this? who's actually using this instead of a full-screen app?
* tablet_manager is a bit meh, but the only alternative would be to have a
wl_seat::get_tablets request and a wl_seat::tablet_added event. Possible,
but doesn't look that much nicer. but it does away with the indirection.
(read the diff below to understand what I mean here)
* if we stick with the tablet_manager, do we need a
wl_tablet_manager::get_tablets request in case the client releases a
tablet it needs again later? or do we expect to re-bind to
wl_tablet_manager?
* fuzz/flat should be dropped, I just haven't yet.
* I'd really like to enscribe in the protocol that ABS_PRESSURE means just
that and damn anyone else who wants to use 0x18 as axis code. weston
does this for wl_pointer::button, but it's not actually documented. what's
the deal here?
* does this even make sense as wl_tablet or should I try first as
experimental weston-tablet interface that then (maybe) moves later to
wayland proper.
That's it so far, again, any feedback appreciated. diff below.
Cheers,
Peter
diff --git a/protocol/wayland.xml b/protocol/wayland.xml
index aeb0412..8d10746 100644
--- a/protocol/wayland.xml
+++ b/protocol/wayland.xml
@@ -1235,7 +1235,7 @@
-
+
A seat is a group of keyboards, pointer and touch devices. This
object is published as a global during start up, or when such a
@@ -1251,6 +1251,7 @@
+
@@ -1306,6 +1307,19 @@
+
+
+
+The ID provided will be initialized to the wl_tablet_manager
+interface for this seat. This can then be used to retrieve the
+objects representing the actual tablet devices.
+
+This request only takes effect if the seat has the tablets
+capability.
+
+
+
+
@@ -1617,6 +1631,223 @@
+
+
+ A tablet manager object provides requests to access the graphics
+ tablets available on this system.
+
+
+
+
+Describes the type of tablet.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+ This interface describes a graphics tablet, such as Wacom's Intuos or
+ Cintiq ranges.
+
+ Note, this interface does not handle touch input on touch-capable
+ tablets. Depending on the tablet, touch input is sent through the
+ wl_pointer (if used as a touchpad) or wl_touch interface (if used as a
+ touch screen).
+
+
+
+
+
