Conversation
Jarkko Sakkinen
jarkko
Edited 6 days ago
Let me present v4l2-vcam:
https://git.kernel.org/pub/scm/linux/kernel/git/jarkko/linux-tpmdd.git/log/?h=vcam
Vcam user driver is created by opening /dev/vcam and then issuing V4L2_VCAM_IOC_NEW. This will emit /dev/videoX for readers. Reader semantics enforces single reader limitation.
In addition:
1. Supports zero-copy operation for a shared capture and output buffer (enabled automatically when possible).
2. Uses DMA contig allocator automatically when possible (falls back to vmalloc).
3. VB2 framework used for the pipeline.
These all are BTW unresolved in the OOT driver, and should help with getting better picture and frame rates over what we can do outside of kernel.
The code will code about 777 rounds of cleanups and tweaks and then I'll send the RFC patch ;-)
https://git.kernel.org/pub/scm/linux/kernel/git/jarkko/linux-tpmdd.git/log/?h=vcam
Vcam user driver is created by opening /dev/vcam and then issuing V4L2_VCAM_IOC_NEW. This will emit /dev/videoX for readers. Reader semantics enforces single reader limitation.
In addition:
1. Supports zero-copy operation for a shared capture and output buffer (enabled automatically when possible).
2. Uses DMA contig allocator automatically when possible (falls back to vmalloc).
3. VB2 framework used for the pipeline.
These all are BTW unresolved in the OOT driver, and should help with getting better picture and frame rates over what we can do outside of kernel.
The code will code about 777 rounds of cleanups and tweaks and then I'll send the RFC patch ;-)
1
2
1
Anisse @ FOSDEM
Aissen@social.treehouse.systems@jarkko I know it's work in progress, and you have test programs, etc. What I see missing for somewhere in the next 777 rounds: a small doc of the API, and maybe a minimal test program creating an ultra simple video stream.
1
0
0
Jarkko Sakkinen
jarkko
@Aissen
1. Test program: https://codeberg.org/jarkko/video-loop-test
2. Documenting API usually makes sense as 777 + 1 change, doesn't it? ;-) Anyhow, I keep this in mind! Thanks for the comment.
I'm thinking of kselftest but for the moment out-of-tree test program is easier to work with.
1. Test program: https://codeberg.org/jarkko/video-loop-test
2. Documenting API usually makes sense as 777 + 1 change, doesn't it? ;-) Anyhow, I keep this in mind! Thanks for the comment.
I'm thinking of kselftest but for the moment out-of-tree test program is easier to work with.
1
0
1
@Aissen There's som scoped areas where I need to just play with the driver a bit, and observe how the ends interact. It has been hard to focus to those areas while there's been much bigger existential issues inherited from the OOT driver (broken driver model, practically all code related to frame buffering was obselete by any modern standards and required a full rewrite to bring to vb2/dma-buf universum).
E.g. it might make sense to consider some sort of signaling messaging for the output producer so that it can go to voluntararily to sleep.
E.g. it might make sense to consider some sort of signaling messaging for the output producer so that it can go to voluntararily to sleep.
1
0
1
@Aissen I was thinking about documentation just in RFC scope and I think I will document uapi properly and in addition to that I'll create some kind of "theory of operation" documentation to vcamera.c (the current name). I'll try to make that writeup as clear as possible.
Further than that it is better to sprinkle it more based on feedback. Too much documentation convolutes more an early patch than helps, thus this approach.
Further than that it is better to sprinkle it more based on feedback. Too much documentation convolutes more an early patch than helps, thus this approach.
1
0
0