On Fri, Dec 26, 2008 at 4:08 PM, Holger Freyther <[email protected]> wrote: > On Friday 26 December 2008 21:38:14 Andy Green wrote: > >> | for evdev and the calibration data? >> >> It's a good point, is there a way to associate the input event devicets_raw >> ande s >> that sends coordinates with the way that you set its calibration? > > With tslib? Yes. in the ts.conf you define which input_raw which device to use > and then stack modules and its configuration on top.
I see. Right now our filtering is working very well. You could use tslib just for calibration. We added calibration in kernel because this was the only task left to tslib. But you can still use the touchscreen the way you like it... I guess it is up to the distributors what to use. Using /dev/input/eventX directly is just an option that I would like to try. What is actually important now is that the driver is working well, much better than with the current stable kernel and this is an improvement users will like (I hope). As Andy said, there was some filtering in drivers already, but it was not stacked nor organized. Now the TS driver is smaller, without filtering or averaging in the same file. Also, the filters can be used by other drivers. >> Now the arrangements in kernel that are specific to the touchscreen >> shipped give great data already, tslib seems needless. If I understood >> what Nelson is asking, it's just about removing tslib from inbetween the >> input subsystem data and XGlamo. Not --> That was my question indeed. > I'm glad that you respond here because I have a couple of issues with the > current version (as much as I understand it): > > - XCalibrate Extension -> broken, so user recalibration is not working > > - We require custom machine specific code/shell/script to find the > device and > set the calibration data (e.g. the ts could be on serial as well..) which is a > step back from a different ts.conf and pointercal... So you need a stable > general purpose interface to configure such things (enumerable as well...) As I read in other email, we could have symlinks. > - Currently (from the sysfs interface) it looks like all this is > implemented > in one driver, with a userspace hat on I would like to wait until this is more > generalized, with my kernel hat and iPAQ history I would be surprised if a in > kernel calibration, linearisation will end in the kernel. Not just in one driver... it is a general filter that can be stacked, just like it is done in tslib. I just wonder... Are things this way because this is best or because this is a working solution that people already used to? And in any case, things will still be compatible with tslib. Perhaps once people start seeing ts.conf files having only two lines they will realize they do not really have to depend on it. And of course, we would have to add the missing bits, like the symlinks to make things easier. _______________________________________________ devel mailing list [email protected] https://lists.openmoko.org/mailman/listinfo/devel
