1. V4L2: Minumum Requirements for New Drivers
Hans Verkuil
Cisco Systems Norway

2. Staging
If it uses controls, then it must use the control framework. Rationale: work is in progress to convert all drivers to the control framework. Having new drivers come in that don't use it makes it hard to ever finish the conversion.
I2C devices must be implemented as sub-devices, using struct v4l2_subdev. Rationale: this ensures reusability. However, might this be too strict for staging?

3. Mainline
Use struct v4l2_device and struct v4l2_fh. Subdevs use v4l2_subdev.
Use the control framework for control handling.
Use videobuf2 for buffer handling (exception: DVB buffers as long as vb2 doesn't support that).
Must pass v4l2-compliance without errors.
Document this in the wiki in the developer section: “Development: Submitting Drivers”

4. V4L2 API Ambiguities and Improvements
Hans Verkuil
Cisco Systems Norway

5. Unknown Colorspace
If a device doesn't tell the driver what colorspace it uses (uvc), should the driver guess or tell the application that the colorspace is unknown?
The driver is best at guessing a colorspace (sRGB usually), but may theoretically get it wrong.
Can the application do anything useful with 'unknown colorspace'?
Proposal: the driver should guess and we should never return 'Unknown Colorspace'.

6. Pixel Aspect Ratio
Pixel aspect: currently this is only available through VIDIOC_CROPCAP. It never really belonged to VIDIOC_CROPCAP IMHO. It's just not a property of cropping/composing. It really belongs to the input/output timings (STD or DV_TIMINGS). That's where the pixel aspect ratio is determined.
It is possible to add it to the dv_timings struct and we can also add it to struct v4l2_standard, but drivers will need to tell the core what the pixel aspect ratio is since VIDIOC_ENUMSTD is now handled inside the V4L2 core and doesn't call the drivers anymore.
An other possibility is to add a new ioctl for this: VIDIOC_G_PIXELASPECT.

7. QUERYCAP for subdevs?
There are no standard ioctls that one could call for a v4l-subdev node to determine whether the device node is a subdev node.
Propose to have subdev nodes support VIDIOC_QUERYCAP as well, and just set a SUBDEVICE capability.
Most fields of struct v4l2_capability apply to a subdev as well, except for 'card'.
Alternative: create a VIDIOC_SUBDEV_QUERYCAP.

8. Tuner Ownership
How to handle tuner ownership if both a video and radio node share the same tuner?
Obvious rules:
Calling S_FREQ, S_TUNER, S_MODULATOR or S_HW_FREQ_SEEK will make the filehandle the owner if possible. EBUSY is returned if someone else owns the tuner and you would need to switch the tuner mode.
Ditto for ioctls that expect a valid tuner configuration like QUERYSTD. This is likely to be driver dependent, though.
Just opening a device node should not switch ownership

9. Tuner Ownership
But it is not clear what to do when any of these ioctls are called:
G_FREQUENCY: could just return the last set frequency for radio or TV: requires that that is remembered when switching ownership. This is what happens today, so G_FREQUENCY does not have to switch ownership.
G_TUNER: the rxsubchans, signal and afc fields all require ownership of the tuner. So in principle you would want to switch ownership when G_TUNER is called. On the other hand, that would mean that calling v4l2-ctl --all -d /dev/radio0 would change tuner ownership to radio for /dev/video0. That's rather unexpected. It is possible to just set rxsubchans, signal and afc to 0 if the device node doesn't own the tuner. I'm inclined to do that.
Should closing a device node switch ownership? E.g. if nobody has a radio device open, should the tuner switch back to TV mode automatically? I don't think it should.
How about hybrid tuners?