[RFC DRAFT] graphics tablet protocol extension

[Peter Hutterer]

On Tue, Sep 24, 2013 at 12:41:50PM -0700, Bill Spitzak wrote:
> 
> 
> Peter Hutterer wrote:
> >Thanks for testing this. I'm currently tempted to have the pad buttons
> >(that's the terminology we use in the xorg wacom driver, so let's use it
> >here too) should have a separate focus, and a separate event. so the
> >interface expands to:
> >
> >wl_tablet::proximity in
> >         ::proximity out
> >         ::button
> >         ::focus in
> >         ::focus out
> >         ::padbutton
> >         ...
> >
> >where padbuttons always go to the focused surface. it is then up to the
> >compositor to implement the actual focus behaviour. it also makes it easy
> >for the client to distinguish between stylus buttons and pad buttons.
> Not sure I understand. I think I agree with your description of how
> it works, but I feel it is sufficient for the pad buttons always go
> to the same surface that the pen clicks go to. Do you just mean that
> the pen has a different focus than the mouse? Or are you really
> proposing the the pad buttons may go to a different surface than pen
> clicks?

pretty much. the pad buttons have an actual focus. that is largely controlled
by the pen but since the pen can go out of proximity anytime, you don't
always have the correct surface under the pen. you need to remember which
one was the last, i.e. you need a focus.

in the most common use case, the sequence would be something like

focus in
proximity in
stylus events
proximity out
button events
focus out

technically that would also allow the buttons to go to a different surface
to the pen. That actually matters: most pens support proximity, so you may
accidentally have a proximity event in another surface. e.g. if you move
your hand out of the way to see what's on the screen before you
press a button. That doesn't mean you want the button focus on that new
surface.

Cheers,
   Peter