Created attachment 315437 [details] [review]
v4l2: Track /dev/video* to triggered required probe

If something in /dev/video* get added, removed or replaced, we need to
probe the devices again in order to ensure the dynamic devices are up to
date.

Review of attachment 315437 [details] [review]:

In ther patch title s/triggered/trigger/

::: sys/v4l2/gstv4l2.c
@@ +197,3 @@
 plugin_init (GstPlugin * plugin)
 {
+  const gchar *paths[] = { "/dev", "/dev/v4l2", NULL };

It's /dev/v4l .. and there is no prefix in that case.

I would like to understand the impact of this patch on 'normal operations' better first.

Does it mean the v4l plugin is typically reloaded after every reboot, even if nothing changed?

Does it mean the v4l plugin is reloaded every time a usb camera gets plugged or unplugged and a gst app is started?

(In reply to Olivier Crête from comment #2)
> Review of attachment 315437 [details] [review] [review]:
> 
> In ther patch title s/triggered/trigger/
> 
> ::: sys/v4l2/gstv4l2.c
> @@ +197,3 @@
>  plugin_init (GstPlugin * plugin)
>  {
> +  const gchar *paths[] = { "/dev", "/dev/v4l2", NULL };
> 
> It's /dev/v4l .. and there is no prefix in that case.

/dev/v4l is something else. It contains sub-folder by-id and by-patch, it's rather new. While /dev/v4l2 is ancient, is from when there was both v4l and v4l2 device (2.4 kernel). This is just to be consistent with the monitor (which is code from the probes).

(In reply to Tim-Philipp Müller from comment #3)
> I would like to understand the impact of this patch on 'normal operations'
> better first.
> 
> Does it mean the v4l plugin is typically reloaded after every reboot, even
> if nothing changed?

With non-static /dev it will. It's a minor hassle compare to the underlying bugs. I can make this opt-in instead, if you don't agree. This feature need to go in, with compile option or not.

> 
> Does it mean the v4l plugin is reloaded every time a usb camera gets plugged
> or unplugged and a gst app is started?

It's not a daemon, so it will be updated after you have plugged/unplugged. There is no other mean with GStreamer to be smarter, and it's not worth writing infrastructure for this in my opinion. The probes are a very limited sub-set of the actual probes that get run when you switch to READY.

Created attachment 315928 [details] [review]
v4l2: Track /dev/video* to triggered required probe

If something in /dev/video* get added, removed or replaced, we need to
probe the devices again in order to ensure the dynamic devices are up to
date.

This is an update, this time you need --enable-v4l2-probe to actually get that in-place. I also disable dynamic element probing by default. I think this is ideal until all the world have move to V4L2 m2m for CODEC ;-P It can also be handy on embedded system where probing takes time accompanied with the configurable version of the decoder/converter.

So is this a "developer feature" then basically, for people hacking/trying drivers? If yes, I'd hide it behind an environment variable instead.

I would like to avoid unnecessary rescans of the plugin on non-embedded systems.

(In reply to Tim-Philipp Müller from comment #8)
> So is this a "developer feature" then basically, for people hacking/trying
> drivers? If yes, I'd hide it behind an environment variable instead.

Not sure what makes you think that. There is no other way to use a M2M VL42 decoder (and there will never be) within playbin without that feature being enabled. You seems to expose a concern of having this probing code to run from time to time on platforms where there is no such decoder or converter.

> 
> I would like to avoid unnecessary rescans of the plugin on non-embedded
> systems.

At boot, it is necessary. We cannot know between two boots if the topology of the system will be the same or not. For that same reason, pulseaudio will probe the alsa devices every boot.

I think I have confused you with stating that this could be disable on certain embedded platform. In fact, I should have said on certain embedded use case, where static pipelines are to be used.

Another important point to remember, the device numbers are not guaranteed by the linux kernel. Also, distribution might at some point enable such feature in their kernel, hence we need a scan to see the devices. And further update to the kernel could change the device order, resulting in bad cached value.

Attachment 315928 [details] pushed as 3cdc700 - v4l2: Track /dev/video* to triggered required probe