How do I make Xglamo read directly from the touchscreen?

Werner Almesberger werner at
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
private interface.

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 ! :-)

- Werner

More information about the devel mailing list