linux-kernel - Re: [PATCH 0/8] Input: atmel_mxt_ts - output raw touch diagnostic data via V4L

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] [thread-next>] [day] [month] [year] [list]

Date:	Fri, 22 Apr 2016 17:18:24 +0200
From:	Hans Verkuil <hverkuil@...all.nl>
To:	Nick Dyer <nick.dyer@...ev.co.uk>,
	Mauro Carvalho Chehab <mchehab@....samsung.com>
Cc:	Dmitry Torokhov <dmitry.torokhov@...il.com>,
	linux-input@...r.kernel.org, linux-kernel@...r.kernel.org,
	linux-media@...r.kernel.org,
	Benjamin Tissoires <benjamin.tissoires@...hat.com>,
	Benson Leung <bleung@...omium.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 0/8] Input: atmel_mxt_ts - output raw touch diagnostic
 data via V4L

On 04/22/2016 05:07 PM, Nick Dyer wrote:
> On 22/04/2016 15:45, Mauro Carvalho Chehab wrote:
>> Em Fri, 22 Apr 2016 10:26:37 +0200
>> Hans Verkuil <hverkuil@...all.nl> escreveu:
>>> On 04/21/2016 11:31 AM, Nick Dyer wrote:
>>>> This is a series of patches to add diagnostic data support to the Atmel
>>>> maXTouch driver. It's a rewrite of the previous implementation which output via
>>>> debugfs: it now uses a V4L2 device in a similar way to the sur40 driver.
>>>>
>>>> There are significant performance advantages to putting 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).
>>>>
>>>> We have a utility which can read the data and display it in a useful format:
>>>> 	https://github.com/ndyer/heatmap/commits/heatmap-v4l
>>>>
>>>> These patches are also available from
>>>> 	https://github.com/ndyer/linux/commits/diagnostic-v4l
>>>>
>>>> Any feedback appreciated.  
>>>
>>> FYI: we're working on a new buffer type for meta data:
>>>
>>> https://patchwork.linuxtv.org/patch/33938/
>>> https://patchwork.linuxtv.org/patch/33939/
>>
>> One of the things I missed on your patchset is the content of the
>> new format you added (V4L2_PIX_FMT_YS16). You should be patching
>> the V4L2 docbook too, in order to add it there.
> 
> OK, will do. I also see that I forgot Kconfig changes for CONFIG_VIDEO_V4L2
> etc.
> 
>> That's said, if the output is really an image, I don't think it
>> should be mapped via the new V4L2_BUF_TYPE_META_CAPTURE. This type of
>> buffer is meant to be used on non-image metadata, like image statistics
>> to feed auto whitebalance and other similar AAA algorithms.
> 
> The output is raw touch data - i.e. a rectangular grid of nodes each having
> an integer value. I think it is an image in some senses, although perhaps
> it's a matter of opinion!
> 
> You can see an example of a Atmel MXT capacitive touch device here (using
> this patchset):
> https://www.youtube.com/watch?v=Uj4T6fUCySw
> 
> There are touch devices which can deliver much higher resolution/framerate.
> For example here's the data coming from a SUR40 which is an optical touch
> sensor but uses V4L in a similar way:
> https://www.youtube.com/watch?v=e-JNqTY_3b0
> 
>> It could still make sense to use the new device type (VFL_TYPE_META) for
>> such drivers, as we don't want applications to identify those devices as
>> if they are a webcam.
> 
> I agree it may be a little confusing if things like Skype start picking up
> these devices. Could we #define V4L2_INPUT_TYPE_TOUCH_SENSOR to solve that
> problem?
> 

That might be an idea. I have to admit that I didn't look at the patches in
detail. It mentioned diagnostics, so I didn't realize that it is a image
with a width and height, even though it is not a regular video input.

Adding a new input type won't prevent anyone from picking it up, since
nobody tests that field :-)

On the other hand, it would be a good place to tell the user that it
is from a touch sensor.

Using the upcoming metadata feature wouldn't work since there is no width
and height in the metadata format.

I wonder what others think about adding a new type value.

Regards,

	Hans