Allow STM32 DCMIPP to work with UVC sample #94562
Draft
+777
−227
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
The UVC class was deciding itself which formats were sent to the host. Remove this logic out of the UVC class and introduce uvc_add_format() to give the application the freedom of which format to list. Signed-off-by: Josuah Demangeon <[email protected]>
The UVC class now lets the application select the format list sent to the host. Leverage this in the sample to filter out any format that is not expected to work (buffer too big, rarely supported formats). Signed-off-by: Josuah Demangeon <[email protected]>
Add USB UVC device's new uvc_add_format() function to the release note, and document the semantic changes of UVC APIs in the migration guide. Signed-off-by: Josuah Demangeon <[email protected]>
Add description and fourcc define for some of the 2 and 3 planes pixel formats. Signed-off-by: Alain Volmat <[email protected]>
ISP is part of the pixel pipes hence it doesn't make any sense to try to call ISP external handlers if the DCMIPP doesn't have pixel pipes available. Signed-off-by: Alain Volmat <[email protected]>
Add support for NV12/NV21, NV16/NV61 and YUV420/YVU420 (semi)planar formats which can be output by the main zephyrproject-rtos#1 pipe. Signed-off-by: Alain Volmat <[email protected]>
Currently the DCMIPP driver rely on a Kconfig in order to
select the right sensor resolution / format to pick.
This also makes the exposure of caps easier since it can
be exposed as:
DUMP pipe: same caps as mentioned in Kconfig
MAIN pipe: any format supported on this pipe and resolution
starting at sensor selected resolution down to
64 times smaller (which is the maximum of the
downscale)
AUX pipe: same as MAIN except without the semi-planar and
planar formats
Signed-off-by: Alain Volmat <[email protected]>
Some devices allow for downscale / upscale via the set_selection compose API. When using it, it is necessary to perform a set_selection of the compose target prior to setting the format. In order to allow non-compose aware application to benefit from it, introduce a helper which take care of setting the compose prior to setting the format. Signed-off-by: Alain Volmat <[email protected]>
Simplify the code by using the video_set_compose_format helper. Signed-off-by: Alain Volmat <[email protected]>
Honor the CONFIG_VIDEO_BUFFER_POOL_ALIGN config by using the video_buffer_aligned_alloc function instead of video_buffer_alloc in order to provide properly aligned buffers to drivers. Signed-off-by: Alain Volmat <[email protected]>
Use the helper video_set_compose_format in order to allow controlling the compose. Signed-off-by: Alain Volmat <[email protected]>
Select from commonly used resolution when the video device advertise capabilities using range. Signed-off-by: Alain Volmat <[email protected]>
|
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
This PR contains various area commits.
I keep this in draft since this is still work in progress and I'd like to open the discussion about those topics.
I added the
video_set_compose_formathelper (probably not the best name) in order to add automatically the call to set_selection. However we might want, in the same helper or not to go even further of that and, if the device support it use crop to achieve the format requested, there could also be an option to for example keep aspect-ratio, which do the heavy lifting of checking the native resolution and perform the crop / compose in order to get a frame with the requested resolution while keeping aspect-ratio (if it has been asked to).I used this new helper on the UVC sample as well, making it easy to select the right resolution.
When a device is advertising a range of width/height, the current UVC sample only expose the max and min resolutions (assuming they can be achieved from a memory point of view).
There would be various way to achieve computing of intermediate resolutions, computing the aspect ratio as well, depending on the step value advertised by the device the amount of intermediate resolution requested (or should I say limited).
In a trial to keep it simple, I put instead a list of commonly used resolution and have the sample app simply check if this can be achieved or not.
This PR depends on 2 other PRs, PR #93192 and PR #94081 so I merged them at the beginning so only the last 6 commits are relevant in this serie.