On (21/03/24 12:00), Tomasz Figa wrote: [..] > > I guess in our case we need to talk about rectangle,auto-controls tuple > > that we send to firmware > > > > rect { > > (0, 0), (INT_MAX, INT_MAX) > > } > > auto-controls { > > INT_MAX > > } > > > > For ROI user-space also must provide valid auto-controls value, which > > normally requires GET_MIN/GET_MAX discovery. > > > > v4l2 selection API mentions only rectangle adjustments and errnos like > > -ERANGE also mention "It is not possible to adjust struct v4l2_rect r > > rectangle to satisfy all constraints given in the flags argument". > > > > So in case when auto-controls is out of supported range (out of > > GET_MIN, GET_MAX range) there is no way for us to tell user-space that > > auto-controls is wrong. We probably need silently pick up the first > > supported value, but not sure how well this will work out in the end. > > Shouldn't the autocontrol selection be done via a separate bitmask > control rather than some custom flags in the selection API? That selection must be done before we send ROI to the firmware. Firmware H that I have supports split controls - we can send ROI::rectangle and ROI::autocontrols separately. But other firmwares don't tolerate such a thing and by the time we issue uvc_query_ctrl(stream->dev, UVC_SET_CUR UVC_CT_REGION_OF_INTEREST_CONTROL roi, + sizeof(struct uvc_roi_rect)) roi rectangle should be of size 5 * u16 and contain values that firmware will accept, including autocontrols.