Hi Jason, Now, this has taken me some time, hasn't it? Sorry for such a huge delay.
It took me some time, because I wasn't content with my arguments and the way I was expressing myself and I still am not. So, sorry if I'm hard to understand or I don't provide good enough arguments. On 03/31/2012 02:45 AM, Jason Gerecke wrote: > On Fri, Mar 30, 2012 at 3:11 AM, Nikolai Kondrashov<spbn...@gmail.com> wrote: >> I'm assuming applications don't actually expect reported values to be in >> degrees, but rather expect fractions of the maximum 60 degree angle. >> > It looks like the truth was somewhere between both of our assumptions. > We should report in integer degrees, and need to be clamped between > -60 and +60. It seems we should do so, at least for the time being. However, we should really inform toolkit and application developers about what we're actually producing. We should also look at what other drivers do and push for uniformity. >> I've tried looking at the GIMP and mypaint code and it looked like it, but >> I'm not 100% sure. At least both of them worked fine with the maximum of >> 105, which Waltop Sirius kernel driver currently produces. However, I don't >> have a Wacom or, in fact, any other tilt-reporting tablet to compare to. >> > GIMP, Inkscape, and MyPaint all treat the values they get from GTK as > the normalized length of the tool's projection along the corresponding > axis (they take the arctangent of the values to get an azimuth). > While GTK doesn't explicitly state that this is what applications receive, > its a reasonable reading of their documentation: "tilt attributes range > from -1.0 to 1.0 ... representing the maximum tilt to the left or up ... > [and] to the right or down". It looks like in practice GTK actually only > scales the tilt values it gets from X based on the minimum and maximum. > Its not what applications expect, but appears to work well enough that > nobody's bothered to file a bug. Now, this is interesting. So they're expecting sines instead of angles. Shall we do something about this? > Krita, however, does appear to depend on the magic number 60 when > dealing with tilt. Diving deeper, it appears that the Qt API actually > states applications will receive "the angle between the device (a pen, > for example) and the perpendicular" and that "the angle is in the > range -60 to +60 degrees". Qt itself doesn't enforce this at all, and > just stuffs whatever data it receives from X into the tilt variables. > That means that for now we've got to be careful to do the clamping > ourselves. I'll update my patch to convert to degrees and will send the new version. >> I'm OK with the fixed maximum angle, because there is only so much tilt a >> human hand is comfortable to do. Although I'm not sure it is exactly 60 >> degrees, I'm inclined to trust Wacom's judgement and expertise in this >> matter. >> > I'm of the opinion that if we should keep the maximum fidelity > possible when passing data up the stack. If a tablet comes out that > can sense a full 90 degrees of tilt, I figure its the driver's job to > provide applications with the full range. Of course, if things are > written assuming a limited range of motion (like Qt apparently was) > then we need to let them know the assumption was invalid and be > mindful of compatibility in the meantime. There are several things to consider. The root of the problem is that, AFAIK, the X input API doesn't allow describing non-linear valuators. I.e. xf86InitValuatorAxisStruct only accepts linear resolution in points/meter. The best way would be to change that. That would end our troubles, shifting them to toolkit or application developers, where it is maybe better handled. Though, I don't think this could happen easily. Thus, we're trying to circumvent the system by inventing an out-of-system convention. This is also done for tip pressure, but tip pressure was never assigned units and resolution (although in HID standard it can be) and this is compensated by pressure curves. We could agree that in case of tilt, the resolution specified through xf86InitValuatorAxisStruct actually means something relevant. However, this stretches the API definition a bit more, than simply specifying 1, meaning "undefined". I would rather go the full way of extending the API instead. Thus, we can't specify the resolution, at least for now, and should agree on either fixed resolution or fixed range. I assume you're suggesting fixing both the resolution and physical range for now and then leaving only the resolution fixed. I agree on the first part, but not the second. I think it is more practical to fix the physical range in this case. Below I'll try to prove my point. First of all, I still think that there is only so much tilt a human hand is comfortable to do, without changing the grip on the pen. I'm not sure if it's exactly 60 degrees, but it seems about right and I guess Wacom did some research on this matter. Next, the users should get the same effect from the application for the same amount of physical tilting they do, no matter which tablet they use. I.e. if I tilt my hand this way with this tablet and draw a line, it should look the same as if I did it with another tablet. If we fix the resolution, we will need to update GTK, GIMP, mypaint and Inkscape (at least) to expect different range from different tablets. Because, if we don't, we will be effectively binding maximum tilting effect to maximum sensed physical tilt of a tablet in these applications. Application developers target the typical physical tilt range and thus tie effect's full expressive range to that physical range. Then, if a tablet has, say half of that range it will be hard to draw a smooth line, because the effect will be thrown about at the slightest jerk of the pen. If a tablet has, say, 50% more range, then, to reach the maximum effect, the user will have to hold the hand in an uncomfortable position and the quality of the drawing will suffer. Now, how the toolkits and applications could account for different physical tilt range of different tablets? Should they bind the same effect to the same physical angles? If they do so, they would still target the majority of the users, providing effect's useful expressive range for a typical tilt range. What shall the effect look like, when the tilt exceeds that range? Will it be meaningful? How many developers will be able to test that, provided most of them have typical tilt range tablets? This will, effectively, just limit the physical tilt range. Still, we can leave both resolution and range fixed, provided the resolution is high enough, and 1 point per degree was considered good enough for quite a while now. However, since most applications are already prepared to deal with variable tilt value range, it seems good to me to avoid unnecessary conversion and associated slight precision loss. And limiting physical range only requires clipping and no multiplication. >> BTW, has anyone actually tried to measure the angles corresponding to >> reported values with a Wacom tablet? >> > The reported values are correct to within a few degrees. While > marketing indicates +-60 degrees, the tablets will report all the way > out to +-64 degrees since they've got a 7-bit field to fill. It > doesn't appear to change with the sine of the angle (unlike the > Sirius), but my tests were admittedly rough. Considering all the misinterpretation in applications this is indeed insignificant. However, I think it's better to figure it out and specify the correct resolution in the kernel drivers. >> The absinfo.resolution is in units/radian, as agreed to by the kernel folks, >> for rotary controls. It could have been units/degree, but this would reduce >> the precision. However, it makes no sense introducing an artificial unit of >> units/Pi*2, especially since the HID spec doesn't use it. >> > Didn't know that :) I couldn't find any kernel docs to indicate an > appropriate unit, so I made one up on the spot. There are no kernel docs. And there was no explicit agreement on tilt resolution units. There was agreement on rotary resolution units and my patch to add tilt to that was accepted recently: http://git.kernel.org/?p=linux/kernel/git/jikos/hid.git;a=commitdiff;h=b73b2da0353d15b712b27b1aed3c50856bdfc341 So, to summarise, I suggest the following plan: 1. Have both resolution and range fixed. I'll update my patch to scale tablets reporting tilt resolution to +-60. 2. Verify units Wacom uses by asking Wacom engineers and/or measuring it. Make kernel driver report it. Make kernel driver report zero-centered values. I can make the patches. 3. Ask Qt developers to correct their notion of the tilt to be varying resolution. They already expect fixed physical range. This is better to be originating from xf86-input-wacom developers. 4. Stop fixing the resolution. I can do the patch when the time comes. Additionaly, I think we should ask GIMP, Inkscape and mypaint developers to interpret values as angles and not sines. What do you think? Thank you for your attention. Sincerely, Nick ------------------------------------------------------------------------------ Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ _______________________________________________ Linuxwacom-devel mailing list Linuxwacom-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/linuxwacom-devel
