wl_tablet specification draft

[Pekka Paalanen]

On Mon, 30 Jun 2014 20:46:46 +1000
Peter Hutterer <peter.hutterer at who-t.net> wrote:

> On 30/06/2014 20:23 , Pekka Paalanen wrote:
> > On Mon, 30 Jun 2014 09:33:15 +0300
> > Pekka Paalanen <ppaalanen at gmail.com> wrote:
> >
> > If you have a tabletscreen, and your tool is a set of fingers, is it
> > any different to a touchscreen? Could we even cover touchscreens with
> > the tablet protocol, and deprecate wl_touch?
> 
> hmm, interesting idea. we're also kicking around the idea where the 
> protocol moves from using tablets as the event sources to using the 
> tools as the sources instead. So the prox-in event doesn't come from the 
> wl_tablet but from the wl_tool instead (with the tablet being a property 
> on the event). That principle would be usable for touch interaction if 
> you generate a couple of generic finger1, finger2, etc. tools. I'll 
> think about this some more.

Sounds promising.

> > One more question is, how do input event parameters get mapped for
> > clients. Say, your window is in a 30-degree angle and squashed, what do
> > you report as tool angles etc.
> 
> I think the safest bet is to define any tablet input as alongside the 
> x/y axis of the client surface, with angles/distance defined as as 
> orthogonal to the client surface. so any angles or distortion would have 
> to be applied to the input before sending it to the client. Correct me 
> if I'm wrong here but iirc the client doesn't know about the surface 
> distortion applied by the compositor anyway, right?

Correct. We already report all pointer motion in surface coordinates,
because that is the only possibility there.

However, that is quite tied to the idea, that the input device is
related to the screen (output). If you have client-drawing-area mode,
the first thought is to not apply the distortion, so that the tablet
rectangle matches the window rectangle, no matter how it is presented
on screen. The coordinate mapping will be different anyway.

I suppose that is also an open question for the pointer-lock extension.


Thanks,
pq