Re: [PATCH RFC 0/8] Input: atmel_mxt_ts - raw data via debugfs

[Nick Dyer <nick.dyer@itdev.co.uk>]

> On Wed, Jan 13, 2016 at 05:20:57PM +0000, Nick Dyer wrote:
>> The devices we want to support are I2C based and the frame rate is low:
>> typically less than 10 fps with 1386 nodes, as an example. So performance
>> is not critical and doing meaningful processing is not really feasible.
>>
>> The use cases we want to support are diagnostic, for instance tuning and
>> analysing touch sensor manufacturing defects. It's useful in this context
>> to be able to interrogate the device using the command line or shell scripts.
> 
> I understand that the current controller and firmware you are working on
> is not suitable for actual processing and the data rate is only useful
> for diagnostic. This does not mean however that we can't use the same
> high-speed interface for both diagnostic and processing, if such
> interface is available. And given that there is desire to do some of the
> host-side processing I'd prefer to standardize on interface that is
> suitable for both instead of stuffing driver-specific bits into debugfs.

Hi Dmitry-

We've begun to look at re-implementing this using V4L2.

One additional thing that I wanted to raise in relation to this feature.
The diagnostic data available from these chips is not limited to raw
capacitance value data for each node on the touch matrix. Examples might be:

* One reading per X/Y line, eg a noise measurement
* Single values, for example a frame counter
* Raw pressure/button data from an active stylus

It's unclear exactly how we are going to expose this kind of information at
the moment.

One option seems to be the multi-plane support in V4L2, or defining a
custom struct for embedding this data in the V4L2 frame.

But the number of differences between chip versions means that we might
have to settle for having some way to get the raw data stream out and
forward it to some user space tool which is able to decode.

Nick