From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752013AbcCJOIs (ORCPT ); Thu, 10 Mar 2016 09:08:48 -0500 Received: from zencphosting06.zen.co.uk ([82.71.204.9]:50182 "EHLO zencphosting06.zen.co.uk" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751825AbcCJOIk (ORCPT ); Thu, 10 Mar 2016 09:08:40 -0500 Subject: Re: [PATCH RFC 0/8] Input: atmel_mxt_ts - raw data via debugfs To: Dmitry Torokhov References: <1449088951-7069-1-git-send-email-nick.dyer@itdev.co.uk> <5672EF68.3000800@itdev.co.uk> <20160111232413.GA39766@dtor-ws> <20160112081041.GB19287@mail.corp.redhat.com> <56968779.5060302@itdev.co.uk> <20160113184005.GB39593@dtor-ws> Cc: Benjamin Tissoires , Benson Leung , linux-input@vger.kernel.org, linux-kernel@vger.kernel.org, Alan Bowens , Javier Martinez Canillas , Chris Healy , Henrik Rydberg , Andrew Duggan , James Chen , Dudley Du , Andrew de los Reyes , sheckylin@chromium.org, Peter Hutterer , Florian Echtler From: Nick Dyer Message-ID: <56E17FED.2010104@itdev.co.uk> Date: Thu, 10 Mar 2016 14:08:45 +0000 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.6.0 MIME-Version: 1.0 In-Reply-To: <20160113184005.GB39593@dtor-ws> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit X-OutGoing-Spam-Status: No, score=-0.4 X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - zencphosting06.zen.co.uk X-AntiAbuse: Original Domain - vger.kernel.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - itdev.co.uk X-Get-Message-Sender-Via: zencphosting06.zen.co.uk: authenticated_id: nick.dyer@itdev.co.uk X-Authenticated-Sender: zencphosting06.zen.co.uk: nick.dyer@itdev.co.uk Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org > 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