linux-kernel - Re: [PATCH RFC 0/8] Input: atmel_mxt_ts

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Date:	Thu, 10 Mar 2016 14:08:45 +0000
From:	Nick Dyer <nick.dyer@...ev.co.uk>
To:	Dmitry Torokhov <dmitry.torokhov@...il.com>
Cc:	Benjamin Tissoires <benjamin.tissoires@...hat.com>,
	Benson Leung <bleung@...omium.org>,
	linux-input@...r.kernel.org, linux-kernel@...r.kernel.org,
	Alan Bowens <Alan.Bowens@...el.com>,
	Javier Martinez Canillas <javier@....samsung.com>,
	Chris Healy <cphealy@...il.com>,
	Henrik Rydberg <rydberg@...math.org>,
	Andrew Duggan <aduggan@...aptics.com>,
	James Chen <james.chen@....com.tw>,
	Dudley Du <dudl@...ress.com>,
	Andrew de los Reyes <adlr@...omium.org>,
	sheckylin@...omium.org, Peter Hutterer <peter.hutterer@...-t.net>,
	Florian Echtler <floe@...terbrot.org>
Subject: Re: [PATCH RFC 0/8] Input: atmel_mxt_ts - raw data via debugfs

> 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