Conversation
Jarkko Sakkinen
jarkko
I have a dev-tree: https://git.kernel.org/pub/scm/linux/kernel/git/jarkko/linux-tpmdd.git/log/?h=v4l2-loopback-dev
1. Suck inner guts out of the OOT driver.
2. Wrap it up tpm_vtpm_proxy
So generally looking for advice on:
1. #Pipewire interaction
2. #Gstreamer interaction
Focus on what instead of how. I.e. if this existed how would uapi play for those upstream projects?
#linux #kernel #video4linux #webcam
1. Suck inner guts out of the OOT driver.
2. Wrap it up tpm_vtpm_proxy
So generally looking for advice on:
1. #Pipewire interaction
2. #Gstreamer interaction
Focus on what instead of how. I.e. if this existed how would uapi play for those upstream projects?
#linux #kernel #video4linux #webcam
1
2
2
Jarkko Sakkinen
jarkko
@Conan_Kudo @wtay
OK, so I think what goes wrong in high-level in the OOT driver and its uapi goes in core essence into: if you provide a service, you DO NOT use the client API to implement your service. Just basic API bullshit, overall, not like in kernel particular...
So instead when you open an fd then "you are /dev/videoX" or whatever. I.e. write ops go to the fd not any of /dev/videoX.
So... based on these it's a fuse alike driver for webcams. There really should maybe one /dev/video_loop device or whatever is a good name , and when you open that file, the creation of that file implies the creation of /dev/videoX.
After that the fd interface in user space gives all data and meta-data that you could expect similar devices.
So I think this is the gist of getting it wrong in uapi in that driver. But yeah like internals and thinking went on those can be quite easlily refactored out and wrapped in a nicer API package.
So yeah I'll do what I do put this in clean shape and send RFC patch set. So can CC obviously people to that once I get it out (few weeks smthng).
OK, so I think what goes wrong in high-level in the OOT driver and its uapi goes in core essence into: if you provide a service, you DO NOT use the client API to implement your service. Just basic API bullshit, overall, not like in kernel particular...
So instead when you open an fd then "you are /dev/videoX" or whatever. I.e. write ops go to the fd not any of /dev/videoX.
So... based on these it's a fuse alike driver for webcams. There really should maybe one /dev/video_loop device or whatever is a good name , and when you open that file, the creation of that file implies the creation of /dev/videoX.
After that the fd interface in user space gives all data and meta-data that you could expect similar devices.
So I think this is the gist of getting it wrong in uapi in that driver. But yeah like internals and thinking went on those can be quite easlily refactored out and wrapped in a nicer API package.
So yeah I'll do what I do put this in clean shape and send RFC patch set. So can CC obviously people to that once I get it out (few weeks smthng).
1
0
0
@Conan_Kudo @wtay So the other problem is racy /dev/videoX instance. The problem is in that state changes of the video device are racy by definition. That is obviously unacceptable.
I.e. probably APi should be something along lines of:
1. fd = open("/dev/video_loop")
2. ioctl(fd, "set properties")
2. ioctl(fd, "create")
And post that anything that the device is written goes through that fd and is tied to its life-cycle. That is the only way to guarantee that it is tied to life-cycle of the device per se. Only when the fd is written nothing ever happens in the state of /dev/videoX.
For testing a tool is needed for "capture devices", which will create something for ffmepg to write to so that another ffmpeg instance can play it from /dev/videoX.
I.e. probably APi should be something along lines of:
1. fd = open("/dev/video_loop")
2. ioctl(fd, "set properties")
2. ioctl(fd, "create")
And post that anything that the device is written goes through that fd and is tied to its life-cycle. That is the only way to guarantee that it is tied to life-cycle of the device per se. Only when the fd is written nothing ever happens in the state of /dev/videoX.
For testing a tool is needed for "capture devices", which will create something for ffmepg to write to so that another ffmpeg instance can play it from /dev/videoX.
0
0
0