One more existential reason for v4l2-loopback: testing video4linux features other than v4l2-loopback.

It is always nice to have a module in the stack that can pretend to be a piece of hardware in various end-to-end tests.

Just writing these down so that I can make a credible cover letter at the time :-)

I did this one big refactor few days ago: https://git.kernel.org/pub/scm/linux/kernel/git/jarkko/linux-tpmdd.git/commit/?h=v4l2-loopback&id=ccb1b6e1247887be17bf22b3809c50848e87a4db

I'm still editing it up until I'm happy with capture/output separation and some other things related (e.g. life-cycle and removal).

Obviously once I sent a patch set I will squash everything before sending...

#video4linux #linux #kernel #media

Multiple capture/output devices issue in the OOT driver and v4l2-loopback. It has the unfinished "SPLIT_DEVICES" compilation options, which I DO NOT fully cope with. I don't get what the heck they are aiming for TBH.

A video device can be either something like camera or something that takes input from client and displays that, e.g. similar device to ChromeCast would be a good example in this context.

I'm aligning to a solution where the initial "ADD" ioctl has:

1. flags (for setting the RW properties)
2. video_nr
3. video_fd (for server to read OR write)

And the direction is determined by flags. I did not fully understand why OOT driver aimed to do both capture and output device simultaneously, which does bother me a bit since it would be best to know the original reasoning, even if the conclusions were wrong.

Moving slowly in this area still and experimenting with options.

#linux #kernel #media #video4linux

After trying bunch of things over the last few weeks I finally have a test program for feeding the data for a video loopback device, i.e. to work as fake webcam:

- Has zero dependencies other than libc. Draws the frames, converts the pixel formats and writes them to the device.
-.Has optional debug display using minifb.
- Predictable cyclic motion, which useful in future for automated testing.

Repository: https://codeberg.org/jarkko/v4l2-loopback-test/
BuildRoot package: https://codeberg.org/jarkko/linux-tpmdd-test/src/branch/main/package/v4l2-loopback-test

I've not been able to make any major changes to the driver I would like to do because it does not make much when being blind. Now it is finally possible to forget user space and move on to the kernel changes.

#linux #kernel #media #video4linux

Great found the most suitable crate for my test program:

https://github.com/zesterer/euc

I.e. I can pre-render the frame to buffers and then loop those frames to "cast_fd" with a given FPS (25) so it should be fairly timing accurate.

Using rotating and shaded torus I have cyclic movement which the other side (opening /dev/video0) can then read and store a full cycle of the animation.

Client and server can be two threads in the same process, and as final step the client can compare that the read frames are close proximity enough to the pre-rendered frames.

That should create a full headless and "CI friendly" system test for v4l2-cast. Definitely still hold a bit before doing too heavy refactoring and make this happen!

I wonder can we already have Rust programs in kselftest's? My driver is in C but this could be potentially part of the kselftest (at some point).

#linux #kernel #video4linux

Next making a fake webccam program with Rust to have something to run as the server end with the in-kernel driver using anonymous inode for proxy.

Realized that I need this before doing API split (i.e. break).

I'll implement it with Bevy and it will stream a rotating torus (that weird thing in the middle ATM) to the video loopback proxy

#linux #kernel #video4linux

Great, ffmpeg now setup properly to BuildRoot and video streaming through my in-progress loopback driver. Not having QA environment has kept this one stuck for few weeks.

#linux #kernel #video4linux #loopback #driver

Not forgotten and not discontinued:

https://github.com/umlaeute/v4l2loopback/issues/268#issuecomment-2541605102

Just a slow process and busy at work before holidays ;-)

This is pretty typical for OOT drivers really. Bad architecture choices kind of accumulate because no one dares to make any actual changes to what is already there.

Probably would happen to me too if I was doing OOT so not blaming anyone, just saying how it is ;-)

#linux #kernel #video4linux

Takes some time to get a test for my "FUSE camera driver" right (it's like in ~65% done til RFC) but one additional application that came to mind for it would be provide camera access for Wine ("winecamera"). So that you could use Windows applications, which require camera access.

#linux #video4linux #wine #windows

Video streamed with ffmpeg, and played with ffplay through with my WiP V4L2 loopback driver.

The next step is to detach the producer from /dev/videoX fops and instead return anonymous inode, which owns a file where the capture device can write the video stream.

The video resolution in this smoke test is 640x480, and the encoder scales it up in real-time to 1280x720.

#linux #kernel #media #video4linux

Writing down this for myself for the most part to get idea what to write to the cover letter later on.

My RFC driver model for v4l2-loopback will be centered around /dev/video_loop. It has only single ioctl (OOT driver has three), which has N input parameters (describing metadata for the video device) and exactly two output parameters:

1. capture_fd: communications end point for the virtual capture device. Created using anonymous inode.
2. output_nr: /dev/video{output_nr} is the V4L2 device for the output.

There is no query ioctl because any sane program should at minimum know what resources it creates and should not have privilege in the first place to peak others resources.

There is no remove ioctl because close(capture_fd) destroys /dev/video{output_nr}

Neither overlay nor dma-buf support in the initial version (should be reviewed from basis that these can be extended later on).

#linux #kernel #video4linux #v4l2loopback