How do I make Xglamo read directly from the touchscreen?
nelsoneci at gmail.com
Fri Dec 26 22:53:55 CET 2008
On Fri, Dec 26, 2008 at 4:08 PM, Holger Freyther <zecke at se.org> 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
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.
More information about the devel