@oleksandr I'm making RFC patch set of in-kernel driver...

Factor out the core code from this and wrap it with better driver model.

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

@Conan_Kudo @wtay I aim to send RFC next month....

@Conan_Kudo @wtay https://github.com/umlaeute/v4l2loopback/issues/268#issuecomment-2495881766

@Conan_Kudo @wtay So the other problem is racy /dev/videoX instance. The problem is in that state changes of the video device are racy by definition. That is obviously unacceptable.

I.e. probably APi should be something along lines of:

1. fd = open("/dev/video_loop")
2. ioctl(fd, "set properties")
2. ioctl(fd, "create")

And post that anything that the device is written goes through that fd and is tied to its life-cycle. That is the only way to guarantee that it is tied to life-cycle of the device per se. Only when the fd is written nothing ever happens in the state of /dev/videoX.

For testing a tool is needed for "capture devices", which will create something for ffmepg to write to so that another ffmpeg instance can play it from /dev/videoX.

@Conan_Kudo @wtay

OK, so I think what goes wrong in high-level in the OOT driver and its uapi goes in core essence into: if you provide a service, you DO NOT use the client API to implement your service. Just basic API bullshit, overall, not like in kernel particular...

So instead when you open an fd then "you are /dev/videoX" or whatever. I.e. write ops go to the fd not any of /dev/videoX.

So... based on these it's a fuse alike driver for webcams. There really should maybe one /dev/video_loop device or whatever is a good name , and when you open that file, the creation of that file implies the creation of /dev/videoX.

After that the fd interface in user space gives all data and meta-data that you could expect similar devices.

So I think this is the gist of getting it wrong in uapi in that driver. But yeah like internals and thinking went on those can be quite easlily refactored out and wrapped in a nicer API package.

So yeah I'll do what I do put this in clean shape and send RFC patch set. So can CC obviously people to that once I get it out (few weeks smthng).

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

@timojyrinki @mmin @Jesse bitwig

small extra trouble which would widen embedded coverage so much more. just don't get it tbh. data center infrastructure mob is dominating the linux upstream i guess ;-)

@pavel @vbabka i've tried to give feedback in some reviews to make sure that test script would be busybox ash (i.e. #!/usr/bin/env sh) compatible but some others have downplayed that feedback ;-) at least i've tried...

especially with preproduction hardware it is not uncommon start with fpga so it would somewhat feasible to reduce image size for kernel + kselftest... because loading is SLOW

@Aissen yeah that is what I'm doing small iteration at a time :-) i've read my joel on software in the distant past https://www.joelonsoftware.com/2000/04/06/things-you-should-never-do-part-i/

non taken! and my rants neither should be taken too seriously. i'm basically and idiot trying to find idiomatic patterns :-)

@pavel @vbabka that's about what i run in my test images. actually i do have bash because kselftest requires it so that might be problem :-) it can't be worse performer than running RISC-V on FPGA, which I did for work purposes at some point...

@carnage4life so true.

This is like something out of medieval king’s court converted into a tweet.

@vbabka @pavel i need to check for fun what are the lowest specs for atari m68k. i possess STE with 4 megs and ultrasatan ;-) maybe i could create a config for it to my buildroot based shenanigans.

Well, I heard someone working in game industry that the figures I get with Rust when compiling and linking are in par with C++ projects :-) Like compiling Unreal Engine for instance.

Based on Unreal Engine figures 9950X(3D) should be a decent CPU so with "matching" parts on non-ECC memory (with ThreadRipper I'd actually go with ECC memory), we are talking about 4k investment so be it.

@litchipi Yeah, actually it is the linking that is nasty given the build artifacts that Rust makes but yeah you have a point :-) This was mostly just my stupid ranting that helps me to get over the work day stress, that's the weight of this nonsense really :-)

This goes to non-scientific speculation at best but I'd figure that over the time more innovation will be done for the linking phase as you could probably take advantage (in caching) of the heuristics of the linking phase (blobs build a huge static blob) perhaps... Perhaps even doing some of the compiler backend work specifically targeted to Rust.

Price: 7500 Finnish Marks. Funny how it is all over the place ;-)

It's in good condition considering 92 year old age of this paper.

This is literally my certificate of ownership for my downtown apartment in Tampere, Finland. I'd call this a proper stock :-) Especially love the tape fix in the middle.

Still I'm now looking into putting my place to digital register and hang this to my wall...