Jarkko Sakkinen
jarkko
Edited 4 months 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
Jarkko Sakkinen
jarkko
There's uxplay but what are options of libraries capable for streaming AirPlay?
0
0
0
Jarkko Sakkinen
jarkko
Edited 4 months ago
I replaced the misuse of VIDIOCs on driver side with a dedicated ioctl interface:
VCAM_OUTPUT_IOC_QUERY
VCAM_OUTPUT_IOC_SET_FORMAT
VCAM_OUTPUT_IOC_ALLOC_FRAMES
VCAM_OUTPUT_IOC_IMPORT_DMABUF
VCAM_OUTPUT_IOC_QUEUE
VCAM_OUTPUT_IOC_DEQUEUE
VCAM_OUTPUT_IOC_FREE_FRAMES
This is accessed through output_fd. In addition vma_ioc_new returns control_fd, which is read/poll interface for the streaming status.
With these two interfaces it should be possible to implement drivers for streaming sources such as smartphones.
I feel that this project is going to really awesome direction :-)
#linux #kernel #video
VCAM_OUTPUT_IOC_QUERY
VCAM_OUTPUT_IOC_SET_FORMAT
VCAM_OUTPUT_IOC_ALLOC_FRAMES
VCAM_OUTPUT_IOC_IMPORT_DMABUF
VCAM_OUTPUT_IOC_QUEUE
VCAM_OUTPUT_IOC_DEQUEUE
VCAM_OUTPUT_IOC_FREE_FRAMES
This is accessed through output_fd. In addition vma_ioc_new returns control_fd, which is read/poll interface for the streaming status.
With these two interfaces it should be possible to implement drivers for streaming sources such as smartphones.
I feel that this project is going to really awesome direction :-)
#linux #kernel #video
0
0
1
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 4 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 4 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