How do I make Xglamo read directly from the touchscreen?
werner at openmoko.org
Fri Jan 9 00:32:23 CET 2009
Nelson Castillo wrote:
> I thought that we needed to have a small mach-gta02.c that works in mainline.
I don't think this is a condition for getting the design reviewed by
upstream. People will mainly be interested in seeing the code. The
other documentation you've prepared will of course help to strenghten
your case. If they want to try it on a Neo, they can just use our
tree, no problem. If they want to try the filters on something else,
they'll need to provide their own glue anyway. mach-gta02.c would
only confuse them ;-)
> that case, you cannot send feedback to the interrupt function. Not big deal,
> just ignore a bunch of points instead of discarding the bugus click.
> Sounds weird in userspace :-/
That depends. If you're using an existing kernel interface that
provides some abstraction, then you generally have no choice but to
do the work inside the kernel. E.g., a keyboard driver will usually
try to deliver keyboard events, not the scan matrix through some
However, if the interface is not at the kernel level but in user
space and the interface between kernel and user space is what you
choose it to be, I would consider minimizing the work done in the
kernel pretty normal. Driver gives you the raw data, then you
decide what to do with it.
> I feel you're trying to tell us there is a single path to solving the
> problem and that we
> are failing to follow it...
I think there are two issues here:
1) The general conflict whether any given functionality should be
implemented in the kernel or in user space. "If you can do it in
the kernel then don't do it in user space" is an approach that
was common in the early days of Linux. In recent years, the
tendency has become "if you can do it in user space then don't do
it in the kernel."
The line is blurry and there are no hard and fast rules. E.g.,
initramfs, FUSE, or udev vs. devfs are examples for the "do it in
user space" way. DRM (for X11) would be a recent example for
something going in the opposite direction.
But generally, the tendency is to do things in user space. This
is also "helped" by the long turn-around time for kernel changes
vs. updates to packages maintained outside the kernel.
2) You're duplicating an existing architecture, so - unless there's
already great unease about tslib - you'll have to convince people
that your solution is no only equivalent or slightly better, but
that it provides substantial benefits that would not be possible
with the existing architecture.
What helps is that you're reusing an existing interface. So the
departure from the status quo isn't quite as radical as it could
It'll be interesting to see how all this is received ;-) In any case,
it's important to get feedback. You've proven that your approach
solves the problem. Now it's time to join the group of people who
shape this part of the system architecture over time and perhaps
become one of them.
Good luck, and may the best solution win ! :-)
More information about the devel