-
Notifications
You must be signed in to change notification settings - Fork 8.2k
drivers: video: controls: rename all CIDs to Linux counterpart #78802
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
drivers: video: controls: rename all CIDs to Linux counterpart #78802
Conversation
ef5cb5c to
ad81bdc
Compare
|
I'm happy with applying |
|
@ngphibang please help review |
ad81bdc to
b8c33b8
Compare
b8c33b8 to
0d70c17
Compare
ngphibang
left a comment
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM except a minor remark on the organization of the two last commits. Can we squash them ?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think these should not be introduced in the previous commit and then removed here.
I think this commit can be squashed withthe previous one ?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I tried to decompose the steps as much as possible, and give a safe backup point to fall back to, but that's also very much possible to fallback to before the PR merge!
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I understand that you add these macros in this commit and then remove them in the next commit to keep the bisectability (buildable). But it's simpler if we merge this commit with the next one, no ?
0d70c17 to
b5f04d0
Compare
b5f04d0 to
3a583c3
Compare
8d1464a to
63e2a69
Compare
|
I picked the opportunity to change the documentation style, making enums in the middle of the CID list hopefully less intrusive, and make it easier to insert new CIDs (i.e. no alignment change needed). Let me know if it was better before, easy for me to revert. |
63e2a69 to
02e23f2
Compare
ab47c24 to
86049bf
Compare
37086a1 to
a5c88d0
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The video-controls.h only defines CID macros. It uses nothing from device.h, kernel.h, etc. Although it's not in this PR scope but I recommend to drop all included headers.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Good point! Instead of shuffling these headers, I removed them.
This might have been code added and removed later (refactoring).
a5c88d0 to
aad1e7c
Compare
|
@kartben Could you revisit this PR ? Thanks. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I just rechecked this VIDEO_CID_VENDOR_CLASS_BASE. In fact, this is Zephyr-specific and does not exist in Linux.
Its equivalent counterpart in Linux should be V4L2_CID_PRIVATE_BASE defined here. Could you change to this one (I also need this CID for the upcomming control framework PR) ? Thanks !
PS: Otherwise, I can change it in my PR just by a commit (it seems simpler this way)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Ah right, in include/uapi/linux/videodev2.h I did not check there!
/* User-class control IDs defined by V4L2 */
#define V4L2_CID_MAX_CTRLS 1024
/* IDs reserved for driver specific controls */
#define V4L2_CID_PRIVATE_BASE 0x08000000I pushed the change.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
VIDEO_CID_VENDOR_CLASS_BASE need to be changed to VIDEO_CID_PRIVATE_BASE to be aligned with Linux
aad1e7c to
1bafaf8
Compare
The V4L2 and V4Z list of control IDs are slightly different. Use the same CIDs as Linux, with the exact same numbers to facilitate debug and co-development. This also rename the GENERIC class into BASE as in Linux. No change in the video CIDs names in this commit. Signed-off-by: Josuah Demangeon <[email protected]>
Refers to the CID numbers found in the Linux Kernel so that each CID of Zephyr matches the CIDs of Linux. The new CIDs introduced in Zephyr can then follow the same number and naming found on Linux. No renaming of the CID macro names is done yet. Signed-off-by: Josuah Demangeon <[email protected]>
Now that Control IDs have different classes, sort them to their apropriate classes sections. Signed-off-by: Josuah Demangeon <[email protected]>
This uses Linux V4L2 controls as a reference to give names to the CIDs. Apply the renaming down to the drivers that use them. Signed-off-by: Josuah Demangeon <[email protected]>
Make controls more readable and intuitive to extend, with definition of each control value to help disambiguate between similar controls, such as BRIGHTNESS vs GAIN. Move the class definition to the top of each relevant class, like it is on Linux for the V4L2_CID_..._CLASS_BASE variables. Signed-off-by: Josuah Demangeon <[email protected]>
The video CIDs got changed, and users will be impacted and need to rename some constants. Offer a strategy for finding the new names in the migration guide for the upcoming release. Signed-off-by: Josuah Demangeon <[email protected]>
1bafaf8 to
845d408
Compare
|
force-push:
|
doc/releases/migration-guide-4.1.rst
Outdated
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
| In most cases, removing the category prefix is enough: ``VIDEO_CID_CAMERA_GAIN`` becomes | |
| In most cases, removing the category prefix is enough, e.g. ``VIDEO_CID_CAMERA_GAIN`` becomes |
| /** Amount of perceived light of the image, the luma (Y') value. */ | ||
| #define VIDEO_CID_BRIGHTNESS (VIDEO_CID_BASE + 0) | ||
|
|
||
| /** Amount of difference between the bright colors and dark colors. */ | ||
| #define VIDEO_CID_CONTRAST (VIDEO_CID_BASE + 1) | ||
|
|
||
| /** Colorfulness of the image while preserving its brightness */ | ||
| #define VIDEO_CID_SATURATION (VIDEO_CID_BASE + 2) | ||
|
|
||
| /** Shift in the tint of every colors, clockwise in a RGB color wheel */ | ||
| #define VIDEO_CID_HUE (VIDEO_CID_BASE + 3) | ||
|
|
||
| /** Amount of time an image sensor is exposed to light, affecting the brightness */ | ||
| #define VIDEO_CID_EXPOSURE (VIDEO_CID_BASE + 17) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I appreciate the effort to make sure all public API is documented but FWIW I find these oddly worded for some reason. I guess that's what happens when the names are already mostly self-explanatory and one doesn't want to literally paraphrase them in the comment. Not blocking though :)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yes, I have same thoughts too and sometimes, the explanation is not totally correct as it is difficult to explain in short words, so it is better to not explain, developers who actually use these CID need to understand them, I think :-). But it's not a blocking point.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Reading them again, these do not help understanding what the control do.
Better not risk defining them slightly differently than Linux ones.
If there need to be any doc effort, this can go in Linux.
Frequent issue of newbies: they reinvent the wheel.
New PR to address these small changes. Thank you for the feedback . :)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
How about a link to this page for reference?
https://www.kernel.org/doc/html/latest/userspace-api/media/v4l/control.html
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yes, I think it's a good idea but I am not sure if it's OK in Zephyr to refer to documentation of a different project.
This aims to improve compatibility between Linux and Zephyr sources in order to facilitate debugging and implementing solution that covers both system, such as protocols to control video systems.
The CIDs numbers are expected to be exaactly the same to further help debugging.
The existing CIDs are kept as compatibility defines to the new V4L2-style names.