On Sunday, June 12, 2011 19:08:03 Mauro Carvalho Chehab wrote: > > I think in the longer term we need to change the spec so that: > > > > 1) Opening a radio node no longer switches to radio mode. Instead, you need to > > call VIDIOC_S_FREQUENCY for that. > > 2) When VIDIOC_S_FREQUENCY the type field should match the video/radio node it > > is called on. So for /dev/radio type should be RADIO, for others it should be > > ANALOG_TV. Otherwise -EINVAL is called. > > > > So this might be a good feature removal for 3.2 or 3.3. > > I'm OK with that. How about this: diff --git a/Documentation/feature-removal-schedule.txt b/Documentation/feature-removal-schedule.txt index 1a9446b..9df0e09 100644 --- a/Documentation/feature-removal-schedule.txt +++ b/Documentation/feature-removal-schedule.txt @@ -600,3 +600,25 @@ Why: Superseded by the UVCIOC_CTRL_QUERY ioctl. Who: Laurent Pinchart <laurent.pinchart@xxxxxxxxxxxxxxxx> ---------------------------- + +What: For VIDIOC_S_FREQUENCY the type field must match the device node's type. + If not, return -EINVAL. +When: 3.2 +Why: It makes no sense to switch the tuner to radio mode by calling + VIDIOC_S_FREQUENCY on a video node, or to switch the tuner to tv mode by + calling VIDIOC_S_FREQUENCY on a radio node. This is the first step of a + move to more consistent handling of tv and radio tuners. +Who: Hans Verkuil <hans.verkuil@xxxxxxxxx> + +---------------------------- + +What: Opening a radio device node will no longer automatically switch the + tuner mode from tv to radio. +When: 3.3 +Why: Just opening a V4L device should not change the state of the hardware + like that. It's very unexpected and against the V4L spec. Instead, you + switch to radio mode by calling VIDIOC_S_FREQUENCY. This is the second + and last step of the move to consistent handling of tv and radio tuners. +Who: Hans Verkuil <hans.verkuil@xxxxxxxxx> + +---------------------------- Regards, Hans -- 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