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 majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
