Conversation
Jarkko Sakkinen
jarkko
Edited 7 days ago
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
- 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
1
2
3
I feel like wasting time a lot for nothing (psychologically) but at the same I think here lies the main reason why this driver has not moved really :-)
In order to modify the driver you would have to change the stack around it, which is destined not to be compatible what the upstream expects. There's no tools outside v4l2-loopback stack that you could really use for testing the camera side, when you start breaking the API.
So in order to start doing even basic changes to the driver (other than make it compile as in-tree driver), something that resembles enough stack is a mandatory requirement. Thus, this silly demo is sort of like v4l2-loopback tools emulator...
In order to modify the driver you would have to change the stack around it, which is destined not to be compatible what the upstream expects. There's no tools outside v4l2-loopback stack that you could really use for testing the camera side, when you start breaking the API.
So in order to start doing even basic changes to the driver (other than make it compile as in-tree driver), something that resembles enough stack is a mandatory requirement. Thus, this silly demo is sort of like v4l2-loopback tools emulator...
1
0
1
C library and Rust crate recommendation of the day:
1. C: https://github.com/emoon/minifb
2. Rust: https://github.com/emoon/rust_minifb
This is pure gold!
A simple no bullshit framebuffer that dumps to X11/Wayland/macOS/iOS/Android/Web(WASM).
1. C: https://github.com/emoon/minifb
2. Rust: https://github.com/emoon/rust_minifb
This is pure gold!
A simple no bullshit framebuffer that dumps to X11/Wayland/macOS/iOS/Android/Web(WASM).
0
1
3