[libcamera-devel] [PATCH v2] libcamera: v4l2_device: Workaround faulty control menus

[Marian Buschsieweke]

Hi,

> If that's the case why only push the default to indices?

see the note at
https://www.kernel.org/doc/html/v6.0/userspace-api/media/v4l/vidioc-queryctrl.html#description

    It is possible for VIDIOC_QUERYMENU to return an EINVAL error code for some
    indices between minimum and maximum. In that case that particular menu item
    is not supported by this driver. [...]

I interpret this as "if VIDIOC_QUERYMENU fails, that menu item is not
supported" and not as "if VIDIOC_QUERYMENU fails, that menu item is supported
but has no label". This seems to also be the interpretation behind the
implementation in libcamera that just removes menu items for which
VIDIOC_QUERYMENU fail.

I can test this tomorrow to confirm that exposure_auto cannot be set to any of
[0..3], or whether indeed just the labels are missing.

Assuming the interpretation in the code is correct and in fact the menu
exposure_auto contains no supported item to pick, it is IMO most sensible to
either not expose the control for it, or to provide a bogus single-item menu.
The latter approach resulted in the cleaner and less complex patch (:

Kind regards,
Marian


On Wed, 2 Nov 2022 17:22:37 +0100
Jacopo Mondi <jacopo at jmondi.org> wrote:

> Hi Kieran
> 
> On Wed, Nov 02, 2022 at 10:38:04AM +0000, Kieran Bingham via libcamera-devel
> wrote: [...]  
> 
> Not sure what this mean in practice... The bug report says:
> 
> "Exposure Auto" menu has not a single supported item
> 
> However it is reported as listing 3 menu entries by v4l2-ctl -l
> 
>         exposure_auto 0x009a0901 (menu)   : min=0 max=3 default=0 value=0
> 
> I guess the issue is then that QUERYMENU is not supported ? How does this
> work in UVC, I guess the uvcdriver supports the ioctl, is it the
> device fw which wrongly implements the uvcvideo specification ?
> 
> If that's the case why only push the default to indices ? Aren't min
> and max selectable too ? (yes, we're going to miss all other values in
> between min/max which are != default, but if the device is buggy we
> can't do more than this...)
> 
> As this fix a user bug I don't want to get into the way of this fix,
> but just to validate my understanding can you clarify this last part ?
> 
>  [...]  

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 228 bytes
Desc: OpenPGP digital signature
URL: <https://lists.libcamera.org/pipermail/libcamera-devel/attachments/20221102/97993368/attachment.sig>