Dynamic video input/output list

Dynamic video input/output list

[Aurélien Zanelli]

Hi everyone,

I'm looking to enhance video input/output enumeration support in
GStreamer using VIDIOC_ENUMINPUT/VIDIOC_ENUMOUTPUT ioctls and after some
discussions we wonder if the input/output list can change dynamically at
runtime or not.

So, is v4l2 allow this input/output list to be dynamic ?

Cheers
-- 
Aurélien Zanelli

Re: Dynamic video input/output list

[Devin Heitmueller]

> I'm looking to enhance video input/output enumeration support in
> GStreamer using VIDIOC_ENUMINPUT/VIDIOC_ENUMOUTPUT ioctls and after some
> discussions we wonder if the input/output list can change dynamically at
> runtime or not.
>
> So, is v4l2 allow this input/output list to be dynamic ?

I sure how the spec allows it, because I've done it in the past.  I
have cards which have an onboard header for external A/V inputs, and I
am able to tell if the breakout cable is attached due to a dedicated
pin tied to a GPIO.  Thus, I am able to dictate whether the card has
the A/V breakout cable attached and thus whether to expose only the
first input or all three inputs.

That said, in this case the inputs in the list never moved around
because the optional entries were at the end of the list - the list
just got longer if those inputs were available.  I'm not sure what
would happen if you had a configuration where you needed to remove
entries other than those at the end of the list.  For example, if you
had a card with four possible inputs and you removed input 2, does the
list stay the same length and input 2 is now marked as invalid, or
does the length of the list become 3 and inputs 3 and 4 turn into
inputs 2 and 3?

Devin

-- 
Devin J. Heitmueller - Kernel Labs
http://www.kernellabs.com

Re: Dynamic video input/output list

[Hans Verkuil]

On 03/16/2015 07:01 PM, Devin Heitmueller wrote:
>> I'm looking to enhance video input/output enumeration support in
>> GStreamer using VIDIOC_ENUMINPUT/VIDIOC_ENUMOUTPUT ioctls and after some
>> discussions we wonder if the input/output list can change dynamically at
>> runtime or not.
>>
>> So, is v4l2 allow this input/output list to be dynamic ?
> 
> I sure how the spec allows it, because I've done it in the past.

Just because you can do something doesn't mean the spec allows it :-)
In this particular case nobody ever thought about whether this could
change dynamically so the spec never talks about it.

But at the moment it is definitely not allowed, even though the spec
doesn't explicitly forbid it. All applications expect that the list of
inputs/outputs is fixed.

The spec could be extended to allow this, but then there also should be
a new event introduced that the application can receive if the list changes
so it can update the list.

But frankly, I would prefer to always expose all possible inputs, including
those of an optional onboard header, and if nothing is connected just mark
those inputs as having status V4L2_IN_ST_NO_POWER.

Note however that it is perfectly fine if the driver detects the presence
of such an onboard header when it is loaded and then only exposes those
extra inputs if the header is present. It just can't change the list later
unless do you an rmmod and modprobe of the driver. It's probably what you
do anyway.

Regards,

	Hans

> I have cards which have an onboard header for external A/V inputs, and I
> am able to tell if the breakout cable is attached due to a dedicated
> pin tied to a GPIO.  Thus, I am able to dictate whether the card has
> the A/V breakout cable attached and thus whether to expose only the
> first input or all three inputs.
> 
> That said, in this case the inputs in the list never moved around
> because the optional entries were at the end of the list - the list
> just got longer if those inputs were available.  I'm not sure what
> would happen if you had a configuration where you needed to remove
> entries other than those at the end of the list.  For example, if you
> had a card with four possible inputs and you removed input 2, does the
> list stay the same length and input 2 is now marked as invalid, or
> does the length of the list become 3 and inputs 3 and 4 turn into
> inputs 2 and 3?
> 
> Devin
> 

Re: Dynamic video input/output list

[Aurélien Zanelli]

On 16/03/2015 20:57, Hans Verkuil wrote:
> On 03/16/2015 07:01 PM, Devin Heitmueller wrote:
>>> I'm looking to enhance video input/output enumeration support in
>>> GStreamer using VIDIOC_ENUMINPUT/VIDIOC_ENUMOUTPUT ioctls and after some
>>> discussions we wonder if the input/output list can change dynamically at
>>> runtime or not.
>>>
>>> So, is v4l2 allow this input/output list to be dynamic ?
>>
>> I sure how the spec allows it, because I've done it in the past.
> 
> Just because you can do something doesn't mean the spec allows it :-)
> In this particular case nobody ever thought about whether this could
> change dynamically so the spec never talks about it.
> 
> But at the moment it is definitely not allowed, even though the spec
> doesn't explicitly forbid it. All applications expect that the list of
> inputs/outputs is fixed.
> 
> The spec could be extended to allow this, but then there also should be
> a new event introduced that the application can receive if the list changes
> so it can update the list.

Thanks for quick answers.
In light of these details, I think we will assume in GStreamer that the
list is fixed. Maybe it would be nice to explicitely forbid dynamic list
in the specification for now.

> 
> But frankly, I would prefer to always expose all possible inputs, including
> those of an optional onboard header, and if nothing is connected just mark
> those inputs as having status V4L2_IN_ST_NO_POWER.
Agreed.

Regards,
Aurélien Zanelli

> 
> Note however that it is perfectly fine if the driver detects the presence
> of such an onboard header when it is loaded and then only exposes those
> extra inputs if the header is present. It just can't change the list later
> unless do you an rmmod and modprobe of the driver. It's probably what you
> do anyway.
> 
> Regards,
> 
> 	Hans
> 
>> I have cards which have an onboard header for external A/V inputs, and I
>> am able to tell if the breakout cable is attached due to a dedicated
>> pin tied to a GPIO.  Thus, I am able to dictate whether the card has
>> the A/V breakout cable attached and thus whether to expose only the
>> first input or all three inputs.
>>
>> That said, in this case the inputs in the list never moved around
>> because the optional entries were at the end of the list - the list
>> just got longer if those inputs were available.  I'm not sure what
>> would happen if you had a configuration where you needed to remove
>> entries other than those at the end of the list.  For example, if you
>> had a card with four possible inputs and you removed input 2, does the
>> list stay the same length and input 2 is now marked as invalid, or
>> does the length of the list become 3 and inputs 3 and 4 turn into
>> inputs 2 and 3?
>>
>> Devin
>>
> 

Re: Dynamic video input/output list

[Devin Heitmueller]

> Note however that it is perfectly fine if the driver detects the presence
> of such an onboard header when it is loaded and then only exposes those
> extra inputs if the header is present. It just can't change the list later
> unless do you an rmmod and modprobe of the driver. It's probably what you
> do anyway.

Ah, good point.  In my case I was working with PCIe cards where I had
no expectation that the cable was plugged/unplugged at runtime.

Sorry for the noise.

Devin

-- 
Devin J. Heitmueller - Kernel Labs
http://www.kernellabs.com