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.ailus@xxxxxxxxxxxxxxxxxxxxxxxxxx -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html