Shared publicly  - 
Draft of a wayland protocol to support Wacom tablets sent to list. Comments appreciated.

I do have some implementation, but it still lacks things like proximity events etc, so I won't claim that's ready for testing yet.
[RFC DRAFT] graphics tablet protocol extension. Peter Hutterer peter.hutterer at Fri Sep 20 03:35:42 PDT 2013. Previous message: [PATCH wayland] protocol: validate the protocol against a dtd; Next message: [PATCH wayland] Export the Wayland protocol XML file; Messages sorted by: ...
Peter Hutterer's profile photo桜木まりも's profile photoAdrian M Negreanu's profile photoDiego Call.'s profile photo
I'm guessing that's my job for next week :)
Please make it almost trivial to support them. Otherwise, we'll have a situation like in Qt today: every other release breaks it because no one tests it...

Preferably, make it just minor modifications compared to a touchscreen. 
+Thiago Macieira probably why it breaks, wacom devices are so much more than a touchscreen. it would be easier to treat touchscreens as wacom devices :-)
I'm fine with that. As long as they're not an entirely different input API.
About exposing the touch ability of some tablets through wl_touch: How can the application know that this touch and this button on the pad correspond to the same physical device? Or - how to relate the finger proximity event and the subsequent touch?
+Thiago Macieira easier said than done. I can't force people to test tablets but they are an important (and paying) part of the ecosystem. The existing Wayland protocol is simply not enough, but I think the current staff is simple enough to make it easy.
+Peter Hutterer: no doubt. My only suggestion is to make supporting tablets as easy as you can, so remove opportunities for breaking stuff.
+Alexander Patrakov current idea is to only expose the touch parts as touch and the buttons as part of the stylus. That may need a switch in the compositor so you could reassign, with e.g.a bamboo being like a touchpad with buttons. That would be a compositor implementation issue though.
One think I would really like is a "softbutton hover" event. The Aiptek tablets do this, there is a "macro key" area at the top of the normal tablet surface. As soon as you move the pen to the top edge it stops sending coordinates but key numbers plus the normal proximity/pressure/button bits.
The windows driver shows a small tooltip when hovering over the macro keys, making hitting it without looking at the tablet really simple.
I did think about soft button events and the best (and only workable) solution I've come up with so far is to integrate that in the compositor.

The compositor knows when the pointer is over there, so it would intercept the events and mangle them into whatever else is supposed to happen .
+Peter Hutterer For the Aiptek this wont work. The macro keys are not reported as events in the normal coordinate space, but as keys 1...N, although they are physically located at the top of the drawing area. The driver could fake coordinates, but what's the correct value for above top left, ie 0/0?
+Stefan Brüns if the kernel already reports keys, then we should just stick with that. Beyond that, I need to think about it. Would be great if you could send me an email with that info though, easier to search for in the future
Add a comment...