RFC: V4L2 API ambiguities

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



During the Plumbers Conference a few weeks ago we had a session to resolve V4L2
ambiguities. It was very successful, but we didn't manage to tackle two of the
harder topics, and a third one (timestamps) cause a lot of discussion on the
mailinglist after the conference.

So here is the list I have today. Any other ambiguities or new features that
should be added to the list?

Regards,

	Hans



1) Make a decision how to tell userspace that the monotonic timestamp is used.

Several proposals were made, but no decision was taken AFAIK. Can someone
(Sakari?) make a summary/current status of this?


2) 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 or
composing. It really belongs to the input/output timings (STD or DV_TIMINGS).
That's where the pixel aspect ratio is determined.

While it is possible to add it to the dv_timings struct, I see no way of cleanly
adding it to struct v4l2_standard (mostly because VIDIOC_ENUMSTD is now handled
inside the V4L2 core and doesn't call the drivers anymore).

An alternative is to add it to struct v4l2_input/output, but I don't know if it
is possible to define a pixelaspect for inputs that are not the current input.
What I am thinking of is just to add a new ioctl for this: VIDIOC_G_PIXELASPECT.


3) 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.

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?
--
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


[Index of Archives]     [Linux Input]     [Video for Linux]     [Gstreamer Embedded]     [Mplayer Users]     [Linux USB Devel]     [Linux Audio Users]     [Linux Kernel]     [Linux SCSI]     [Yosemite Backpacking]
  Powered by Linux