On Sat, May 19, 2012 at 8:37 AM, Nikolai Kondrashov <spbn...@gmail.com> wrote: > 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. > > Not a problem. There's no rush to get this off the ground, and I prefer well-thought-out arguments anyway! :)
> 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. > > Absolutely. >>> 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? > > I'll tackle this in the summary. >> 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. > While I agree with what you've said in the strict sense, I think extending the API with new code just to specify axes with angular resolution is overkill. Applications are already able to determine what any given axis is by its label (e.g. AXIS_LABEL_PROP_ABS_TILT_Y) so its not like there would be any confusion over whether the axis resolution is in linear or angular units. The only thing necessary is to update the documentation to state appropriate units for angular valuators (e.g. counts per radian). > I assume you're suggesting fixing both the resolution and physical range for > now and then leaving only the resolution fixed. > You're right on the first part, though I think the ideal outcome of this transition would be having *neither* fixed. We would get both physical range and resolution from the kernel and then set up the X11 valuators to be equivalent. It would take time to get to the point that we could do that, but so would fixing just one or the other -- might as well get it right if we're going to go through the pain anyway. > 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. > I agree that the same effect should be achieved for the same application settings and amount of physical tilt regardless of tablet. As you point out, trying to use an effect directly mapped to tilt would in most cases be difficult at extreme angles. The effect should go full-scale at some defined angle, not at the maximum supported angle. That said, the full-scale angle for an effect is something to be decided by the *effect* not the driver. Sure, we could limit all tablets to 60 degrees of tilt, but what would be the point? Just because the human hand is limited to ~60 degrees isn't a reason for us to clip perfectly valid input beyond that point. If an application wants to ignore (or use) it, that's their own prerogative. GIMP and MyPaint for instance put the onus on the user to decide what tilt values are useful. Both provide you with control over how tilt is interpreted when applying the effect. If I have a tablet that exceeds the typical tilt range all I need to do is adjust the setting if I feel it is uncomfortable. Even a typical tablet can map its tilt to the entire effect range, so the questions you raise are moot. You mentioned that GTK, GIMP, Inkscape, and mypaint would need to be patched to have fixed-resolution data without binding physical range to logical range. That's incorrect. Applications built on GTK are provided normalized tilt values, meaning the specifics about hardware range is stripped away. Regardless of if we provided fixed-resolution or fixed-range data, only GTK would need patching to ensure applications get the correct data. > 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. > > I wouldn't be too worried about this. The tablet may be able to report angles with 1 degree of precision, but moving your hand while maintaining a constant angle is quite difficult. Furthermore, the tablet has its own accuracy spec that is another source of error. Suffice it to say that any calculation-induced inaccuracy would be swamped by these two much larger error sources. >>> 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. > Yes. > 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. > I'll be replying to your results below soon :) > 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. > Yes. Regardless of what we do, Qt needs to look at the valuator minimum, maximum, and resolution, and use that information to transform whatever tilt values they receive to honor the guarantees provided by their API. In addition to being able to handle varying resolution, they should be able to handle varying range (by clamping to their specified [-60, +60] range). > 4. Stop fixing the resolution. I can do the patch when the time comes. > Yes. Though I'd also like to be in a position where we can stop fixing the range as well :) > Additionaly, I think we should ask GIMP, Inkscape and mypaint developers to > interpret values as angles and not sines. > As far as we can tell, most applications interpret their documentation to mean that they're being provided sines. It'd make more sense to patch GTK to just take the sine of our angles and pass them on. The documentation should also be expanded so this is no longer an assumption. This will decrease the altitude sensitivity of brushes since approximately [-90,-60) and (60,90] degrees will no longer be accessible by Wacom hardware, but its a problem that can be fixed by the end-user by adjusting the brush settings. > What do you think? > > Thank you for your attention. > > Sincerely, > Nick Thanks for your effort on this, Jason --- Day xee-nee-svsh duu-'ushtlh-ts'it; nuu-wee-ya' duu-xan' 'vm-nvshtlh-ts'it. Huu-chan xuu naa~-gha. ------------------------------------------------------------------------------ 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
