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 be. 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 _______________________________________________ devel mailing list [email protected] https://lists.openmoko.org/mailman/listinfo/devel
