Hi,
Hans Verkuil wrote:
>>>> +
>>>> +#define VIDIOC_SUBDEV_G_FMT _IOWR('V', 4, struct
>>>> v4l2_subdev_format)
>>>> +#define VIDIOC_SUBDEV_S_FMT _IOWR('V', 5, struct
>>>> v4l2_subdev_format)
>>>> +#define VIDIOC_SUBDEV_ENUM_MBUS_CODE \
>>>> + _IOWR('V', 2, struct v4l2_subdev_mbus_code_enum)
>>>> +#define VIDIOC_SUBDEV_ENUM_FRAME_SIZE \
>>>> + _IOWR('V', 74, struct v4l2_subdev_frame_size_enum)
>>>
>>> The ioctl numbering is a bit scary. We want to be able to reuse V4L2
>>> ioctls
>>> with subdevs where appropriate. But then we need to enumerate the subdev
>>> ioctls using a different character to avoid potential conflicts. E.g.
>>> 'S'
>>> instead of 'V'.
>>
>> There's little chance the ioctl values will conflict, as they encode the
>> structure size. However, it could still happen. That's why I've reused the
>> VIDIOC_G_FMT, VIDIOC_S_FMT, VIDIOC_ENUM_FMT and VIDIOC_ENUM_FRAMESIZES
>> ioctl
>> numbers for those new ioctls, as they replace the V4L2 ioctls for
>> sub-devices.
>> We can also use another prefix, but there's a limited supply of them.
>
> Hmm, perhaps we can use 'v'. That's currently in use by V4L1, but that's
> on the way out. I'm not sure what is wisdom here. Mauro should take a look
> at this, I think.
Similar V4L2 ioctls exists but they still are part of a different API.
So I'd go with 'S' (or something else non-'V') unless the ioctl is
exactly the same as in V4L2. And allocate numbers starting from 0 if
possible.
But I agree, let's wait Mauro's opinion...
Regards,
--
Sakari Ailus
sakari.ai...@maxwell.research.nokia.com
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
