wl_tablet specification draft

[Bill Spitzak]

On 06/26/2014 09:38 PM, Ping Cheng wrote:

> With my experience, mapping whole tablet to a window or a
> specific display area is preferred. That is how mapping works on Windows
> and Mac too.

First this is *only* when the drawing program wants it to happen. There 
is some kind of mode switch so the user can use the pen to do things 
outside the drawing area. When the drawing program is not controlling it 
the user wants to be able to use the pen instead of the mouse for all 
mouse actions.

I would also love to see addressed the ability to get "square" movement 
out of the pad, and to automatically switch to "mouse mode" if the 
outputs are a significantly different shape than the tablet. Though 
Linux was by far the worst, all three systems (OS/X and Windows) fell 
down badly here, mostly by making it impossible to mode-switch between 
mouse and tablet mode, and on Windows it is impossible to change the 
scale of mouse mode. None of them would change how the mapping is done 
when outputs are added/removed. I believe "limit to one monitor" is not 
necessary and is only being provided as a work-around for the non-square 
mappings that should be avoided in a different way.

Even though it sounds like it is disagreeing with me, there is no need 
for "mouse emulations". Wayland clients should all be written to know 
that they could get pen events just like mouse events and to handle them 
the same if they don't want to do anything smarter with the pen.

Vaguely thinking of this from a Wayland client's pov it seems like what 
should happen is this:

- The pen moves the seat's mouse cursor, always. If more than one cursor 
is wanted the pen should be in a different seat. The user is not 
manipulating more than one device at a time and does not want to see two 
cursors.

- By default the pen can move the cursor anywhere the mouse could move 
it. A configuration option sets the "scale" (possibly a range) between 
pen movements and cursor motion. If mapping the tablet to the bounding 
box of all the outputs exceeds this scale then it automatically switches 
to "mouse mode" (ie relative movement, possibly with acceleration). 
Conversely if it is too small, or the aspect is sufficiently different, 
then only a centered rectangle of the tablet is used. The setting is 
automatically updated when the outputs or configuration changes as long 
as no pen buttons are held down. It may be useful to have horizontal and 
vertical enter "mouse mode" independently, but somebody needs to try that.

- Clients can request that the tablet be mapped to a rectangle in a 
particular surface. They must have the seat mouse focus for this to 
happen. Unless some extra api is used for force the mapping, the 
built-in rules are applied to determine the scale and whether mouse-mode 
is used, based on the size and aspect of this rectangle.

- If this mapping is happening, other devices (ie the mouse) can still 
move the cursor outside the rectangle. It will jump back in when pen is 
moved in proximity.

- This does not "grab" the mouse/pen. If other surfaces are visible 
inside the rectangle (either because it is larger than the surface or 
because of an overlapping surface) then clicks go to the client the 
surface belongs to.

- A client can request the default mode be restored, even if they did 
not set the rectangle, as long as it has seat mouse focus. This is so an 
overlapping dialog can decide whether it should exit the mode. I think 
this will be better than any built-in rules for relinquishing the mode.