wl_tablet specification draft

[Peter Hutterer]

On Sat, Jun 28, 2014 at 12:41:33PM +0300, Pekka Paalanen wrote:
> On Fri, 27 Jun 2014 13:04:59 -0700
> Bill Spitzak <spitzak at gmail.com> wrote:
> 
> > 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.
> 
> First you said that...
> 
> > 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.
> 
> ...and then you said the exact opposite, plus you require the
> broken case where the same hardware events map to multiple
> completely different protocols (wl_pointer *and* tablet).

that's not necessarily the worst thing, provided it doesn't happen at the
same time. with a "mode toggle" button the compositor could switch between
tablet events and absolute motion on-the-fly.

This is a change how tablets currently work in Linux but aside from that
it's actually the easiest and cleanest to implement.
 
> Moving seat's "mouse cursor" means the tablet/pen controls the
> wl_pointer and sends wl_pointer events. I don't see any way around
> that.

moving the visible cursor doesn't necessarily mean that it must translate
into the wl_pointer protocol. It's probably awkward at first if the pointer
moves and clients don't react to it but if we essentially require the
toolkits to support wl_tablet then this will go away quickly.

Cheers,
   Peter