Enhancement: Revisit change resolution on-the fly, also solves producer disconnect.

[xxxajk]

• v4l2loopback version: github-master-pull
• kernel version: 5.11.x 5.8.x
• Distribution (+version): mint/ubuntu mixed

Step 3: Describe the problem:

Can't have a query return multiple supported resolutions set by producer, and be able to request a size change.

From brief Email discussion:

The producer could just query every so often using the IOCTL VIDEOC_G_FMT, when there is a change requested, it will be able to see the change, and do what it needs to do using VIDEOC_S_FMT.

On the consumer side -> request change -> we make a note to pass to the producer. VIDEOC_G_FMT will act like nothing has happened YET and will report back the OLD resolution.

So how do we know which FD is a producer? That's pretty easy, the producer can set this as a fact by using VIDEOC_S_EXT_CTRLS and set a special control there, which can even be named :-) Since we will know which FD made the request, the rest is pretty simple.

Question from reply:

so how would that work for any standard-compliant consumer?
i mean: there's actual data flowing between the producer and consumer,
and the format of the data has been pre-negotiated.
no consumer actually polls the format before receiving a new frame.

and what if the producer does not query every so often?

one of the two will access out-of-bounds memory.

i don't see how this could work in practice.

• On first start, use a sane default (which is 640x480, etc currently), We can use a special VIDEOC_[G|S]_EXT_CTRLS to check /populate/update a list of formats/resolutions/etc to give the query choices to the program making the request. These IOCTLs are restricted to the producer only, and won't show for the consumer, unless we add capability there. One nice thing that we can do is also have the ability to add extra controls on the fly, such as setting focal distance on a motorized focus camera, setting auto focus, and other settings. The producer can check what is there already to sync in the event it gets restarted. If a control isn't listed, the producer will know to populate the list with whatever defaults.
• A blank or placeholder frame for the requested resolution. This should also be done if there isn't a producer, instead of just a timeout. There's no option for a plain blank, only for an image currently, and it seems that it is required to fit the resolution. A blank screen option that takes an html color number would be ideal, or, just what many other capture cards do when there is no signal, the blue screen of dispair.
• As soon as the consumer makes a request, blank frames are sent as above, until producer sets the new values. All pending and incoming frames are disposed of/ignored, and prevents any out-of-bounds memory issues, etc.
• If producer thread monitoring for changes fails, the consumer will get the blank screen, if the producer is restarted, the producer uses the setting from VIDEOC_G_FMT instead of a preset in the producer. This keeps things in sync with the kernel and requests, and prevents any out-of-bounds issues.

How to tell old v.s. new producers.
Old producers won't be affected by the changes, since there's nothing new in order to stream. Simply lock everything if there's no request for the mode using VIDEOC_S_EXT_CTRLS. This will also allow an interesting trick where a consumer and producer can effectively swap roles. Currently producers only open in WO mode, consumers in RO mode. Allowing an RW mode would allow role swapping if it is found to be useful, but RW mode can be the difference to say we are a new-style producer. Might be a useful? Not sure.
New producers can check if they can use the new IOCTLs, and set modes. If this fails, it can revert back and spew a warning, or bail out.