Jarkko Sakkinen
Posts
5159Following
335Followers
510OpenPGP: 3AB05486C7752FE1
Jarkko Sakkinen
jarkko
Edited 5 hours 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
Jarkko Sakkinen
jarkko
Edited yesterday
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...
1
4
6
Jarkko Sakkinen
jarkko
Edited yesterday
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
Jarkko Sakkinen
jarkko
Edited 2 days ago
I think vcam driver is almost ready for RFC submission. It is a dual-VB2 queue architecture and intermediator that moves frames between the queues. Flow can be either based on copying or shared DMA-BUF's and memory allocation can be either vmalloc or dma-sg based.
Right now VCAM_IOC_CREATE locks in "physical characteristics" of the device. It might be nice to be able to change them without re-creating the device but this is *purposely* left out as nothing prevents extending uAPI that way later on.
SLOC is now varying between 2-2.5 KSLOC, which "feels" about right for me considering complexity of the flow etc.
I'll hold for a week so that I discover low-hanging stupid stuff and send it late next week.
Right now VCAM_IOC_CREATE locks in "physical characteristics" of the device. It might be nice to be able to change them without re-creating the device but this is *purposely* left out as nothing prevents extending uAPI that way later on.
SLOC is now varying between 2-2.5 KSLOC, which "feels" about right for me considering complexity of the flow etc.
I'll hold for a week so that I discover low-hanging stupid stuff and send it late next week.
2
1
0
Jarkko Sakkinen
jarkko
Starting documenting vcam driver for RFC patch set.
I probably don't convert my test yet to kselftest. For the time being, seeing is believing so I'll just link the test program Git URL to the cover letter. Probably based on feedback I'll also have better information what would be the most appropriate kselftest.
I probably don't convert my test yet to kselftest. For the time being, seeing is believing so I'll just link the test program Git URL to the cover letter. Probably based on feedback I'll also have better information what would be the most appropriate kselftest.
1
0
0
Jarkko Sakkinen
jarkko
Edited 3 days ago
For a parentless video device, is it too unorthodox embed dma_mask, dma_parms to your private context struct?
I just put vdev->dev.dma_* to point to those fields.
It seems to work at run-time for vb2_dma_sg_memops.
I don't know really what I'm doing TBH but after trying out different things this seems to work.
I'm just a dude who wants stream Zoom calls with a phone camera - definitely not a V4L2 expert ;-)
I just put vdev->dev.dma_* to point to those fields.
It seems to work at run-time for vb2_dma_sg_memops.
I don't know really what I'm doing TBH but after trying out different things this seems to work.
I'm just a dude who wants stream Zoom calls with a phone camera - definitely not a V4L2 expert ;-)
0
1
1
Jarkko Sakkinen
jarkko
Right, I obviously need separate "IDLE" and "STREAMING" bits in status word despite always being mutually exclusive. Otherwise it is impossible to define meaningful "wait for bits turned on" op :-)
0
0
1
Jarkko Sakkinen
jarkko
Lot's of stuff I'm doing with vcam driver are really a versions of ideas re-used that I did for SGX driver :-) Everything is a memory manager of some sort in the end of the day... That driver was really a grand tutorial of Linux device model for me and still helps me to navigate through it today.
0
0
2
Jarkko Sakkinen
jarkko
Yet another iteration in ioctl API. Since VIDIOC bindings were dropped from outside completely some complexity of them existing is just unrolling.
Now it is five calls total:
1. VCAM_IOC_CREATE
2. VCAM_IOC_QUEUE
3. VCAM_IOC_DEQUEUE
4. VCAM_IOC_STATUS
5. VCAM_IOC_WAIT
The last two will replace and remove control_fd previously returned by VCAM_IOC_CREATE. It existed because output was using a subset of VIDIOCs previously.
Now it is five calls total:
1. VCAM_IOC_CREATE
2. VCAM_IOC_QUEUE
3. VCAM_IOC_DEQUEUE
4. VCAM_IOC_STATUS
5. VCAM_IOC_WAIT
The last two will replace and remove control_fd previously returned by VCAM_IOC_CREATE. It existed because output was using a subset of VIDIOCs previously.
0
0
0
Jarkko Sakkinen
jarkko
Now that the uapi in vcam is improving by factors daily that will rather make me postpone sending RFC by a week or two than send it too soon.
When this trend stagnates a bit I'll send the RFC :-)
When this trend stagnates a bit I'll send the RFC :-)
1
0
0
Jarkko Sakkinen
jarkko
Edited 4 days ago
OK with some tweaking vcam ioctls reduced down to three ioctl play:
1. VCAM_IOC_CREATE
2. VCAM_IOC_QUEUE
3. VCAM_IOC_DEQUEUE
Most of stuff went to create ioctl, there's now sysfs attributes for limits and available formats, and frames are anyhow freed when fd is closed.
1. VCAM_IOC_CREATE
2. VCAM_IOC_QUEUE
3. VCAM_IOC_DEQUEUE
Most of stuff went to create ioctl, there's now sysfs attributes for limits and available formats, and frames are anyhow freed when fd is closed.
0
0
1
Jarkko Sakkinen
jarkko
Edited 4 days ago
Flattened ioctls:
VCAM_IOC_CREATE
VCAM_IOC_QUERY
VCAM_IOC_SET_FORMAT
VCAM_IOC_ALLOC_FRAMES
VCAM_IOC_IMPORT_DMABUF
VCAM_IOC_QUEUE
VCAM_IOC_DEQUEUE
VCAM_IOC_FREE_FRAMES
The interface is available from fd opened by /dev/vcam, thus making it the life-line of /dev/videoX. The result struct of VCAM_IOC_CREATE provides "control fd", which ATM provides status flag for stream on/off state.
VCAM_IOC_CREATE is one-shot:
1. Before the ioctl is called, other ioctls result -ENOTTY.
2. After successful invocation, the other ioctls become available, and VCAM_IOC_CREATE will result -ENOTTY up until the end.
In other words, no broken use of VIDIOC API and /dev/videoX for outputing frames. Instead, vcam provides a dedicated and consolidated API to perform its task within the constraints what makes sense for virtual webcams and such.
Probably getting ioctls acceptable for reviewers will take a few rounds but I still think that this is the right design choice to get something that we can eventually ship in the mainline kernel.
VCAM_IOC_CREATE
VCAM_IOC_QUERY
VCAM_IOC_SET_FORMAT
VCAM_IOC_ALLOC_FRAMES
VCAM_IOC_IMPORT_DMABUF
VCAM_IOC_QUEUE
VCAM_IOC_DEQUEUE
VCAM_IOC_FREE_FRAMES
The interface is available from fd opened by /dev/vcam, thus making it the life-line of /dev/videoX. The result struct of VCAM_IOC_CREATE provides "control fd", which ATM provides status flag for stream on/off state.
VCAM_IOC_CREATE is one-shot:
1. Before the ioctl is called, other ioctls result -ENOTTY.
2. After successful invocation, the other ioctls become available, and VCAM_IOC_CREATE will result -ENOTTY up until the end.
In other words, no broken use of VIDIOC API and /dev/videoX for outputing frames. Instead, vcam provides a dedicated and consolidated API to perform its task within the constraints what makes sense for virtual webcams and such.
Probably getting ioctls acceptable for reviewers will take a few rounds but I still think that this is the right design choice to get something that we can eventually ship in the mainline kernel.
1
0
1
Jarkko Sakkinen
jarkko
Edited 4 days ago
Here vcam-test outputs to /dev/vcam and in sequence streams /dev/video0 and renders the output to KMS/DRM initialized frame buffer.
I need to flatten the ioctl interface of /dev/vcam a bit but otherwise this is looking pretty reasonable...
I need to flatten the ioctl interface of /dev/vcam a bit but otherwise this is looking pretty reasonable...
0
0
1
Jarkko Sakkinen
jarkko
As per kselftest for vcam, it will by default do frame comparison without displaying anything but will contain also debug mode, which uses KMS/DRM directly to show the results. It's run mostly run in a VM without window manager anyhow.
0
0
0