2010/1/5 Przemysław Firszt <[email protected]>: > 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) :-)
It was a typo. >> 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 ;-) Thank you. >> 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. Something you may want to consider is to convert the values into integers later (after the calculation). It may offer a better accuracy (maybe not that much though). >> 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)? Correct. > I think I should just do it (as a patch) and than you can test it and > decide if it's good enough. Sure. Ping ------------------------------------------------------------------------------ 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
