On 04/03/2021 00:41, Wren Turkal wrote: > Questions below. > > On 3/3/21 2:41 PM, Nicolas Dufresne wrote: >> No, since m2m are instance base, you cannot have two process operating on the >> same node (there is only 1 streaming state). You'd probably want to look at >> extending the VIMC driver instead. It's a virtual media controller, it's missing >> few bits to make loopback possible, but would be a good fit. >> >> Note that vivid have a loopback capability, but it does not constraint the >> width/height/format and will produce a test pattern if you request something >> that differ from the source. > > I am not sure which you're suggesting to use: vivid or vimc. Also, are you > suggesting to extend them or use them as a template for a new module? I don't think either vimc nor vivid are particularly suitable for this, although vivid comes close. You can certainly lift ideas from vivid. > I think you are saying that vivid can already do loopback. However vivid is > a test driver and, like vim2m, doesn't ship with distribution kernels. Should I > try to move it out of the test-drivers? > >> It is very buggy, it often return a queued buffer back, and in fact, if you try >> to use the queue too much it fails. Though all this would probably be fine if >> you port it to VB2. > > I am assuming you are saying to port v4l2loopback to vb2. I am working on that > right now, but I am not sure how to proceed since the vb2 needs a queue for > capture and a queue for output (since they cannot be the same). I have created > the queues, but I am not sure how to further integrate. Please check out the > WIP here: > https://github.com/wt/v4l2loopback/commit/e71b0a50427729a5e6e74443066751f7321dc404 > > If the m2m is the wrong approach, do you have any suggestions for how to > proceed? You need two video devices, one capture, one output. I see that the current loopback driver has just one video device and advertises it as a M2M device, but that's not what it should do. Creating two video devices (similar to what vivid does) is the best and most compatible approach. > > Also, I am currently making a change for the linux kernel moving this code > info drivers/media/v4l2-core/v4l2-loopback.c so that I can start iterating > with your feedback. Is that a correct place to put this code? No, v4l2-core is for core V4L2 frameworks, not for drivers. For now stick it in drivers/media/test-drivers. It will likely be moved again at some point (if we keep the 'misc' device that the current driver creates, then it might end up in drivers/media/misc). By far the most important thing you need to do is convert it to vb2. Since the intention is to upstream the driver I would start by doing a cleanup of the code, ditching all compat code with older kernels, making sure it adheres to the linux coding style (use 'scripts/checkpatch.pl --strict' for that), then split it in two video devices and use vb2. I actually wonder if it shouldn't be renamed to viloopback since it will be different from v4l2loopback. Anyway, that's something that can be done later. Regards, Hans > > Thanks, > wt >
