> 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). 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. 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) Alan -- 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
