Next iteration:
struct vcam_ioc_new {
__u64 device_name;
__u32 device_nr;
__u32 output_fd;
__u32 control_fd;
__u8 reserved[12]; /* must be zeroed */
};
enum vcam_control_flags {
VCAM_CONTROL_STREAM_ON = 1ULL << 0,
};
#define VCAM_IOC_NEW _IOWR('v', 0x00, struct vcam_ioc_new)
control_fd emits u64's and read() returns when flags differ from previous call.
struct vcam_ioc_new {
__u64 device_name;
__u32 device_nr;
__u32 output_fd;
__u32 control_fd;
__u8 reserved[12]; /* must be zeroed */
};
enum vcam_control_flags {
VCAM_CONTROL_STREAM_ON = 1ULL << 0,
};
#define VCAM_IOC_NEW _IOWR('v', 0x00, struct vcam_ioc_new)
control_fd emits u64's and read() returns when flags differ from previous call.
0
0
0
Jarkko Sakkinen
jarkko
Edited 3 months ago
Stream signaling for vcam: output_fd when read returns (sequence, flags) pairs. Currently there is only a single flag: VCAM_CONTROL_STREAM_ON.
Blocking read() and poll() can be then used to in the source to see client app starts or stops streaming video.
Blocking read() and poll() can be then used to in the source to see client app starts or stops streaming video.
1
0
0
Jarkko Sakkinen
jarkko
I have a project of finishing everything in open source that I've started as side quests within last 2-3 years but never finished.
I already created tpm2-protocol and tpm2sh for "stackless" hacking of TPMs and vcam is on the way in near future.
After these the backlog contains:
1. TPM2 asymmetric keys (or possibly more generic hardware asymmetric keys).
2. zmodem2/lrzsz2. There's a few bugs I need to sort out :-)
3. Refreshing and refining dhowell's old container patches.
I'll definitely start with bullet three as it has waited far too long, about the same time as vcam was on hold :-) (rt @neal).
I already created tpm2-protocol and tpm2sh for "stackless" hacking of TPMs and vcam is on the way in near future.
After these the backlog contains:
1. TPM2 asymmetric keys (or possibly more generic hardware asymmetric keys).
2. zmodem2/lrzsz2. There's a few bugs I need to sort out :-)
3. Refreshing and refining dhowell's old container patches.
I'll definitely start with bullet three as it has waited far too long, about the same time as vcam was on hold :-) (rt @neal).
1
0
2
Jarkko Sakkinen
jarkko
Edited 3 months ago
Refining my test program for vcam just a bit:
1. "Thread" A creates /dev/videoX through /dev/vcam and starts producing checker board animation.
2. "Thread" B opens /dev/videoX and uses optionally shared DMA-BUF to establish zero-copy.
3. For the time being B displays the animation on screen but in a headless kselftest it would do frame comparison.
I'm not actually sure if I even use threads. It could also execute the steps in sequence I think. Neither sure if this ends up as a kselftest but it is very possible.
Probably makes sense to turn this into kselftest as minifb is the only outside dependency and that sequential approach gives means to do headless comparative testing...
E.g., it could be further refined to iterate through all supported formats and stuff like that.
1. "Thread" A creates /dev/videoX through /dev/vcam and starts producing checker board animation.
2. "Thread" B opens /dev/videoX and uses optionally shared DMA-BUF to establish zero-copy.
3. For the time being B displays the animation on screen but in a headless kselftest it would do frame comparison.
I'm not actually sure if I even use threads. It could also execute the steps in sequence I think. Neither sure if this ends up as a kselftest but it is very possible.
Probably makes sense to turn this into kselftest as minifb is the only outside dependency and that sequential approach gives means to do headless comparative testing...
E.g., it could be further refined to iterate through all supported formats and stuff like that.
0
0
0
Jarkko Sakkinen
jarkko
@jani, Didn't DRM documentation have some nice way to embed and include documentation from source files?
In vcam, I will have at least documentation blocks for theory of operation and very like locking hierarchy (depending on complexity). It would be nice to have in Documentation/ something that includes those snippets.
Just looking for tips and too lazy for RTFM ATM :-)
In vcam, I will have at least documentation blocks for theory of operation and very like locking hierarchy (depending on complexity). It would be nice to have in Documentation/ something that includes those snippets.
Just looking for tips and too lazy for RTFM ATM :-)
1
0
1
Jarkko Sakkinen
jarkko
For bare-metal kernel testing there is nothing as awesome as Raspberry Pi 400 :-)
Keyboard and GPIOs (for e.g. attaching TPM chip) make it optimal.
Keyboard and GPIOs (for e.g. attaching TPM chip) make it optimal.
0
0
1
Jarkko Sakkinen
jarkko
AI-based product guaranteed to exist at some point: memorial versions of people after they die.
1
0
0
Jarkko Sakkinen
jarkko
my favorite GUI app for couple of years: foot :-)
it really nailed terminal for wayland, and please never make it cross-platform!
it really nailed terminal for wayland, and please never make it cross-platform!
0
0
0
@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
@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
Jarkko Sakkinen
jarkko
vcamera is probably a better name (vs. v4l2-vcam) and v4l2-core is wrong place for the driver so for RFC review I just place it straights under drivers/media. No reason to try to be smart here...
0
1
1
Jarkko Sakkinen
jarkko
vcamera is probably a better name (vs. v4l2-vcam) and v4l2-core is wrong place for the driver so for RFC review I just place it straights under drivers/media. No reason to try to be smart here...
0
1
1
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
Jarkko Sakkinen
jarkko
Edited 3 months 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