<div dir="ltr"><div><div><div><div><div><div>Hi, all!<br><br></div>I will try to answer all your emails in one post.<br><br></div>1) Tablet vs. Touch. Basically what I am talking about is *not* touch arbitration and palm recognition. The Wacom driver itself blocks all the touch events when the stylus is in the proximity, so it performs the necessary arbitration. What we need is to block several kinds of actions (read "tools") when the user uses touch and unblock them when the user works with stylus or mouse. An exact usecase: we need to allow the user to zoom/pan on the canvas with his fingers, but at the same time real painting with fingers must be prohibited (it disturbs the painters). Right now it is almost impossible, because we get no touch events, and instead get synthesized MousePress/Release/Move events for finger actions, which are indistinguishable from real mouse events.<br>
<br></div>2) Buttons vs Tablet Press. Well, to tell you the truth we are not interested in whether the stylus touched the surface of not. At all. The stylus has 3 button: the tip itself, and two buttons. These three buttons can be remapped with the driver (xsetwacom) to any X11 button the user wants. Therefore, I have absolutely no interest in TabletTouch/TabletRelease if the only thing they tell me that the stylus has touched the surface of the tablet with the stylus or not. What I really need is the TabletButtonPress/Release event, which tells me:<br>
<br></div>1) Which button (of the three) is pressed<br></div>2) Exact position of the stylus<br></div>3) Pressure, Tilt, Z-coordinate if available (might be zero/unit for some of the buttons)<br><div><div><div><div><br></div>
<div>The situation is getting even worse if you look at the feature which Windows' Wacom driver has (I'm not sure whether this feature is available in X11 Wacom driver, but it is highly requested by the painters). On Windows the buttons on the stylus can be switched into "modifier" mode. That is pressing the button doesn't produce a real button event. You need to press the  stylus button, and then touch the surface of the tablet with the tip: only then the app will get mouse button click (right or middle button usually). If this feature will ever be implemented in X11 Wacom driver (which is quite desirable), your protocol with TabletTouch/Press will not work. Please check Wintab protocol docs for more info, specifically, CSR_SYSBTNMAP attributes [0]<br>
</div><div><br></div><div>3) Axes resolution. Yes, it is perfectly ok to have a separate function which tells the physical limits of the axis. What I wanted to say is that min_value/max_value attributes, which are reported by XInput are not enough. For rotation I also need to know the mapping of the coordinate system origin and it's direction (clockwise/counterclockwise).<br>
</div><div><br></div><div>PS:<br></div><div>Please keep me in CC, I'm having troubles with keeping up with the traffic in this mailing list.<br></div><div><br><br>[0] - <a href="http://www.wacomeng.com/windows/docs/Wintab_v140.htm">http://www.wacomeng.com/windows/docs/Wintab_v140.htm</a><br>
<br></div></div></div></div></div><div class="gmail_extra"><br><br><div class="gmail_quote">On Fri, Jun 27, 2014 at 6:53 AM, Jason Gerecke <span dir="ltr"><<a href="mailto:killertofu@gmail.com" target="_blank">killertofu@gmail.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="HOEnZb"><div class="h5">On Wed, Jun 25, 2014 at 5:50 PM, Peter Hutterer<br>
<<a href="mailto:peter.hutterer@who-t.net">peter.hutterer@who-t.net</a>> wrote:<br>
> Replying to three emails at once here to keep the thread a bit more<br>
> managable.<br>
><br>
> On Wed, Jun 25, 2014 at 01:38:22PM -0700, Jason Gerecke wrote:<br>
>> On Wed, Jun 25, 2014 at 12:38 AM, Lyude <<a href="mailto:thatslyude@gmail.com">thatslyude@gmail.com</a>> wrote:<br>
>> > On Wed, 2014-06-25 at 11:06 +0400, Dmitry Kazakov wrote:<br>
>> >> Hi, all!<br>
>> >><br>
>> >><br>
>> >> I am a developer from Krita painting application team. We recently did<br>
>> >> quite much work on incorporating better tablet support in Krita. I<br>
>> >> have several comments about your proposal of the tablet protocol<br>
>> >> (sorry for nor replying directly, since I wasn't subscribed to the<br>
>> >> list before).<br>
>> ><br>
>> > Benjamin commented on this as I was writing this e-mail, and I figured I<br>
>> > should too: yes, it's awesome to see developers commenting on the<br>
>> > protocol. A lot of the quirks around this protocol are going to be<br>
>> > difficult to see without the help of people who have programmed on the<br>
>> > client side of things as opposed to the compositor side of things. So<br>
>> > yes, your input is very much appreciated and I thank you for it!<br>
>> ><br>
>> >><br>
>> >> 1) Axes. There should also be an axis for rotation of the stylus<br>
>> >> (Artpen) and Tangential Pressure (for the wheel of the Airbrush).<br>
>> >><br>
>> >> 2) There is also Artpen type of stylus. In Qt it is called "Rotational<br>
>> >> Stylus".<br>
>> ><br>
>> > Don't worry, we haven't forgotten about these. These will eventually be<br>
>> > added into the protocol. The reason why they're not in this draft is<br>
>> > because I'm doing this as my Google Summer of Code project, and as such<br>
>> > I'm on a deadline and I have to focus on just getting the basics done<br>
>> > first before I can focus on all of the other features.<br>
><br>
> Our current approach, both in libinput and the WL protocol should make these<br>
> additions little more than adding a couple of enum, so I think we're good<br>
> here.<br>
><br>
>> >> 3) Fingers. There is a complication in XInput2 right now, since touch<br>
>> >> enabled Wacom devices have a special Finger XInput2 device, which<br>
>> >> provides both interfaces: tablet and touch and therefore generates<br>
>> >> both types of events. Right now Qt5 still cannot handle it properly,<br>
>> >> but the work is in progress. From Krita point of view, the main<br>
>> >> usecase for us is to distinguish whether the user paints with a finger<br>
>> >> of with the stylus. Because most of the users prefer to disable<br>
>> >> painting with fingers and use it for gestures/UI only (yes, palm<br>
>> >> detection works with non-100% probability).<br>
>> ><br>
>> > Right now libinput handles the finger device as another touchpad, since<br>
>> > that's usually what it is. Your use-case sounds perfectly valid though,<br>
>> > but IMO a better approach would be to add something to the protocol for<br>
>> > touchpads on wayland so that it can be known that they belong to a<br>
>> > tablet and provide any other sorts of data you might be need, so<br>
>> > programs like yours can treat them differently.<br>
><br>
> Dmitry, are you talking about pen/touch arbitration, i.e. don't send touch<br>
> events when the pen is in use. If so, that's definitely on the plan, we need<br>
> it for touchpads (disable while typing feature), and we need it for the<br>
> pen/touch interference.<br>
><br>
> This will be hidden away so you or event the compositor don't have to worry<br>
> about it.<br>
><br>
>> >> 4) Button Press/Release events should come in both cases: when the<br>
>> >> user clicks on the stylus' buttons and when the stylus touches the<br>
>> >> surface of the tablet.<br>
>> ><br>
>> > I'm not entirely sure that's a good idea. If I'm reading this right, you<br>
>> > mean that additional button presses should be sent when the tool touches<br>
>> > the surface of the tablet. [...]<br>
><br>
> We're already sending out BTN_TOUCH when the tip touches the surface, so I<br>
> think we're good here. Unless Dmitry was referring to something else.<br>
><br>
><br>
>> >> 6) It might be a good idea to define the physical properties of the<br>
>> >> axes. E.g. for tilt, rotation and tangential pressure. Afair, Wacom<br>
>> >> driver for XInput returns some not-very-obvious values right now. One<br>
>> >> would need to experiment to know what these numbers mean.<br>
>> ><br>
>> > We would all love for this to be the case I promise you, but<br>
>> > unfortunately it's not that simple for all of the axes. The distance<br>
>> > axis reports a seemingly meaningless value that can't be converted to<br>
>> > millimeters very easily. That being said, I have come up with a few ways<br>
>> > that we could actually convert it to millimeters, but this will have to<br>
>> > wait until I've fulfilled the goals for my Google Summer of Code Project<br>
>> > (unless anyone else wants to implement this in the mean time in libinput<br>
>> > of course).<br>
>> ><br>
>> > I'll write up the method I've come up with for converting this wild<br>
>> > value to actual millimeters at some point when I get the chance.<br>
>> ><br>
>> While I'm interested in seeing what you've come up with, I would be<br>
>> very hesitant to integrate the code into libinput. We make *no* claims<br>
>> about the physical resolution or accuracy of the distance axis. I've<br>
>> seen the value change by more than 10 units just by switching to a<br>
>> different pen... There's absolutely nothing stopping us from<br>
>> introducing a tablet that invalidates any clever code you may come up<br>
>> with.<br>
><br>
> yeah, I agree with Jason here, let's not pretend we have data we don't have.<br>
> As much as I'd like to attach concrete physical information to all axes we<br>
> can't (well, shouldn't) make it up.<br>
><br>
> Short of keeping a database of each tablet with the offsets and ratios to<br>
> convert distance values to mm I don't think this is doable, and I'm not a<br>
> big fan of that either.<br>
><br>
>> > As for the tilt axes of the tools, this is something that could be<br>
>> > represented in a more meaningful value. We could normalize it to a<br>
>> > number between 0 and 180°, so you can get the actual tilt in degrees as<br>
>> > opposed to what we currently have. This is something we could pull off<br>
>> > rather easily, I'll make sure to discuss this with my mentor tomorrow.<br>
>> ><br>
>> Alternatively, I would suggest adding an e.g.<br>
>> `libinput_event_tablet_get_axis_resolution` function. To get a<br>
>> physical value, a caller would just multiply whatever this function<br>
>> returns for some axis by the current normalized unitless value for the<br>
>> same. I suggest this for a few reasons: it is a fairly standard way of<br>
>> doing things (HID, the kernel, and X all use the same system), is more<br>
>> efficient (callers working in your preferred unit [e.g. Qt] are spared<br>
>> doing the conversion but anyone else [e.g. GTK, EFL] will have to do a<br>
>> second conversion to a different unit), and provides a way of getting<br>
>> physical information for any axis (if we ever came out with a pen that<br>
>> accurately measured distance, you wouldn't need to change the<br>
>> semantics of how distance is reported or sacrifice the now-existant<br>
>> physical translation information).<br>
><br>
> Jason: how accurate is tilt, and are applications actually using it as angle or<br>
> just as normalized number anyway?<br>
><br>
<br>
</div></div>I can't find a mention of the accuracy in any public docs, so I'm a<br>
little hesitant to give numbers on the list. The spec sheet does show<br>
it to be accurate to a handful of degrees though.<br>
<br>
The second part is a little complicated to answer. Every tilt-enabled<br>
program I'm aware of uses the data to adjust the brush azimuth. The<br>
goal is to have the virtual brush angled to be parallel with the<br>
physical pen at all times. A few applications also calculate an<br>
altitude angle, deforming the brush from circular to increasingly<br>
eliptical as the pen becomes more horizontal. Qt and Android (and<br>
likely EFL based on current discussions) have APIs that specify angles<br>
in various physical forms: tilt-x/tilt-y in degrees, alt-az in<br>
radians, etc. GTK on the other hand provides normalized data, but<br>
neither provides resolution information nor information about what<br>
"normalized" means. Because of the resulting ambiguity, GIMP and<br>
Inkscape do their calculations on the assumption that [-1, 1] in GTK<br>
corresponds to [-180 degrees, +180 degrees] in the physical world. GTK<br>
actually does its normalization based on the device's min/max though<br>
(so [-64 degrees, +63 degrees] for our hardware) meaning that GIMP and<br>
Inkscape wind up calculating incorrect azimuth values. The results<br>
aren't _that_ wrong though; I'm not aware of anyone having noticed or<br>
filing a bug about it.<br>
<br>
tl;dr, Applications universally /try/ to use the physical angles. Not<br>
all succeed.<br>
<div class="im HOEnZb"><br>
Jason<br>
---<br>
Now instead of four in the eights place /<br>
you’ve got three, ‘Cause you added one  /<br>
(That is to say, eight) to the two,     /<br>
But you can’t take seven from three,    /<br>
So you look at the sixty-fours....<br>
<br>
</div><div class="HOEnZb"><div class="h5">>> > As for tangential pressure, this is a term I've never actually heard of<br>
>> > before. I don't know what the values from the tablet are supposed to<br>
>> > correspond to in regards to pressure, so I've added two of our friends<br>
>> > at Wacom to the CC list help us out (I hope you two don't mind!) on<br>
>> > this.<br>
>> > (Jason and Ping, if you guys aren't on the list already, the original<br>
>> > protocol this e-mail is discussing can be found here:<br>
>> > <a href="http://lists.freedesktop.org/archives/wayland-devel/2014-June/015583.html" target="_blank">http://lists.freedesktop.org/archives/wayland-devel/2014-June/015583.html</a><br>
>> > )<br>
>> ><br>
>> > In regards to rotation and any other axes, I haven't had any contact<br>
>> > with these yet. So I can't really say much on them.<br>
><br>
> Rotation exists on the mouse/lens cursor tool, but it's a calculation based<br>
> on the tilt x/y axes. For us it'd just be one more axis.<br>
><br>
> Cheers,<br>
>    Peter<br>
><br>
>> I'm not sure where the term "tangential pressure" came from, but it<br>
>> can refer either to the fingerwheel on the airbrush tool (expected to<br>
>> be used to control ink flow rate; value is basically [0, 1]) or the<br>
>> fingerwheel on the 4D Mouse tool (which is like a spring-loaded<br>
>> mousewheel that reports how far forward or backward from the neutral<br>
>> position the wheel is; value is basically [-1, 1]).<br>
>><br>
>> Jason<br>
><br>
</div></div></blockquote></div><br><br clear="all"><br>-- <br>Dmitry Kazakov
</div>