Skip to content

Expanded support for Libcamera Controls (ControlInfoMap and ControlInfo) #46

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

Open
wants to merge 15 commits into
base: main
Choose a base branch
from

Conversation

SoZ0
Copy link

@SoZ0 SoZ0 commented Dec 8, 2024

I believe i have implemented the rest of ControlInfoMap and ControlInfo and created a few methods to turn it into an iterator.

I have tested on my host machine (Libcamera 0.3.1, Fedora 40 - x86) and with cross compiling to arm64 (Libcamera 0.3.2, Debian Bookworm). The code works on both x86 and arm64 (tested with a compute module 4).

  • Exposed the methods to get the name, id and type from the ControlID type directly but they have not been implemented rust side.
  • Exposed a few of the methods to interact with ControlIdMap and plan to give it the same treatment as done with ControlInfoMap
  • Made an Iterator for ControlInfoMap to allow rust to loop through the contents of the ControlInfoMap
  • Implemented all of ControlInfo's methods with each of them returning their respective rust counterparts (min, max, def all returning ControlValue)
  • Modified build.rs and tomls for libcamera to fix issues with not being able to compile with cross
  • updated bindgen and cc to 0.70 and 0.3 respectively

I am working on a project that requires quite extensive information from libcamera so I will continue to make pull request as I expand libcamera-sys and libcamera to support the remaining missing implementation I need

@SoZ0
Copy link
Author

SoZ0 commented Dec 8, 2024

I realized I skipped over the values method inside of ControlInfo. I have added an implementation that appears to work with the same systems mentioned before.

I also expanded on top of the libcamera-meta to allow getting the id and names of the ControlId/PropertyId from the enum directly.

@SoZ0 SoZ0 changed the title Add support for iterating and getting information from ControlInfoMap and ControlInfo Expanded support Libcamera Controls (ControlInfoMap and ControlInfo) Dec 8, 2024
@SoZ0 SoZ0 changed the title Expanded support Libcamera Controls (ControlInfoMap and ControlInfo) Expanded support for Libcamera Controls (ControlInfoMap and ControlInfo) Dec 8, 2024
@chemicstry
Copy link
Contributor

Hey, sorry for not reviewing this earlier. The changes look good, but could you rebase or cherry pick on main branch? Many things not related to ControlInfo have been merged

@Prowler1000
Copy link

If this has no movement on it in a few days I'll probably grab the changes, resolve the conflicts and rebase. I made similar changes on my own fork (though very crude). I'm re-writing the project I used libcamera-rs for currently, so I'm in no hurry and don't want to step on anyones toes

@SoZ0
Copy link
Author

SoZ0 commented May 31, 2025

the other changes should be removed, working on getting the branch ready to merge with main
should be done in a few hours if not sooner

@SoZ0
Copy link
Author

SoZ0 commented May 31, 2025

should be good now, let me know if anything needs changing

@fishrockz
Copy link
Collaborator

We might need to update the version of clippy we use in our CI as rust v1.86 is giving me clippy lints for this PR.

@fishrockz
Copy link
Collaborator

fishrockz commented Jun 1, 2025

@SoZ0 I have had quite a few demands on my time this week but i promise i will review this more thoroughly shortly.

I was able to set controls and get there values dynamically with mainline, and so as this PR does not contain any examples, what it is you are able to do with this, PR? Im not trying to be dismissive, i will try and test this on hardware and make sure it builds for the supported versions before approving so was wondering what i should be looking for when testing etc :)

@SoZ0
Copy link
Author

SoZ0 commented Jun 2, 2025

no worries, I'll write up a few examples of what this changes exactly but the main gist of this was to expose more of ControlInfoMap and ControlInfo. I will try to have them done by Wednesday

@SoZ0
Copy link
Author

SoZ0 commented Jun 3, 2025

I have created the examples if you would like to look them over they live with the other examples:

  • camera_iter.rs
    just display a new iterator for the camera manager does not remove the old method of list cameras, not shown in the example but is still added, camera manager now has a stop method now to match how it works inside of libcamera and will only destroy camera manager if it is dropped. Before if you needed to stop and start camera manager it required dropping and destroying the camera manager.
  • list_cameras.rs
    has been updated to now display all the camera's controls and their respective values (min, max, def, values), from my understanding and from what I could find this was not possible before. You needed prior knowledge of what controls were already present on the camera, or to just try all possible controls to determine what is available. you can now iterate and list all controls the camera contains. For context the program I needed this for the code is required to be camera agnostic so knowing controls beforehand was not possible
  • read_controls.rs
    I believe this displays mostly what this PR is about, it shows how to read values stored in ControlInfo that were not accessible before (from my understanding).

I have tested the examples on several different cameras without issue so far:

  • Logitech StreamCam Webcam
  • Logitech C270
  • OV9281 from 3 different manufacturers,
  • IMX585
  • handle full of other camera modules (I forgot the model numbers)

I have tested all of these cameras on a compute module 4/5 with a MIPI/CSI connection and the Logitech cameras were tested on a Fedora 40/41/42 machine as well as the cm4/5 as a USB webcam. I have not tested all permutations of this list but I have been able to read up to 4 different camera module's controls at the same time (I ran out of ports) but I believe there is no limit or at least the limit is high enough to be used in reasonable any use case.

There may be an edge case I could be missing still, but I feel very confident that the changes work, will not disrupt any existing code bases and is beneficial for the library.

If you need any more information or would like to see and specific use cases please let me know. I will be glad to help out with anything you might need.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants