All of lore.kernel.org
 help / color / mirror / Atom feed
From: Nick Dyer <nick.dyer@itdev.co.uk>
To: Florian Echtler <floe@butterbrot.org>
Cc: Hans Verkuil <hverkuil@xs4all.nl>,
	Dmitry Torokhov <dmitry.torokhov@gmail.com>,
	linux-input@vger.kernel.org, linux-kernel@vger.kernel.org,
	linux-media@vger.kernel.org,
	Benjamin Tissoires <benjamin.tissoires@redhat.com>,
	Benson Leung <bleung@chromium.org>,
	Alan Bowens <Alan.Bowens@atmel.com>,
	Javier Martinez Canillas <javier@osg.samsung.com>,
	Chris Healy <cphealy@gmail.com>,
	Henrik Rydberg <rydberg@bitmath.org>,
	Andrew Duggan <aduggan@synaptics.com>,
	James Chen <james.chen@emc.com.tw>, Dudley Du <dudl@cypress.com>,
	Andrew de los Reyes <adlr@chromium.org>,
	sheckylin@chromium.org, Peter Hutterer <peter.hutterer@who-t.net>,
	mchehab@osg.samsung.com
Subject: Re: [PATCH v4 2/9] [media] v4l2-core: Add VFL_TYPE_TOUCH_SENSOR
Date: Wed, 22 Jun 2016 22:22:03 +0100	[thread overview]
Message-ID: <4acb15eb-7e05-5cfa-5524-afd8ee546a53@itdev.co.uk> (raw)
In-Reply-To: <alpine.DEB.2.10.1606222234190.2895@butterbrot>

On 22/06/2016 21:38, Florian Echtler wrote:
> On Wed, 22 Jun 2016, Nick Dyer wrote:
> 
>> On 22/06/2016 12:48, Florian Echtler wrote:
>>> On 20.06.2016 14:00, Hans Verkuil wrote:
>>>> On 06/17/2016 04:16 PM, Nick Dyer wrote:
>>>>>
>>>>> Use a new device prefix v4l-touch for these devices, to stop generic
>>>>> capture software from treating them as webcams.
>>
>>> Come to think of it, wouldn't it make sense to expose the other touch
>>> devices as generic frame grabbers, too, so you can easily view the debug
>>> output with any generic tool like cheese?
>>
>> While I like the idea of being able to use the generic tools, I think we
>> needed to do something to stop these devices turning up in e.g. video
>> conferencing software - it would cause a lot of confusion. There's nothing
>> stopping particular tools adding the necessary code to handle touch devices
>> if they feel their users want it.
> 
> Just to clarify: from the userspace point-of-view, would this change simply
> modify the prefix of the device node (i.e. /dev/video1 -> /dev/v4l-touch1),
> or would it somehow affect the API? If it's just the device node name, then
> that shouldn't be a problem after all, because e.g. reacTIVision requires
> you to specify the exact camera to be used anyway.

With the changes that Hans Verkuil has asked me to do:
* The device node is /dev/v4l-touch0-255
* There are several new formats eg. V4L2_TCH_FMT_DELTA_TD16 (16 bit deltas)
* I've defined new types VFL_TYPE_TOUCH, V4L2_BUF_TYPE_TOUCH_CAPTURE,
V4L2_INPUT_TYPE_TOUCH

We're just testing the changes, I hope to post an updated version soon.

  reply	other threads:[~2016-06-22 21:22 UTC|newest]

Thread overview: 22+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-06-17 14:16 [PATCH v4 0/9] Output raw touch data via V4L2 Nick Dyer
2016-06-17 14:16 ` [PATCH v4 1/9] [media] Add signed 16-bit pixel format Nick Dyer
2016-06-20 11:00   ` Hans Verkuil
2016-06-20 11:51     ` Nick Dyer
2016-06-17 14:16 ` [PATCH v4 2/9] [media] v4l2-core: Add VFL_TYPE_TOUCH_SENSOR Nick Dyer
2016-06-20 12:00   ` Hans Verkuil
2016-06-22 11:48     ` Florian Echtler
2016-06-22 11:59       ` Nick Dyer
2016-06-22 20:38         ` Florian Echtler
2016-06-22 21:22           ` Nick Dyer [this message]
2016-06-17 14:16 ` [PATCH v4 3/9] Input: atmel_mxt_ts - add support for T37 diagnostic data Nick Dyer
2016-06-17 14:16 ` [PATCH v4 4/9] Input: atmel_mxt_ts - output diagnostic debug via v4l2 device Nick Dyer
2016-06-17 14:16 ` [PATCH v4 5/9] Input: atmel_mxt_ts - read touchscreen size Nick Dyer
2016-06-17 14:16 ` [PATCH v4 6/9] Input: atmel_mxt_ts - handle diagnostic data orientation Nick Dyer
2016-06-17 14:16 ` [PATCH v4 7/9] Input: atmel_mxt_ts - add diagnostic data support for mXT1386 Nick Dyer
2016-06-17 14:16 ` [PATCH v4 8/9] Input: atmel_mxt_ts - add support for reference data Nick Dyer
2016-06-20 16:09   ` Hans Verkuil
2016-06-20 16:18     ` Nick Dyer
2016-06-20 16:22       ` Hans Verkuil
2016-06-17 14:16 ` [PATCH v4 9/9] Input: synaptics-rmi4 - add support for F54 diagnostics Nick Dyer
2016-06-20 16:20   ` Hans Verkuil
2016-06-21 22:16     ` Nick Dyer

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=4acb15eb-7e05-5cfa-5524-afd8ee546a53@itdev.co.uk \
    --to=nick.dyer@itdev.co.uk \
    --cc=Alan.Bowens@atmel.com \
    --cc=adlr@chromium.org \
    --cc=aduggan@synaptics.com \
    --cc=benjamin.tissoires@redhat.com \
    --cc=bleung@chromium.org \
    --cc=cphealy@gmail.com \
    --cc=dmitry.torokhov@gmail.com \
    --cc=dudl@cypress.com \
    --cc=floe@butterbrot.org \
    --cc=hverkuil@xs4all.nl \
    --cc=james.chen@emc.com.tw \
    --cc=javier@osg.samsung.com \
    --cc=linux-input@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-media@vger.kernel.org \
    --cc=mchehab@osg.samsung.com \
    --cc=peter.hutterer@who-t.net \
    --cc=rydberg@bitmath.org \
    --cc=sheckylin@chromium.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body. 
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.