On 07/28/2017 04:28 PM, Laurent Pinchart wrote:
> Hi Hans,
>
> On Friday 28 Jul 2017 16:04:48 Hans Verkuil wrote:
>> On 07/28/2017 03:25 PM, Laurent Pinchart wrote:
>>> On Friday 28 Jul 2017 13:05:27 Hans Verkuil wrote:
From: Hans Verkuil
I tried to get this in back in 2015, but th
Hi Hans,
On Friday 28 Jul 2017 16:04:48 Hans Verkuil wrote:
> On 07/28/2017 03:25 PM, Laurent Pinchart wrote:
> > On Friday 28 Jul 2017 13:05:27 Hans Verkuil wrote:
> >> From: Hans Verkuil
> >>
> >> I tried to get this in back in 2015, but that effort stalled.
> >>
> >> Trying again, since I re
On 07/28/2017 04:04 PM, Hans Verkuil wrote:
> On 07/28/2017 03:25 PM, Laurent Pinchart wrote:
>> To solve this, if you really want to identify the type of device node at
>> runtime, we should have a single ioctl supported by the two device nodes.
>> Given that we"re running out of capabilities bi
On 07/28/2017 03:25 PM, Laurent Pinchart wrote:
> Hi Hans,
>
> Thank you for the patches.
>
> On Friday 28 Jul 2017 13:05:27 Hans Verkuil wrote:
>> From: Hans Verkuil
>>
>> I tried to get this in back in 2015, but that effort stalled.
>>
>> Trying again, since I really need this in order to add
Hi Hans,
Thank you for the patches.
On Friday 28 Jul 2017 13:05:27 Hans Verkuil wrote:
> From: Hans Verkuil
>
> I tried to get this in back in 2015, but that effort stalled.
>
> Trying again, since I really need this in order to add proper v4l-subdev
> support to v4l2-ctl and v4l2-compliance.
From: Hans Verkuil
I tried to get this in back in 2015, but that effort stalled.
Trying again, since I really need this in order to add proper v4l-subdev
support to v4l2-ctl and v4l2-compliance. There currently is no way of
unique identifying that the device really is a v4l-subdev device other
t
