-
Notifications
You must be signed in to change notification settings - Fork 521
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Document an API-way to test for v4l2loopback module presence #397
Comments
i don't see any benefit apart from what we already have. |
So if I see this right, it mostly boils down to:
Unfortunately it doesn't seem like So basically there are two things open:
Anything I'm missing? |
that's not what i meant. what i meant is:
i don't see a reason to document this. i don't understand why you want to do that in the first place. there is no "API-way" to detect the presence of a webcam, and yet this is not a problem. |
The question boils down to allow the program e.g. to create additional output devices as necessary (similar to the dynamic cam allocation from v4l2loopback-ctl) for e.g. debugging. |
how would "an API-way to test for v4l2loopback module presence" help with that feat? |
In an ideal world. all those functions would be covered in a small userland library that other tools (like v4l2loopback-ctl) could just call to do things. An "API-way to test module presence" could (in absense of a usermode library) be a quick sanity check a program could perform (#397 (comment), steps 1+2) and would ideally know after those steps succeeded, that (except for operations not permitted) the remaining tasks are likely to also succeed. View it from the UX perspective: Giving an user the error "Required kernel functions provided by module XY are not available." is much better, than replying with "Failed to open video device" (for a device name the user supplied). Another aspect why a documented way to check for the presence of the module is strongly encouraged are interoperability and backward compatibility: As long as I can maintain a minimal interface that users of my functionality can rely on, I can change whatever else I like and always allow the user to figure out, how to react in a particular situation. And if I even try to keep most of my interface stable, I have high chances that even really old software can use the most recent releases without need for recompilation. |
it seems you cannot really make up your mind what you actually want - at least, I cannot make up my mind what you actually want. afaiu, "to allow the program e.g. to create additional output devices" is totally unrelated to "loopback device not available" (which is how I read your UX example). my argument is really you should not depend on a given module, but on a given functionality.
so the question is still: what is it that you do want to detect? as for "a small userland library that other tools (like v4l2loopback-ctl) could just call to do things.": the |
ACK.
Okay. And for those
Granted. The userland library doesn't need to do much normally. One purpose it can have is to work around API changes in the module or with different versions/forks of the module. A second (probably more interesting usecase) is abstraction to simplify common tasks for users of the functionality, like iterating devices, get/set properties, etc … The userland library is fully optional and not part of what I want to have as a result of this PR. What I'm aiming at is getting a well-defined interface, with everything I need to use it, in header files, that are properly available for use through programs not part of this repository's source tree. If you say this API is the ioctl interface. That's fine with me. Just make sure there's a header providing all the ioctl constants, enums, types etc.pp. that a program needs (that part is IMHO missing). The second thing that's missing is maybe a oneliner in the docs saying "The module can be used in your own software by including file XY.h". FWIW: On Debian/Ubuntu I'm basically just missing a package |
you are missing the headers because there hasn't been a release of |
Is such a release planned already? Any rough timescale maybe? TIA. |
i'd like to have #359 implemented first, as i figure the API will change a bit. |
Environment
v4l2loopback
version: 0.12.3Problem:
Steps to reproduce:
Observed Results:
I could not find a suitable, documented way how to detect if v4l2loopback is loaded other than trying to look for the module in the list of loaded modules, trying to find its control device file or trying to access some video device in a way only permitted IFF the module is loaded. Unfortunately the documentation that comes with this module documents no easy way for userland tools to check for the kernel module's presence or its version/capabilities.
Expected Results:
Some API or other easy to check means that a user-land application can use to check if v4l2loopback is available and gather information about its capabilities.
A possible solution to this might e.g. providing a standardized file in procfs that the kernel module populates with its configuration once it's loaded or configured. Alternatively a subtree inside sysfs might be provided for capability gathering and configuration purposes.
The text was updated successfully, but these errors were encountered: