From mboxrd@z Thu Jan 1 00:00:00 1970 From: One Thousand Gnomes Subject: Re: Touch processing on host CPU Date: Tue, 21 Oct 2014 13:22:29 +0100 Message-ID: <20141021132229.37a1197c@alan.etchedpixels.co.uk> References: <5440F282.8040306@itdev.co.uk> <20141017171756.GA22238@dtor-ws> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <20141017171756.GA22238@dtor-ws> Sender: linux-kernel-owner@vger.kernel.org To: Dmitry Torokhov Cc: Nick Dyer , Greg KH , Jonathan Cameron , "linux-input@vger.kernel.org" , "linux-kernel@vger.kernel.org" List-Id: linux-input@vger.kernel.org > 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