[RFC DRAFT] graphics tablet protocol extension

[Peter Hutterer]

On Sat, Sep 21, 2013 at 10:09:25AM -0700, Bill Spitzak wrote:
> On 09/20/2013 03:35 AM, Peter Hutterer wrote:
> 
> >* 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.
> 
> I tried both Windows 7 and OS/X with a Wacom Intuos3 6x8.
> 
> The buttons act precisely like whatever they are emulating. They can
> be set to be a set of modifier keys, or a single mouse button click,
> or a sequence of keystrokes with modifiers, and the result is
> exactly as though I quickly hit the same things on the main keyboard
> and mouse.
> 
> If a button sends keystrokes then they go to the application with
> the keyboard focus even if the mouse is pointing somewhere else.
> 
> If they send a shift modifier then they cause keys typed on the
> keyboard to be uppercase.
> 
> Setting them to clicks causes the clicks to go to the application
> under the mouse cursor, activating those applications. This is more
> apparent under Windows where the first click in an un-activated app
> is still handled, on OS/X it just activates it and throws away the
> click (I believe Cocoa apps can see this click, but all ignore it to
> match OS/X UI guidelines).
> 
> On Windows, by using Alt+Tab, I was able to make a button type into
> two different applications!
> 
> Note that both platforms had a method to make all the button
> assignments depend on the current application.
> 
> There are also two vertical strips (just really small pads) next to
> the buttons. They may be limited to detecting the vertical position
> of the pen, but I would not be suprised if they are in fact more of
> the main tablet area and can pick up pressure and tilt and some
> horizontal positions. These could also be programmed to send
> keystrokes and they acted like the buttons.
> 
> Now for my opinion:
> 
> This seems to be an implementation detail and I think it is ok if
> the effect of buttons goes only to the app with the pointer focus.

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.

> The default setups make the buttons act like all the different
> modifiers so you can do shift+click on the pad. On OS/X one of the
> buttons is set so when held down it causes the pen to send x/y mouse
> scrolling events. The small vertical strips are set in both cases to
> "smart scroll" which it is unclear what it does, and imho setting
> them to the scroll wheel works better ("smart scroll" may be an
> attempt to work around Window's very broken policy of sending the
> scroll wheel to the keyboard focus). I think this covers what is
> needed for "tablet unaware" applications. I suspect that the
> modifiers only have to work at the moment a click is sent from the
> pen, though working the way Windows and OS/X does might be the
> easiest implementation but users are not relying on it.
> 
> The reason for the keystrokes is obviously to trigger shortcuts in
> the application the pen is being used on, such as to switch tools in
> Photoshop. I suspect it would be ok if they went to the client with
> pointer focus (it could ignore them if it does not have keyboard
> focus if that helps). They can also be unique buttons, it would be
> much better if the client provided the api to change what the
> buttons do.

yes. afaict the only reason why pad buttons send key strokes is to trigger
actions - and that should be handled by the application anyway. so I don't
really want to add keyboard emulation, etc. to the tablet interface. and if
we really need it one day, that can be hidden through the compositor.

somewhat the same goes for any softbuttons on random places on the tablet
but this bit I'm not too sure about that yet. 

Cheers,
   Peter