Reminds me of a recent touch-screen debate. [LWN.net]

Reminds me of a recent touch-screen debate.

Posted Dec 2, 2009 22:34 UTC (Wed) by neilbrown (subscriber, #359)
Parent article: Kernel support for infrared receivers

touch screens - such as on the Openmoko freerunner - tend to deliver noisy data, particularly when touched lightly. Should this be processed in-kernel then passed out as nice clean mouse events, or should the raw data get to user space to be processed, and then possibly sent back through the kernel (via uevent) or directly to the application?

It sounds like much the same problem, and it seems likely that the same theme will keep coming up as Linux gets used in more interesting devices.

To my mind, the principles of freedom and openness suggest that the author of a particular driver should be free to manage the processing however (s)he wants. As long as we do get the fully processed events coming from the input subsystem in the kernel, the path they take to get there must be left to the author or maintainer of the code.

Putting it a different way, I think that the interface that needs to be stable is the interface to applications, not the interface to the kernel. More and more, there are user-space programs that work closely with the kernel to provide particular functionality. Freezing the interface between those programs and the kernel seems silly. Freezing the interface between the functionality and the applications is where the focus should be. For both LIRC and touch screens, the frozen interface should be the input subsystem. Where raw noisy inputs are processed is just an implementation detail.

(Log in to post comments)

Reminds me of a recent touch-screen debate.

Posted Dec 3, 2009 5:41 UTC (Thu) by xtifr (subscriber, #143) [Link]

"Principles of openness and freedom" are great when you're working on your own stuff, more-or-less independent of others, as the LIRC folks seem to have been doing for some time, but when you start to work with others, new considerations can come into play, such as compatibility, comprehensibility, not stepping on toes, demarcation of boundaries, etc., etc. It's called cooperation, and if LIRC is going to be accepted into the main kernel source tree, then the devs are going to have to cooperate with the folks in charge of the main tree.

If everyone working on drivers were to just do whatever they want, without consideration for how the rest of the kernel operates and is maintained, the kernel would have collapsed under the weight of a million tiny incomprehensibly incompatible interfaces (III) a long time ago! That's why "benevolent dictators" are so critical to successful projects.