Bottom line points: -nothing is gained from passing raw coordinates to evdev -passing calibrated coordinates to evdev makes software calibration optional.
I do not want to have to do software calibration. If you want to, fine, you can do it just as well using hardware-calibration coordinates as raw coordinates. You won't ever notice the difference. Please, can we pass hardware-calibrated coordinates up from the 3M touch screen? :) On Thu, 17 Feb 2005, Paulo Marques wrote: >Dan Streetman wrote: >> [...] >>>One reason is to make the behavior of all touchscreens as similar as >>>possible, so that applications don't have to care. >> >> >> But...you want to force software calibration just for consistency? >> Really? > >Really :) > >Think about it. What does the software have to do to use the touchscreen >hardware calibration? At the very least it as to draw the markers the >controller is expecting and instruct the user to press them. > >Lets say that it is currently 2 markers or 21 markers. Then another >manufacturer comes along and says "no, our touchscreen is much better >because it uses a 5 point linear calibration or a 45 point non-linear >calibration", and you'll have to change your software to cope with that. > >More over, you will still need to provide software calibration for those >touchscreens that don't support it. So you have all the extra work to >support hardware calibration and it won't remove any work from the >software calibration. > >Bottom line, if we have the same raw information that is already >available to the controller, do you think we can't do the same job the >controller does, in software? > >This way, if we decide to provide a 5x4 20 points non-linear super-duper >mega hyper calibration algorithm, it will be available to *all* >supported touchscreens at no extra cost. > >We can also do a lot more stuff in software, like requesting a 3 point >calibration and validating that they are somewhat orthogonal, and reject >them and request a new calibration if they aren't. > >The more touchscreen models and brands we support, the more painful it >will be to support hardware calibration. Believe me, we don't want to go >down that road. > >This has been discussed recently in a "elo touchscreen..." thread. The >conclusion was that we needed a nice user space library to provide this >kind of services (calibration, filtering, etc.), so that applications >that worked with touchscreens could have more specific API than the >generic one provided by the input layer. > > -- Dan Streetman [EMAIL PROTECTED] --------------------- 186,272 miles per second: It isn't just a good idea, it's the law! ------------------------------------------------------- SF email is sponsored by - The IT Product Guide Read honest & candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click _______________________________________________ linux-usb-devel@lists.sourceforge.net To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
