Jarkko Sakkinen
jarkko
1
0
2
Jarkko Sakkinen
jarkko
For the v2 I think I have sane way to constrain the state i.e., in VCAM_IOC_CREATE:
__u32 nr_states;
__u32 states;
Each state (32 bytes per state) specifies configuration with pixel format, geometry, stride etc.
Obviously this means some redundancy perhaps because one has to address e.g. same width and height in different configurations but I think in the end this database approach is the most robust pick.
__u32 nr_states;
__u32 states;
Each state (32 bytes per state) specifies configuration with pixel format, geometry, stride etc.
Obviously this means some redundancy perhaps because one has to address e.g. same width and height in different configurations but I think in the end this database approach is the most robust pick.
1
0
0
Jarkko Sakkinen
jarkko
Edited 4 months ago
Test code I have cleaned up relocated:
https://git.kernel.org/pub/scm/linux/kernel/git/jarkko/vcam-test.git
From this i spin off at least some kind of initial kselftest.
https://git.kernel.org/pub/scm/linux/kernel/git/jarkko/vcam-test.git
From this i spin off at least some kind of initial kselftest.
1
0
0
Jarkko Sakkinen
jarkko
Edited 4 months ago
Despite the feedback does not look very accepting, continuing with vcam makes common sense to me enough that I continue improving and rebasing it.
In order to lift it up from RFC phase at least property negotiation needs some rework, there's some compliance suites for V4L2 to try out and of course some test code needs to be supplemented.
Up side with resistance is at least that it is antidote for a loose send-finger :-) I'll focus on making each iteration considerably better than N - 1.
In order to lift it up from RFC phase at least property negotiation needs some rework, there's some compliance suites for V4L2 to try out and of course some test code needs to be supplemented.
Up side with resistance is at least that it is antidote for a loose send-finger :-) I'll focus on making each iteration considerably better than N - 1.
1
0
0
Jarkko Sakkinen
jarkko
v4l2loopback has highly scattered but at the same time wide base. It even includes stuff like scientific research. Here's one recent'ish example: https://dl.acm.org/doi/epdf/10.1145/3664647.3681007. This also implies that it is a tainted driver likely deployed to multiple critical organizations and environments.
This type of feature is also quite robust tool for many uses where emulation is required but we still need sufficient figures for latency and throughput. It could be applied e.g., to drone platform testing where vision can be mocked with virtual devices providing simulated environment or pre-recorded environment (for training AI).
It is also good to keep in mind not every single piece of legacy software can be magically turned into PipeWire clients, and neither it is a great fit all possible deployments of Linux.
This type of feature is also quite robust tool for many uses where emulation is required but we still need sufficient figures for latency and throughput. It could be applied e.g., to drone platform testing where vision can be mocked with virtual devices providing simulated environment or pre-recorded environment (for training AI).
It is also good to keep in mind not every single piece of legacy software can be magically turned into PipeWire clients, and neither it is a great fit all possible deployments of Linux.
0
0
1
Jarkko Sakkinen
jarkko
OK, there's 6.19-rc8. Has not happened for a while, or at least don't recall
0
0
0
Jarkko Sakkinen
jarkko
IMHO vcam is a bit like ntsync. In other words, it is somewhat use case optimized but the use case is just relevant enough to make it sense to have the feature in the mainline kernel.
0
0
0
Jarkko Sakkinen
jarkko
I didn't really know all the time what I was doing but I at least the choice of tying the pole providing the service tightly to dma-buf was a right design choice :-) This has been somewhat experimental project.
0
0
0
@suihkulokki It is a security fix :-) v4l2-loopback is in top tier of most used OOT drivers and OOT drivers are a security risk.
0
0
1
Jarkko Sakkinen
jarkko
Edited 4 months ago
early RFC: https://lore.kernel.org/linux-media/20260201133342.335680-1-jarkko@kernel.org/T/#u
I'm happy with approach to mm where caller allocates all the resources, which is great for accounting from the correct victim. For any driver that is actually often a non-trivial problem. Other stuff, I'll hold for feedback...
I'm happy with approach to mm where caller allocates all the resources, which is great for accounting from the correct victim. For any driver that is actually often a non-trivial problem. Other stuff, I'll hold for feedback...
0
4
6
Jarkko Sakkinen
jarkko
Edited 4 months ago
any Rust crates for streaming AirPlay?
would be nice at least in some level test the main use case for vcam before sending any patches :-) murphy's law is strong in this...
would be nice at least in some level test the main use case for vcam before sending any patches :-) murphy's law is strong in this...
0
0
0
Jarkko Sakkinen
jarkko
Now vcam is internally running in dma-buf based architecture only:
https://git.kernel.org/pub/scm/linux/kernel/git/jarkko/linux-tpmdd.git/tree/drivers/media/vcam.c?h=vcam
The key function is vcam_dequeue_frames, which pairs queued output and capture frames. When they match the same dma-buf it won't copy anything. So it works like zipper (or that's how I imagine it in my head) :-)
I think it is quite sane and elegant pipeline.
https://git.kernel.org/pub/scm/linux/kernel/git/jarkko/linux-tpmdd.git/tree/drivers/media/vcam.c?h=vcam
The key function is vcam_dequeue_frames, which pairs queued output and capture frames. When they match the same dma-buf it won't copy anything. So it works like zipper (or that's how I imagine it in my head) :-)
I think it is quite sane and elegant pipeline.
0
0
2
Jarkko Sakkinen
jarkko
One last thing inherited from v4l2-loopback is kcalloc(), which I dislike given that it is unaccounted memory for a process.
The solution is to make "server side" using vcam ioctl API exclusive dma-buf based because they provide all the robustness. Depending on allocator they can be memcg accounted and they can be also sent between processes.
I.e. I had some harmful robustness that is really unnecessary given that user space camera driver is specialized software to begin with.
It does not affect /dev/videoX, which runs on different VB2 queue supporting userptr, mmap and dma-buf.
The solution is to make "server side" using vcam ioctl API exclusive dma-buf based because they provide all the robustness. Depending on allocator they can be memcg accounted and they can be also sent between processes.
I.e. I had some harmful robustness that is really unnecessary given that user space camera driver is specialized software to begin with.
It does not affect /dev/videoX, which runs on different VB2 queue supporting userptr, mmap and dma-buf.
0
0
1