Jarkko Sakkinen
Posts
5175Following
336Followers
512OpenPGP: 3AB05486C7752FE1
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 7 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 7 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 7 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
Jarkko Sakkinen
jarkko
There's uxplay but what are options of libraries capable for streaming AirPlay?
0
0
0
Jarkko Sakkinen
jarkko
Edited 8 days 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
0
Jarkko Sakkinen
jarkko
Edited 8 days 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 8 days 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
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
Edited 9 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