Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.kernel > #1306816 > unrolled thread

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

Back to article view | Back to linux.kernel

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.

Contents

  Re: [PATCH RFC 0/8] Input: atmel_mxt_ts - raw data via debugfs Dmitry Torokhov <dmitry.torokhov@gmail.com> - 2016-01-12 00:30 +0100
    Re: [PATCH RFC 0/8] Input: atmel_mxt_ts - raw data via debugfs Benjamin Tissoires <benjamin.tissoires@redhat.com> - 2016-01-12 09:20 +0100
      Re: [PATCH RFC 0/8] Input: atmel_mxt_ts - raw data via debugfs Nick Dyer <nick.dyer@itdev.co.uk> - 2016-01-13 18:30 +0100
        Re: [PATCH RFC 0/8] Input: atmel_mxt_ts - raw data via debugfs Dmitry Torokhov <dmitry.torokhov@gmail.com> - 2016-01-13 19:50 +0100
          Re: [PATCH RFC 0/8] Input: atmel_mxt_ts - raw data via debugfs Henrik Rydberg <rydberg@bitmath.org> - 2016-01-13 22:00 +0100
      Re: [PATCH RFC 0/8] Input: atmel_mxt_ts - raw data via debugfs Dmitry Torokhov <dmitry.torokhov@gmail.com> - 2016-01-13 19:40 +0100

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

Hi Nick,

On Thu, Dec 17, 2015 at 05:22:48PM +0000, Nick Dyer wrote:
> On 02/12/15 20:42, Nick Dyer wrote:
> > 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.

Thanks.

-- 
Dmitry

[toc] | [next] | [standalone]

#1307077

On Jan 11 2016 or thereabouts, Dmitry Torokhov wrote:
> Hi Nick,
> 
> On Thu, Dec 17, 2015 at 05:22:48PM +0000, Nick Dyer wrote:
> > On 02/12/15 20:42, Nick Dyer wrote:
> > > 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

[toc] | [prev] | [next] | [standalone]

#1308655

Hi Ben/Dmitry-

On 12/01/16 08:10, Benjamin Tissoires wrote:
> On Jan 11 2016 or thereabouts, Dmitry Torokhov wrote:
>> On Thu, Dec 17, 2015 at 05:22:48PM +0000, Nick Dyer wrote:
>>>> 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.
>>>
>>> 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.

That's very interesting, thanks. I do think there is a difference in intent
between the debugfs interface we are proposing and the video interface.

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.

Nick

[toc] | [prev] | [next] | [standalone]

#1308724

On Wed, Jan 13, 2016 at 05:20:57PM +0000, Nick Dyer wrote:
> Hi Ben/Dmitry-
> 
> On 12/01/16 08:10, Benjamin Tissoires wrote:
> > On Jan 11 2016 or thereabouts, Dmitry Torokhov wrote:
> >> On Thu, Dec 17, 2015 at 05:22:48PM +0000, Nick Dyer wrote:
> >>>> 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.
> >>>
> >>> 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.
> 
> That's very interesting, thanks. I do think there is a difference in intent
> between the debugfs interface we are proposing and the video interface.
> 
> 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.

Thanks.

-- 
Dmitry

[toc] | [prev] | [next] | [standalone]

#1308811

>> 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.

[snip]

> All that said, my hope is that there is room for both APIs so we can retain some
> simple console accessible debug API that works with typical shell commands,
> (cat, hexdump, sed, awk) to support simple testing, while the high performance
> userspace processing API gets what it needs too, which I would think should
> include some low-latency means of getting input events back into the kernel
> without needing uinput.

The notion of a simple high-speed input interface is surely attractive, but
perhaps the mismatch in scope says something important here.

For high-speed io, there are several subsystems that can be used as-is: video,
sound and iio for instance. The last one has matured through industrial beating,
and is now heavily used for bidirectional io (adding Jonathan).

But for the input subsystem, the versatile io device stands in juxtaposition to
the generic userland interface, which is the essence of the objection here.
Input devices and their capabilities should be easily enumerable and
recognizable. An ad-hoc debug interface is not.

So if we see an interest to incorporate high-speed io nodes in the world of
enumerable input devices, maybe it can be as easy as tucking some property and
control ioctls on top a device node driven by any or all of the mentioned
subsystems. It ought to be even simpler to use than debufs. You should certainly
be able to use it as you describe.

Henrik

[toc] | [prev] | [next] | [standalone]

#1308722

On Tue, Jan 12, 2016 at 09:10:41AM +0100, Benjamin Tissoires wrote:
> On Jan 11 2016 or thereabouts, Dmitry Torokhov wrote:
> > Hi Nick,
> > 
> > On Thu, Dec 17, 2015 at 05:22:48PM +0000, Nick Dyer wrote:
> > > On 02/12/15 20:42, Nick Dyer wrote:
> > > > 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.

I am not sure if it best to settle on using V4L2 API or creating smaller
API that behaves similarly to V4L2 API though. One of the main
differences is that we only need capture here.

Thanks.

-- 
Dmitry

[toc] | [prev] | [standalone]

Back to top | Article view | linux.kernel

csiph-web