-----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-----