Dnia 2010-01-04, pon o godzinie 17:15 -0800, Ping pisze: > > Please check out attached file and let me know if the function is good > > enough to replace the hardcoded data. I've some idaes how to improve the > > match between hardcoded data and the family of functions (if that's the > > name for a function with parameters), but I don't want to make it too > > complicated if it's not necessary. > > Is f(x) = a (x - b), with different a and b, the function that you > used to create the graph? > It's rather f(x)=a/(x-b), with a = f(x) and b = f(x) :-) > The tables we see in the code is for 1/8 (0 to 45 degrees) of the > whole range of the values. The whole tilt to rotation translation is > on a 360 degree base, which we made them into 1800 values, with an > incremental of 2 of each movement. I want to keep it the same - for a while at least ;-) > The actual rotation used in the driver is defined in xf86Wacom.c for > cursor and stylus with rotation supported. The value is from -900 to > 899, which covers 1800 values. OK, so I understood it correctly. > So, I think, I am not exactly sure though: > > 1. the new function should cover all 360 degrees instead of 45; I want to use part of existing code to do it to cover 360, but it's an option. > 2. there should be a trigonometric function (the sine, cosine, or > tangent) involved. > > Some comments: > > 1. there should be a condition added to cap returned angle to 45 > > 2. what is range of ds->rotation? > > This piece of code (wcmTilt2R function) suggests that it's up to > > 1800: > > > > /* Intuos4 mouse has an (180-5) offset */ > > ds->rotation = ((360 - ds->rotation + 180 - 5) % 360) * 5; > > > > Using real numbers generated by the funcion instead of hardcoded integer > > values would give us smoother curve; final ds->rotation value would be > > integer anyway, but with more "fine grained" values. Is it worth to do > > it or it's something that user cannot notice? > > > > Please ignore point 2 if it's not clear for you. > > I will not ignore any point especially when it is not clear to me :). > Quite a stubburn person, uh? It means that I have a chance to explain it in a better way :-) The current way of defining the translation curve (tilt_x,tilt_y -> rotation) creates some "steps" on the curve. Multiplying the curve by 5 to stretch range of values to 1800 doesn't remove the steps. See attached pdf for comparison.
To recap: we have to find a function that converts tilt_x (-64 to 64) and tilt_y (-64 to 64) on rotation (0-360) and the we can tweak it for intuos4 range (-900 to 899)? I think I should just do it (as a patch) and than you can test it and decide if it's good enough. -- Przemo
tilt_tables.pdf
Description: Adobe PDF document
------------------------------------------------------------------------------ This SF.Net email is sponsored by the Verizon Developer Community Take advantage of Verizon's best-in-class app development support A streamlined, 14 day to market process makes app distribution fast and easy Join now and get one step closer to millions of Verizon customers http://p.sf.net/sfu/verizon-dev2dev
_______________________________________________ Linuxwacom-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/linuxwacom-devel
