Re: Dynamic video input/output list

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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
>>
> 
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html




[Index of Archives]     [Linux Input]     [Video for Linux]     [Gstreamer Embedded]     [Mplayer Users]     [Linux USB Devel]     [Linux Audio Users]     [Linux Kernel]     [Linux SCSI]     [Yosemite Backpacking]
  Powered by Linux