Re: Dynamic video input/output list
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 -- 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
Dynamic video input/output list
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 -- 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
Re: Dynamic video input/output list
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 -- 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
Re: Dynamic video input/output list
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 -- 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
