public inbox for linux-media@vger.kernel.org
 help / color / mirror / Atom feed
From: "Aurélien Zanelli" <aurelien.zanelli@parrot.com>
To: Hans Verkuil <hverkuil@xs4all.nl>,
	Devin Heitmueller <dheitmueller@kernellabs.com>
Cc: Linux Media Mailing List <linux-media@vger.kernel.org>
Subject: Re: Dynamic video input/output list
Date: Wed, 18 Mar 2015 17:55:40 +0100	[thread overview]
Message-ID: <5509AE0C.6040009@parrot.com> (raw)
In-Reply-To: <55073598.9010803@xs4all.nl>

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
>>
> 

  reply	other threads:[~2015-03-18 16:55 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-03-16 17:48 Dynamic video input/output list Aurélien Zanelli
2015-03-16 18:01 ` Devin Heitmueller
2015-03-16 19:57   ` Hans Verkuil
2015-03-18 16:55     ` Aurélien Zanelli [this message]
2015-03-18 16:59     ` Devin Heitmueller

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=5509AE0C.6040009@parrot.com \
    --to=aurelien.zanelli@parrot.com \
    --cc=dheitmueller@kernellabs.com \
    --cc=hverkuil@xs4all.nl \
    --cc=linux-media@vger.kernel.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox