On 21/10/14 13:22, One Thousand Gnomes wrote: >> If you will have touch processing in a binary blob, you'll also be going >> to ages "Works with Ubuntu 12.04 on x86_32!" (and nothing else), or >> "Android 5.1.2 on Tegra Blah (build 78912KT)" (and nothing else). > > As well as not going upstream because there is no way anyone else can > test changes to the code, or support it. Plus of course there are those > awkward questions around derivative work boundaries that it is best the > base kernel keeps well clear of. > > If the data format is documented to the point someone can go write their > own touch processor for the bitstream then that really deals with it > anyway. Given the number of these things starting to pop up it would > probably be good if someone did produce an open source processing engine > for touch sensor streams as it shouldn't take long before its better than > all the non-free ones 8). Thank you for this input, I will feed it back. > Given how latency sensitive touch is and the continual data stream I > would be inclined to think that the basic processing might be better in > kernel and then as an input device - providing it can be simple enough to > want to put kernel side. I would think that a touch processing algorithm (including aspects such as noise and false touch suppression, etc) would be too complex to live in-kernel. Getting decent performance on a particular device requires a lot of tuning/customisation. > Otherwise I'd say your bitstream is probably something like ADC data and > belongs in IIO (which should also help people to have one processing > agent for multiple designs of touch, SPI controllers etc) This sounds promising. The only sticking point I can see is that a touch frontend has many more channels (possibly thousands), which would seem to impose a lot of overhead when put into the IIO framework. I will certainly take a closer look at it. -- To unsubscribe from this list: send the line "unsubscribe linux-input" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
