A touchscreen driver has been posted upstreams

[Nelson Castillo]

On Tue, Nov 24, 2009 at 5:09 PM, Werner Almesberger <werner at openmoko.org> wrote:
> Nelson Castillo wrote:
>> The main problem now is that there is no way from userpace to
>> communicate back to the kernel. But this might not be needed if it's
>> OK to lose some computing power (not much I guess).
>
> You mean for the sample rate change ? It seems that this is the
> kind of kernel change that wouldn't face much resistance.

There is something nice that we can do in the kernel that you cannot
do from userspace, and that is asking for points on demand without
delays (you decide whether you need more points or not in an interrupt
handler using feedback from the filter chain). Usually you need more
points when there is noise (say because of little pressure).

What I think is that you can also filter the noise in userspace if you
send more a lot more points to userspace (in packets). It seems this
is the way ts drivers should be implemented according to Russell. For
us it would mean that we have to schedule N conversions and send all
the points to userspace (instead of averaging them or mangling them in
any way). It doesn't mean that we can use the filters in the same way
we are using them now.

It would be nice if you could configure filters from userspace (just
as a concept, I'm not saying I will work on it. I guess upstream
people would hate it anyway :-) ). That would mix efficiency with
flexibility. Unfortunately the filters have to be used from interrupt
handlers and it means you would have to modify drivers (I am comparing
with iptables/ebtables where I guess that NIC drivers don't know a bit
about filters).
Joeg sais this seems to be a task for a driver but because of what I
just wrote I'm not sure if this can be done.

> Of course, if the overhead is negligible even at a high rate,
> you may not care. (I don't remember - is it ?)

I still don't know.

I really don't care that much since at least we have a patch-set that
solves the problem for us. It would be nice to see a more correct
solution so that we don't have to carry many patches, though. That's
why I think I'll do some tests later.