-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Somebody in the thread at some point said: | On Friday 26 December 2008 22:36:42 Andy Green wrote: | |> No the kernel touchscreen filter stuff is independent of the driver, it |> is implemented separately and resuably. | | Ah okay. From my non existing knowledge of the code I think using a | input_handler to export a "calibrated, normalized..." touchscreen with some | ioctol/sysfs to do the configuration is the best configuration. And at that | point I wonder how the result is different from a ordinary one button PS2 | mouse?
Other than the coordinates will be absolute, and the need for the calibration action, not much. And of course those things are input event device nodes as you recognized. |> I agree upstream requirement for tslib seems entrenched, and yet we have |> a really good solution for GTA02 touchscreen function in kernel now that |> we didn't have before, and couldn't get until now in tslib. And that's |> true whether upstream sees value in no-tslib solution or not. | | couldn't get. I recognize that it is more easy for some people to work on the | kernel but it is also true that writing a filter for ts_lib is very very | simple. I'm confident that I could move the code of your filters into userspace | and write it as module for tslib. Of course you can cut and paste the filters into a tslib implementation.... but since the filters are decimating the input stream, it's more power-efficient to do it in the ISR as we do now and just send the reduced rate of results into the input subsystem to unblock a userspace process, cutting the wake rate. As Nelson said it's better to issue clean data once from the right tap into userspace, it's easy to agree with that if we were at the point that adding a capacitor to the design would make it all clean from the ADC onward we would choose to clean it as early as possible. (The median filter particularly is quite powerful, we're able to run the touchscreen ADC hardware itself at its lowest rate on andy-tracking with that and get great results). |> It'll help getting this upstream if it allows complete removal of tslib, |> ~ so it's good to hear these points, but it's also good Nelson is asking |> about what's involved to remove the anomalies created by tslib elsewhere |> as part of studying that... | | Right, we get to a point I understand what is happening. I will try to get | some background on tslib, Russell King started the library and I will ask | Chris Larson (current maintainer of tslib) if he can give us some input. Great, although it may require Chris to be broadminded to hear us planning making what he's maintaining unnecessary in some situations. If it isn't anathema then of course I'm also interested in any ideas that make the filter chain stuff more general or more useful. - -Andy -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org iEYEARECAAYFAklVXH0ACgkQOjLpvpq7dMrXegCgjWn+VHjKclqC4Gh/WJv+0Fj0 kBkAn1DelNXPu/jON2sDBDvdZPogLwgp =KWGX -----END PGP SIGNATURE----- _______________________________________________ devel mailing list [email protected] https://lists.openmoko.org/mailman/listinfo/devel
