Re: [RFC] media: Question about reserving V4L2 UAPI control IDs for out-of-tree rgb133 kernel driver

[Przemek Gajos]

Hi Nicolas,

Thanks for the quick reply.

> I could not find specific changes between 6.19 and 7.0 that would explain this
> failure. Perhaps you could share a bit more details on what you are doing, and
> how it fails ? Are you using v4l2_ctrl_new_custom() ?

It is a fairly old driver we are now modernising. We have a set of
hardware-specific controls for which we have been using
V4L2_CID_PRIVATE_BASE (0x08000000) as a CID base. We have now
integrated the driver into the v4l2 control framework and noticed
that controls that fall into that range are rejected by
v4l2_ctrl_new_custom(). Specifically, there is a gate in the
internal helper v4l2_ctrl_new() that rejects any id greater than or
equal to V4L2_CID_PRIVATE_BASE:

    /* Sanity checks */
    if (id == 0 || name == NULL || !elem_size ||
        id >= V4L2_CID_PRIVATE_BASE ||
        (type == V4L2_CTRL_TYPE_MENU && qmenu == NULL) ||
        (type == V4L2_CTRL_TYPE_INTEGER_MENU && qmenu_int == NULL)) {
            handler_set_err(hdl, -ERANGE);
            return NULL;
    }

I understand that V4L2_CID_PRIVATE_BASE belongs to the legacy
model. From looking into uapi/linux/v4l2-controls.h, my current
understanding is that custom controls should use the User Class
Base and that drivers can get a dedicated offset within that base,
e.g.:

    #define V4L2_CID_USER_<MY_DRIVER_NAME>_BASE \
            (V4L2_CID_USER_BASE + <MY_DRIVER_OFFSET>)

> Up-streaming is the path forward.

We have not made the decision to up-stream the driver yet.
Is up-streaming a requirement for a driver to reserve an offset within the
V4L2_CID_USER_BASE in the v4l2-controls.h header?

Thank you,
Przemyslaw Gajos