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

On Jan 11 2016 or thereabouts, Dmitry Torokhov wrote:

Hi Nick,

On Thu, Dec 17, 2015 at 05:22:48PM +0000, Nick Dyer wrote:

quoted

On 02/12/15 20:42, Nick Dyer wrote:

quoted

This is a series of patches to add diagnostic data support to the Atmel
maXTouch driver. There's an existing implementation in the open-source mxt-app
tool, however there are performance advantages to moving this code into the driver.
The algorithm for retrieving the data has been fairly consistent across a range of
chips, with the exception of the mXT1386 series (see patch).

The intention is to open-source a utility which can read/display this data, this
should be available very shortly.

Hi-

The utility to read this data has now been released, and you can find it at:
https://github.com/ndyer/heatmap

I've recorded a couple of videos of the utility in action on a Pixel 2:
* https://youtu.be/M0VD2gZt8Zk
* https://youtu.be/nwDLB4zikzU

Thank you for sharing the utility and the recording, but it seems that
there is a desire to get access to the heat maps not only for
validation, but also for certain processing purposes, and so I do not
think that we should try to standardize on debugfs as the interface, but
rather look for something that allows better performance.

I wonder if the interface should look similar to the V4L2 capture API
where application opens a character device, uses several ioctls to query
its capabilities/set up capture parameters (i.e reference or deltas),
select()s file descriptor for reading and then uses mmap() to access the
captured heat map.

I've CCed a few people who might be interested in this topic.

I've added Florian, who worked on the driver for the Surface 2.0 which
does exactly that, exports the heat map through V4L2.

See drivers/input/touchscreen/sur40.c for his driver.

Cheers,
Benjamin

Thanks.

-- 
Dmitry