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

Getting camera when using Google Meet is a great motivator:

$ git -P log --oneline master..
4443634cf761 (HEAD -> v4l2-loopback-dev, origin/v4l2-loopback-dev) media: v4l2-loopback: Open code "max_buffers"
2675a7f243a9 media: v4l2-loopback: Reorganize constants
c2b256ea51a0 media: Remove V4L2L_OVERLAY code path
2518279c3788 media: Remove !V4L2LOOPBACK_WITH_STD code path
0d8d5155c6ab media: Open code v4l2l_pix_format_has_valid_sizeimage()
c5e199b864fe media: v4l2-loopback: Replace dprintk() with pr_debug()
75cc3a15ccf0 media: v4l2-loopback: Remove the parameter "debug"
36ae93bcb2d7 media: v4l2-loopback: Remove v4l2l_mod64()
0cf1e2192918 media: v4l2-loopback: Remove sysfs shenanigans
520e4971b347 media: v4l2-loopback: Remove dprintkrw()
1670e49b1d28 media: v4l2-loopback: Remove MARK()
8c6389ba1e2b media: v4l2-loopback: Remove MODULE_VERSION()
1a50af7267ae media: v4l2-loopback: Remove SNAPSHOT_VERSION code path
3d21bcb22993 media: v4l2-loopback: Remove MODULE_AUTHOR()
986380446e78 media: v4l2-loopback: Remove LINUX_VERSION_CODE checks
2929a5908be8 media: v4l2-loopback: Remove !HAVE_TIMER_SETUP code path
c7a76fbfd8f3 media: v4l2-loopback: Remove !SPLIT_DEVICES code path
778aa6da1fd9 media: v4l2-loopback: Allocate the device number dynamically
8bc12e106311 media: v4l2-loopback: Do not any create devices in *init_module()
073bd4bf72f7 media: v4l2-loopback: Import the driver

By continuing this trend I'll have a driver in few weeks :-)

#linux #kernel #video4linux

I have a dev-tree: https://git.kernel.org/pub/scm/linux/kernel/git/jarkko/linux-tpmdd.git/log/?h=v4l2-loopback-dev

1. Suck inner guts out of the OOT driver.
2. Wrap it up tpm_vtpm_proxy

So generally looking for advice on:

1. #Pipewire interaction
2. #Gstreamer interaction

Focus on what instead of how. I.e. if this existed how would uapi play for those upstream projects?

#linux #kernel #video4linux #webcam