Re: Touch processing on host CPU

[One Thousand Gnomes]

> 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-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/