Re: RFC: V4L2 API ambiguities
On Mon October 15 2012 13:35:45 Hans Verkuil wrote: 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? I've got another: Right now there are no standard ioctls that one could call for a v4l-subdev node to discover whether the device node is really a subdev node. For other v4l nodes we have QUERYCAP, but that's not available for subdev nodes. I propose that QUERYCAP support is added (and will be required) for subdev nodes. The capabilities field will be set to V4L2_CAP_SUBDEVICE only (at least for now). All other fields of v4l2_capability are just as valid for subdevs as they are for normal v4l devices. Regards, Hans -- 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
Re: [media-workshop] RFC: V4L2 API ambiguities
Hi Hans, On Monday 15 October 2012 13:35:45 Hans Verkuil wrote: 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? Small topic that we've briefly discussed on IRC: if a device doesn't tell the driver what color space it uses, should the driver guess or tell the application that the color space is unknown ? I've ran into that issue for the uvcvideo driver, while I agree with you that in that case the color space is very likely sRGB, and that the driver is probably in a better position to make that guess than the userspace application (as the driver knows it handles a webcam), what should be the rule ? 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). Isn't that an implementation issue instead of an API issue ? 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? -- Regards, Laurent Pinchart -- 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
RFC: V4L2 API ambiguities
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 majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [Workshop-2011] RFC: V4L2 API ambiguities
Hi, On 08/13/2012 09:15 PM, Sylwester Nawrocki wrote: snip And if a driver also supports single-plane formats in addition to 1 plane formats, should V4L2_CAP_VIDEO_CAPTURE be compulsary? Yes, so that non multi-plane aware apps keep working. There is the multi-planar API and there are multi-planar formats. Single- and multi-planar formats can be handled with the multi-planar API. So if a driver supports single- and multi-planar formats by means on multi-planar APIs, there shouldn't be a need for signalling V4L2_CAP_VIDEO_CAPTURE, which normally indicates single-planar API. The driver may choose to not support it, in order to handle single-planar formats. Thus, in my opinion making V4L2_CAP_VIDEO_CAPTURE compulsory wouldn't make sense. Unless the driver supports both types of ioctls (_mplane and regular versions), we shouldn't flag V4L2_CAP_VIDEO_CAPTURE. Ok. Regards, Hans -- 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
Re: [Workshop-2011] RFC: V4L2 API ambiguities
Hi, On 08/14/2012 02:00 AM, Laurent Pinchart wrote: Hi Hans, On Monday 13 August 2012 15:13:34 Hans de Goede wrote: [snip] 4) What should a driver return in TRY_FMT/S_FMT if the requested format is not supported (possible behaviours include returning the currently selected format or a default format). The spec says this: Drivers should not return an error code unless the input is ambiguous, but it does not explain what constitutes an ambiguous input. Frankly, I can't think of any and in my opinion TRY/S_FMT should never return an error other than EINVAL (if the buffer type is unsupported) or EBUSY (for S_FMT if streaming is in progress). Returning an error for any other reason doesn't help the application since the app will have no way of knowing what to do next. Ack on not returning an error for requesting an unavailable format. As for what the driver should do (default versus current format) I've no preference, I vote for letting this be decided by the driver implementation. That's exactly the point that I wanted to clarify :-) I don't see a good reason to let the driver decide on this, and would prefer returning a default format I see. as TRY_FMT would then always return the same result for a given input format regardless of the currently selected format. That argument makes sense, so ack from me on always returning a default format. Regards, Hans -- 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
Re: [Workshop-2011] RFC: V4L2 API ambiguities
On Tue August 14 2012 01:54:16 Laurent Pinchart wrote: Hi Hans, On Monday 13 August 2012 14:27:56 Hans Verkuil wrote: Hi all! As part of the 2012 Kernel Summit V4L2 workshop I will be discussing a bunch of V4L2 ambiguities/improvements. I've made a list of all the V4L2 issues and put them in two categories: issues that I think are easy to resolve (within a few minutes at most), and those that are harder. If you think I put something in the easy category that you believe is actually hard, then please let me know. If you attend the workshop, then please read through this and think about it a bit, particularly for the second category. If something is unclear, or you think another topic should be added, then let me know as well. Easy: [snip] 4) What should a driver return in TRY_FMT/S_FMT if the requested format is not supported (possible behaviours include returning the currently selected format or a default format). The spec says this: Drivers should not return an error code unless the input is ambiguous, but it does not explain what constitutes an ambiguous input. Frankly, I can't think of any and in my opinion TRY/S_FMT should never return an error other than EINVAL (if the buffer type is unsupported) or EBUSY (for S_FMT if streaming is in progress). Returning an error for any other reason doesn't help the application since the app will have no way of knowing what to do next. That wasn't my point. Drivers should obviously not return an error. Let's consider the case of a driver supporting YUYV and MJPEG. If the user calls TRY_FMT or S_FMT with the pixel format set to RGB565, should the driver return a hardcoded default format (one of YUYV or MJPEG), or the currently selected format ? In other words, should the pixel format returned by TRY_FMT or S_FMT when the requested pixel format is not valid be a fixed default pixel format, or should it depend on the currently selected pixel format ? Actually, in this case I would probably choose a YUYV format that is closest to the requested size. If a driver supports both compressed and uncompressed formats, then it should only select a compressed format if the application explicitly asked for it. Handling compressed formats is more complex than uncompressed formats, so that seems a sensible rule. The next heuristic I would apply is to choose a format that is closest to the requested size. So I guess my guidelines would be: 1) If the pixelformat is not supported, then choose an uncompressed format (if possible) instead. 2) Next choose a format closest to, but smaller than (if possible) the requested size. But this would be a guideline only, and in the end it should be up to the driver. Just as long TRY/S_FMT always returns a format. Regards, Hans -- 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
Re: [Workshop-2011] RFC: V4L2 API ambiguities
Hi Hans, On Tuesday 14 August 2012 12:54:34 Hans Verkuil wrote: On Tue August 14 2012 01:54:16 Laurent Pinchart wrote: On Monday 13 August 2012 14:27:56 Hans Verkuil wrote: Hi all! As part of the 2012 Kernel Summit V4L2 workshop I will be discussing a bunch of V4L2 ambiguities/improvements. I've made a list of all the V4L2 issues and put them in two categories: issues that I think are easy to resolve (within a few minutes at most), and those that are harder. If you think I put something in the easy category that you believe is actually hard, then please let me know. If you attend the workshop, then please read through this and think about it a bit, particularly for the second category. If something is unclear, or you think another topic should be added, then let me know as well. Easy: [snip] 4) What should a driver return in TRY_FMT/S_FMT if the requested format is not supported (possible behaviours include returning the currently selected format or a default format). The spec says this: Drivers should not return an error code unless the input is ambiguous, but it does not explain what constitutes an ambiguous input. Frankly, I can't think of any and in my opinion TRY/S_FMT should never return an error other than EINVAL (if the buffer type is unsupported)or EBUSY (for S_FMT if streaming is in progress). Returning an error for any other reason doesn't help the application since the app will have no way of knowing what to do next. That wasn't my point. Drivers should obviously not return an error. Let's consider the case of a driver supporting YUYV and MJPEG. If the user calls TRY_FMT or S_FMT with the pixel format set to RGB565, should the driver return a hardcoded default format (one of YUYV or MJPEG), or the currently selected format ? In other words, should the pixel format returned by TRY_FMT or S_FMT when the requested pixel format is not valid be a fixed default pixel format, or should it depend on the currently selected pixel format ? Actually, in this case I would probably choose a YUYV format that is closest to the requested size. If a driver supports both compressed and uncompressed formats, then it should only select a compressed format if the application explicitly asked for it. Handling compressed formats is more complex than uncompressed formats, so that seems a sensible rule. That wasn't my point either :-) YUYV/MJPEG was just an example. You can replace MJPEG with UYVY or NV12 above. What I want to know is whether TRY_FMT and S_FMT must, when given a non-supported format, return a fixed supported format or return a supported format that can depend on the currently selected format. The next heuristic I would apply is to choose a format that is closest to the requested size. So I guess my guidelines would be: 1) If the pixelformat is not supported, then choose an uncompressed format (if possible) instead. 2) Next choose a format closest to, but smaller than (if possible) the requested size. But this would be a guideline only, and in the end it should be up to the driver. Just as long TRY/S_FMT always returns a format. -- Regards, Laurent Pinchart -- 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
Re: [Workshop-2011] RFC: V4L2 API ambiguities
On Tue August 14 2012 13:06:46 Laurent Pinchart wrote: Hi Hans, On Tuesday 14 August 2012 12:54:34 Hans Verkuil wrote: On Tue August 14 2012 01:54:16 Laurent Pinchart wrote: On Monday 13 August 2012 14:27:56 Hans Verkuil wrote: Hi all! As part of the 2012 Kernel Summit V4L2 workshop I will be discussing a bunch of V4L2 ambiguities/improvements. I've made a list of all the V4L2 issues and put them in two categories: issues that I think are easy to resolve (within a few minutes at most), and those that are harder. If you think I put something in the easy category that you believe is actually hard, then please let me know. If you attend the workshop, then please read through this and think about it a bit, particularly for the second category. If something is unclear, or you think another topic should be added, then let me know as well. Easy: [snip] 4) What should a driver return in TRY_FMT/S_FMT if the requested format is not supported (possible behaviours include returning the currently selected format or a default format). The spec says this: Drivers should not return an error code unless the input is ambiguous, but it does not explain what constitutes an ambiguous input. Frankly, I can't think of any and in my opinion TRY/S_FMT should never return an error other than EINVAL (if the buffer type is unsupported)or EBUSY (for S_FMT if streaming is in progress). Returning an error for any other reason doesn't help the application since the app will have no way of knowing what to do next. That wasn't my point. Drivers should obviously not return an error. Let's consider the case of a driver supporting YUYV and MJPEG. If the user calls TRY_FMT or S_FMT with the pixel format set to RGB565, should the driver return a hardcoded default format (one of YUYV or MJPEG), or the currently selected format ? In other words, should the pixel format returned by TRY_FMT or S_FMT when the requested pixel format is not valid be a fixed default pixel format, or should it depend on the currently selected pixel format ? Actually, in this case I would probably choose a YUYV format that is closest to the requested size. If a driver supports both compressed and uncompressed formats, then it should only select a compressed format if the application explicitly asked for it. Handling compressed formats is more complex than uncompressed formats, so that seems a sensible rule. That wasn't my point either :-) YUYV/MJPEG was just an example. You can replace MJPEG with UYVY or NV12 above. What I want to know is whether TRY_FMT and S_FMT must, when given a non-supported format, return a fixed supported format or return a supported format that can depend on the currently selected format. The next heuristic I would apply is to choose a format that is closest to the requested size. So I guess my guidelines would be: 1) If the pixelformat is not supported, then choose an uncompressed format (if possible) instead. 2) Next choose a format closest to, but smaller than (if possible) the requested size. But this would be a guideline only, and in the end it should be up to the driver. Just as long TRY/S_FMT always returns a format. Well, the currently selected format is irrelevant. The user is obviously requesting something else and the driver should attempt to return something that is at least somewhat close to what it requested. If that's impossible, then falling back to some default format is a good choice. Does that answer the question? Regards, Hans -- 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
Re: [Workshop-2011] RFC: V4L2 API ambiguities
Hi Hans, On Tuesday 14 August 2012 13:11:49 Hans Verkuil wrote: On Tue August 14 2012 13:06:46 Laurent Pinchart wrote: On Tuesday 14 August 2012 12:54:34 Hans Verkuil wrote: On Tue August 14 2012 01:54:16 Laurent Pinchart wrote: On Monday 13 August 2012 14:27:56 Hans Verkuil wrote: [snip] 4) What should a driver return in TRY_FMT/S_FMT if the requested format is not supported (possible behaviours include returning the currently selected format or a default format). The spec says this: Drivers should not return an error code unless the input is ambiguous, but it does not explain what constitutes an ambiguous input. Frankly, I can't think of any and in my opinion TRY/S_FMT should never return an error other than EINVAL (if the buffer type is unsupported)or EBUSY (for S_FMT if streaming is in progress). Returning an error for any other reason doesn't help the application since the app will have no way of knowing what to do next. That wasn't my point. Drivers should obviously not return an error. Let's consider the case of a driver supporting YUYV and MJPEG. If the user calls TRY_FMT or S_FMT with the pixel format set to RGB565, should the driver return a hardcoded default format (one of YUYV or MJPEG), or the currently selected format ? In other words, should the pixel format returned by TRY_FMT or S_FMT when the requested pixel format is not valid be a fixed default pixel format, or should it depend on the currently selected pixel format ? Actually, in this case I would probably choose a YUYV format that is closest to the requested size. If a driver supports both compressed and uncompressed formats, then it should only select a compressed format if the application explicitly asked for it. Handling compressed formats is more complex than uncompressed formats, so that seems a sensible rule. That wasn't my point either :-) YUYV/MJPEG was just an example. You can replace MJPEG with UYVY or NV12 above. What I want to know is whether TRY_FMT and S_FMT must, when given a non-supported format, return a fixed supported format or return a supported format that can depend on the currently selected format. The next heuristic I would apply is to choose a format that is closest to the requested size. So I guess my guidelines would be: 1) If the pixelformat is not supported, then choose an uncompressed format (if possible) instead. 2) Next choose a format closest to, but smaller than (if possible) the requested size. But this would be a guideline only, and in the end it should be up to the driver. Just as long TRY/S_FMT always returns a format. Well, the currently selected format is irrelevant. The user is obviously requesting something else and the driver should attempt to return something that is at least somewhat close to what it requested. If that's impossible, then falling back to some default format is a good choice. Does that answer the question? Yes it does, and I agree with that. Some drivers return the currently selected format when a non-supported format is requested. I think the spec should be clarified to make it mandatory to return a fixed default format independent of the currently selected format, and non-compliant drivers should be fixed. -- Regards, Laurent Pinchart -- 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
Re: [Workshop-2011] RFC: V4L2 API ambiguities
On Tue August 14 2012 13:15:21 Laurent Pinchart wrote: Hi Hans, On Tuesday 14 August 2012 13:11:49 Hans Verkuil wrote: On Tue August 14 2012 13:06:46 Laurent Pinchart wrote: On Tuesday 14 August 2012 12:54:34 Hans Verkuil wrote: On Tue August 14 2012 01:54:16 Laurent Pinchart wrote: On Monday 13 August 2012 14:27:56 Hans Verkuil wrote: [snip] 4) What should a driver return in TRY_FMT/S_FMT if the requested format is not supported (possible behaviours include returning the currently selected format or a default format). The spec says this: Drivers should not return an error code unless the input is ambiguous, but it does not explain what constitutes an ambiguous input. Frankly, I can't think of any and in my opinion TRY/S_FMT should never return an error other than EINVAL (if the buffer type is unsupported)or EBUSY (for S_FMT if streaming is in progress). Returning an error for any other reason doesn't help the application since the app will have no way of knowing what to do next. That wasn't my point. Drivers should obviously not return an error. Let's consider the case of a driver supporting YUYV and MJPEG. If the user calls TRY_FMT or S_FMT with the pixel format set to RGB565, should the driver return a hardcoded default format (one of YUYV or MJPEG), or the currently selected format ? In other words, should the pixel format returned by TRY_FMT or S_FMT when the requested pixel format is not valid be a fixed default pixel format, or should it depend on the currently selected pixel format ? Actually, in this case I would probably choose a YUYV format that is closest to the requested size. If a driver supports both compressed and uncompressed formats, then it should only select a compressed format if the application explicitly asked for it. Handling compressed formats is more complex than uncompressed formats, so that seems a sensible rule. That wasn't my point either :-) YUYV/MJPEG was just an example. You can replace MJPEG with UYVY or NV12 above. What I want to know is whether TRY_FMT and S_FMT must, when given a non-supported format, return a fixed supported format or return a supported format that can depend on the currently selected format. The next heuristic I would apply is to choose a format that is closest to the requested size. So I guess my guidelines would be: 1) If the pixelformat is not supported, then choose an uncompressed format (if possible) instead. 2) Next choose a format closest to, but smaller than (if possible) the requested size. But this would be a guideline only, and in the end it should be up to the driver. Just as long TRY/S_FMT always returns a format. Well, the currently selected format is irrelevant. The user is obviously requesting something else and the driver should attempt to return something that is at least somewhat close to what it requested. If that's impossible, then falling back to some default format is a good choice. Does that answer the question? Yes it does, and I agree with that. Some drivers return the currently selected format when a non-supported format is requested. I think the spec should be clarified to make it mandatory to return a fixed default format independent of the currently selected format, and non-compliant drivers should be fixed. I don't know whether it should be mandated. In the end it doesn't matter to the application: that just wants to get some format that is valid. It's a good recommendation for drivers, but I do not think that there is anything wrong as such with drivers that return the current format. Am I missing something here? Is there any particular advantage of returning a default fallback format from the point of view of an application? Regards, Hans -- 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
Re: [Workshop-2011] RFC: V4L2 API ambiguities
On Tuesday 14 August 2012 13:32:43 Hans Verkuil wrote: On Tue August 14 2012 13:15:21 Laurent Pinchart wrote: On Tuesday 14 August 2012 13:11:49 Hans Verkuil wrote: On Tue August 14 2012 13:06:46 Laurent Pinchart wrote: On Tuesday 14 August 2012 12:54:34 Hans Verkuil wrote: On Tue August 14 2012 01:54:16 Laurent Pinchart wrote: On Monday 13 August 2012 14:27:56 Hans Verkuil wrote: [snip] 4) What should a driver return in TRY_FMT/S_FMT if the requested format is not supported (possible behaviours include returning the currently selected format or a default format). The spec says this: Drivers should not return an error code unless the input is ambiguous, but it does not explain what constitutes an ambiguous input. Frankly, I can't think of any and in my opinion TRY/S_FMT should never return an error other than EINVAL (if the buffer type is unsupported)or EBUSY (for S_FMT if streaming is in progress). Returning an error for any other reason doesn't help the application since the app will have no way of knowing what to do next. That wasn't my point. Drivers should obviously not return an error. Let's consider the case of a driver supporting YUYV and MJPEG. If the user calls TRY_FMT or S_FMT with the pixel format set to RGB565, should the driver return a hardcoded default format (one of YUYV or MJPEG), or the currently selected format ? In other words, should the pixel format returned by TRY_FMT or S_FMT when the requested pixel format is not valid be a fixed default pixel format, or should it depend on the currently selected pixel format ? Actually, in this case I would probably choose a YUYV format that is closest to the requested size. If a driver supports both compressed and uncompressed formats, then it should only select a compressed format if the application explicitly asked for it. Handling compressed formats is more complex than uncompressed formats, so that seems a sensible rule. That wasn't my point either :-) YUYV/MJPEG was just an example. You can replace MJPEG with UYVY or NV12 above. What I want to know is whether TRY_FMT and S_FMT must, when given a non-supported format, return a fixed supported format or return a supported format that can depend on the currently selected format. The next heuristic I would apply is to choose a format that is closest to the requested size. So I guess my guidelines would be: 1) If the pixelformat is not supported, then choose an uncompressed format (if possible) instead. 2) Next choose a format closest to, but smaller than (if possible) the requested size. But this would be a guideline only, and in the end it should be up to the driver. Just as long TRY/S_FMT always returns a format. Well, the currently selected format is irrelevant. The user is obviously requesting something else and the driver should attempt to return something that is at least somewhat close to what it requested. If that's impossible, then falling back to some default format is a good choice. Does that answer the question? Yes it does, and I agree with that. Some drivers return the currently selected format when a non-supported format is requested. I think the spec should be clarified to make it mandatory to return a fixed default format independent of the currently selected format, and non-compliant drivers should be fixed. I don't know whether it should be mandated. In the end it doesn't matter to the application: that just wants to get some format that is valid. It's a good recommendation for drivers, but I do not think that there is anything wrong as such with drivers that return the current format. Am I missing something here? Is there any particular advantage of returning a default fallback format from the point of view of an application? Mostly consistency. I find returning different results for TRY_FMT calls with the exact same parameters confusing, both for applications and users. -- Regards, Laurent Pinchart -- 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
Re: [Workshop-2011] RFC: V4L2 API ambiguities
Hi, On 08/14/2012 12:54 PM, Hans Verkuil wrote: On Tue August 14 2012 01:54:16 Laurent Pinchart wrote: Hi Hans, On Monday 13 August 2012 14:27:56 Hans Verkuil wrote: Hi all! As part of the 2012 Kernel Summit V4L2 workshop I will be discussing a bunch of V4L2 ambiguities/improvements. I've made a list of all the V4L2 issues and put them in two categories: issues that I think are easy to resolve (within a few minutes at most), and those that are harder. If you think I put something in the easy category that you believe is actually hard, then please let me know. If you attend the workshop, then please read through this and think about it a bit, particularly for the second category. If something is unclear, or you think another topic should be added, then let me know as well. Easy: [snip] 4) What should a driver return in TRY_FMT/S_FMT if the requested format is not supported (possible behaviours include returning the currently selected format or a default format). The spec says this: Drivers should not return an error code unless the input is ambiguous, but it does not explain what constitutes an ambiguous input. Frankly, I can't think of any and in my opinion TRY/S_FMT should never return an error other than EINVAL (if the buffer type is unsupported) or EBUSY (for S_FMT if streaming is in progress). Returning an error for any other reason doesn't help the application since the app will have no way of knowing what to do next. That wasn't my point. Drivers should obviously not return an error. Let's consider the case of a driver supporting YUYV and MJPEG. If the user calls TRY_FMT or S_FMT with the pixel format set to RGB565, should the driver return a hardcoded default format (one of YUYV or MJPEG), or the currently selected format ? In other words, should the pixel format returned by TRY_FMT or S_FMT when the requested pixel format is not valid be a fixed default pixel format, or should it depend on the currently selected pixel format ? Actually, in this case I would probably choose a YUYV format that is closest to the requested size. If a driver supports both compressed and uncompressed formats, then it should only select a compressed format if the application explicitly asked for it. Handling compressed formats is more complex than uncompressed formats, so that seems a sensible rule. The next heuristic I would apply is to choose a format that is closest to the requested size. Size as in resolution or size as in bpp? So I guess my guidelines would be: 1) If the pixelformat is not supported, then choose an uncompressed format (if possible) instead. 2) Next choose a format closest to, but smaller than (if possible) the requested size. But this would be a guideline only, and in the end it should be up to the driver. Just as long TRY/S_FMT always returns a format. I think we're making this way too complicated. I agree that TRY/S_FMT should always returns a format and not EINVAL, but other then that lets just document that if the driver does not know the passed in format it should return a default format and not make this dependent on the passed in fmt, esp. since otherwise the driver would need to know about all formats it does not support to best map that to a one which it does support, which is just crazy. So I suggest adding the following to the spec: When a driver receives an unsupported pixfmt as input on a TRY/S_FMT call it should replace this with a default pixfmt, independent of input pixfmt and current driver state. Preferably a driver uses a well known uncompressed pixfmt as its default. Regards, Hans -- 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
Re: [Workshop-2011] RFC: V4L2 API ambiguities
On Tue, Aug 14, 2012 at 6:13 PM, Hans de Goede hdego...@redhat.com wrote: Hi, On 08/14/2012 12:54 PM, Hans Verkuil wrote: On Tue August 14 2012 01:54:16 Laurent Pinchart wrote: Hi Hans, On Monday 13 August 2012 14:27:56 Hans Verkuil wrote: Hi all! As part of the 2012 Kernel Summit V4L2 workshop I will be discussing a bunch of V4L2 ambiguities/improvements. I've made a list of all the V4L2 issues and put them in two categories: issues that I think are easy to resolve (within a few minutes at most), and those that are harder. If you think I put something in the easy category that you believe is actually hard, then please let me know. If you attend the workshop, then please read through this and think about it a bit, particularly for the second category. If something is unclear, or you think another topic should be added, then let me know as well. Easy: [snip] 4) What should a driver return in TRY_FMT/S_FMT if the requested format is not supported (possible behaviours include returning the currently selected format or a default format). The spec says this: Drivers should not return an error code unless the input is ambiguous, but it does not explain what constitutes an ambiguous input. Frankly, I can't think of any and in my opinion TRY/S_FMT should never return an error other than EINVAL (if the buffer type is unsupported) or EBUSY (for S_FMT if streaming is in progress). Returning an error for any other reason doesn't help the application since the app will have no way of knowing what to do next. That wasn't my point. Drivers should obviously not return an error. Let's consider the case of a driver supporting YUYV and MJPEG. If the user calls TRY_FMT or S_FMT with the pixel format set to RGB565, should the driver return a hardcoded default format (one of YUYV or MJPEG), or the currently selected format ? In other words, should the pixel format returned by TRY_FMT or S_FMT when the requested pixel format is not valid be a fixed default pixel format, or should it depend on the currently selected pixel format ? Actually, in this case I would probably choose a YUYV format that is closest to the requested size. If a driver supports both compressed and uncompressed formats, then it should only select a compressed format if the application explicitly asked for it. Handling compressed formats is more complex than uncompressed formats, so that seems a sensible rule. The next heuristic I would apply is to choose a format that is closest to the requested size. Size as in resolution or size as in bpp? So I guess my guidelines would be: 1) If the pixelformat is not supported, then choose an uncompressed format (if possible) instead. 2) Next choose a format closest to, but smaller than (if possible) the requested size. But this would be a guideline only, and in the end it should be up to the driver. Just as long TRY/S_FMT always returns a format. I think we're making this way too complicated. I agree that TRY/S_FMT should always returns a format and not EINVAL, but other then that lets just document that if the driver does not know the passed in format it should return a default format and not make this dependent on the passed in fmt, esp. since otherwise the driver would need to know about all formats it does not support to best map that to a one which it does support, which is just crazy. So I suggest adding the following to the spec: When a driver receives an unsupported pixfmt as input on a TRY/S_FMT call it should replace this with a default pixfmt, independent of input pixfmt and current driver state. Preferably a driver uses a well known uncompressed pixfmt as its default. Regards, Hans -- 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 Consistent results for TRY_FMT calls with the exact same parameters seems proper from an application's perspective. One reason why anyone would want the driver to return the current format would be if there is some penalty associated with switching formats in the driver/hardware. Currently, if one expects to avoid such a penalty, one can always explicitly code for that in the application by calling G_FMT rather than solely depending on the result of TRY_FMT. regards CVS -- 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
Re: [Workshop-2011] RFC: V4L2 API ambiguities
On Tue, 14 Aug 2012, Laurent Pinchart wrote: On Tuesday 14 August 2012 13:32:43 Hans Verkuil wrote: On Tue August 14 2012 13:15:21 Laurent Pinchart wrote: On Tuesday 14 August 2012 13:11:49 Hans Verkuil wrote: On Tue August 14 2012 13:06:46 Laurent Pinchart wrote: On Tuesday 14 August 2012 12:54:34 Hans Verkuil wrote: On Tue August 14 2012 01:54:16 Laurent Pinchart wrote: On Monday 13 August 2012 14:27:56 Hans Verkuil wrote: [snip] 4) What should a driver return in TRY_FMT/S_FMT if the requested format is not supported (possible behaviours include returning the currently selected format or a default format). The spec says this: Drivers should not return an error code unless the input is ambiguous, but it does not explain what constitutes an ambiguous input. Frankly, I can't think of any and in my opinion TRY/S_FMT should never return an error other than EINVAL (if the buffer type is unsupported)or EBUSY (for S_FMT if streaming is in progress). Returning an error for any other reason doesn't help the application since the app will have no way of knowing what to do next. That wasn't my point. Drivers should obviously not return an error. Let's consider the case of a driver supporting YUYV and MJPEG. If the user calls TRY_FMT or S_FMT with the pixel format set to RGB565, should the driver return a hardcoded default format (one of YUYV or MJPEG), or the currently selected format ? In other words, should the pixel format returned by TRY_FMT or S_FMT when the requested pixel format is not valid be a fixed default pixel format, or should it depend on the currently selected pixel format ? Actually, in this case I would probably choose a YUYV format that is closest to the requested size. If a driver supports both compressed and uncompressed formats, then it should only select a compressed format if the application explicitly asked for it. Handling compressed formats is more complex than uncompressed formats, so that seems a sensible rule. That wasn't my point either :-) YUYV/MJPEG was just an example. You can replace MJPEG with UYVY or NV12 above. What I want to know is whether TRY_FMT and S_FMT must, when given a non-supported format, return a fixed supported format or return a supported format that can depend on the currently selected format. The next heuristic I would apply is to choose a format that is closest to the requested size. So I guess my guidelines would be: 1) If the pixelformat is not supported, then choose an uncompressed format (if possible) instead. 2) Next choose a format closest to, but smaller than (if possible) the requested size. But this would be a guideline only, and in the end it should be up to the driver. Just as long TRY/S_FMT always returns a format. Well, the currently selected format is irrelevant. The user is obviously requesting something else and the driver should attempt to return something that is at least somewhat close to what it requested. If that's impossible, then falling back to some default format is a good choice. Does that answer the question? Yes it does, and I agree with that. Some drivers return the currently selected format when a non-supported format is requested. I think the spec should be clarified to make it mandatory to return a fixed default format independent of the currently selected format, and non-compliant drivers should be fixed. I don't know whether it should be mandated. In the end it doesn't matter to the application: that just wants to get some format that is valid. It's a good recommendation for drivers, but I do not think that there is anything wrong as such with drivers that return the current format. Am I missing something here? Is there any particular advantage of returning a default fallback format from the point of view of an application? Mostly consistency. I find returning different results for TRY_FMT calls with the exact same parameters confusing, both for applications and users. We've discussed this issue privately with Laurent before, and my opinion was rather to go with the currently configured format. The advantage of this would be, that situations, when a user has configured some format and then is trying to switch to an unsupported format, and instead the driver switches to a 3rd format, instead of keeping the current one, would be avoided. OTOH, it seems a good idea to whenever possible return the same result in reply to the same request, in this case to TRY_FMT. And it also seems logical to have S_FMT do the same thing as TRY_FMT... So, this argument seems stronger
Re: [Workshop-2011] RFC: V4L2 API ambiguities
Hi Guennadi, On Tuesday 14 August 2012 23:14:18 Guennadi Liakhovetski wrote: On Tue, 14 Aug 2012, Laurent Pinchart wrote: On Tuesday 14 August 2012 13:32:43 Hans Verkuil wrote: On Tue August 14 2012 13:15:21 Laurent Pinchart wrote: On Tuesday 14 August 2012 13:11:49 Hans Verkuil wrote: On Tue August 14 2012 13:06:46 Laurent Pinchart wrote: On Tuesday 14 August 2012 12:54:34 Hans Verkuil wrote: On Tue August 14 2012 01:54:16 Laurent Pinchart wrote: On Monday 13 August 2012 14:27:56 Hans Verkuil wrote: [snip] 4) What should a driver return in TRY_FMT/S_FMT if the requested format is not supported (possible behaviours include returning the currently selected format or a default format). The spec says this: Drivers should not return an error code unless the input is ambiguous, but it does not explain what constitutes an ambiguous input. Frankly, I can't think of any and in my opinion TRY/S_FMT should never return an error other than EINVAL (if the buffer type is unsupported)or EBUSY (for S_FMT if streaming is in progress). Returning an error for any other reason doesn't help the application since the app will have no way of knowing what to do next. That wasn't my point. Drivers should obviously not return an error. Let's consider the case of a driver supporting YUYV and MJPEG. If the user calls TRY_FMT or S_FMT with the pixel format set to RGB565, should the driver return a hardcoded default format (one of YUYV or MJPEG), or the currently selected format ? In other words, should the pixel format returned by TRY_FMT or S_FMT when the requested pixel format is not valid be a fixed default pixel format, or should it depend on the currently selected pixel format ? Actually, in this case I would probably choose a YUYV format that is closest to the requested size. If a driver supports both compressed and uncompressed formats, then it should only select a compressed format if the application explicitly asked for it. Handling compressed formats is more complex than uncompressed formats, so that seems a sensible rule. That wasn't my point either :-) YUYV/MJPEG was just an example. You can replace MJPEG with UYVY or NV12 above. What I want to know is whether TRY_FMT and S_FMT must, when given a non-supported format, return a fixed supported format or return a supported format that can depend on the currently selected format. The next heuristic I would apply is to choose a format that is closest to the requested size. So I guess my guidelines would be: 1) If the pixelformat is not supported, then choose an uncompressed format (if possible) instead. 2) Next choose a format closest to, but smaller than (if possible) the requested size. But this would be a guideline only, and in the end it should be up to the driver. Just as long TRY/S_FMT always returns a format. Well, the currently selected format is irrelevant. The user is obviously requesting something else and the driver should attempt to return something that is at least somewhat close to what it requested. If that's impossible, then falling back to some default format is a good choice. Does that answer the question? Yes it does, and I agree with that. Some drivers return the currently selected format when a non-supported format is requested. I think the spec should be clarified to make it mandatory to return a fixed default format independent of the currently selected format, and non- compliant drivers should be fixed. I don't know whether it should be mandated. In the end it doesn't matter to the application: that just wants to get some format that is valid. It's a good recommendation for drivers, but I do not think that there is anything wrong as such with drivers that return the current format. Am I missing something here? Is there any particular advantage of returning a default fallback format from the point of view of an application? Mostly consistency. I find returning different results for TRY_FMT calls with the exact same parameters confusing, both for applications and users. We've discussed this issue privately with Laurent before, and my opinion was rather to go with the currently configured format. The advantage of this would be, that situations, when a user has configured some format and then is trying to switch to an unsupported format, and instead the driver switches to a 3rd format, instead of keeping the current one, would be avoided. OTOH, it seems a good idea to whenever possible
RFC: V4L2 API ambiguities
Hi all! As part of the 2012 Kernel Summit V4L2 workshop I will be discussing a bunch of V4L2 ambiguities/improvements. I've made a list of all the V4L2 issues and put them in two categories: issues that I think are easy to resolve (within a few minutes at most), and those that are harder. If you think I put something in the easy category that you believe is actually hard, then please let me know. If you attend the workshop, then please read through this and think about it a bit, particularly for the second category. If something is unclear, or you think another topic should be added, then let me know as well. Regards, Hans Easy: 1) Split off the control part from videodev2.h. Controls are almost 30% of videodev2.h. I think maintaining controls would be easier if they are moved to e.g. linux/v4l2-controls.h which is included by videodev2.h. 2) Currently there are three types of controls: standard controls, controls that are specific to a chipset (e.g. cx2341x, mfc51) and driver-specific controls. The controls of the first two types have well defined and unique IDs. For driver-specific controls however there are no clear rules. It all depends on one question: should driver-specific controls have a unique control ID as well, or can they overlap with other drivers? If the answer is that they should be unique as well, then all driver-specific controls will have to be defined in a single header so you can be certain that there is no overlap. If the answer is that they may overlap, then each driver can either define their controls inside their own driver, or in a driver-specific public header. In both cases a control ID range has to be defined for such controls, to ensure that they never clash with standard or chipset-specific control IDs. E.g. = V4L2_CTRL_CLASS_XXX + 0x8000 (no overlap) or + 0xf000 (overlap allowed). My preference is to allow overlap. 3) What should VIDIOC_STREAMON/OFF do if the stream is already started/stopped? I believe they should do nothing and just return 0. The main reason for that is it can be useful if an application can just call VIDIOC_STREAMOFF without having to check whether streaming is in progress. 4) What should a driver return in TRY_FMT/S_FMT if the requested format is not supported (possible behaviours include returning the currently selected format or a default format). The spec says this: Drivers should not return an error code unless the input is ambiguous, but it does not explain what constitutes an ambiguous input. Frankly, I can't think of any and in my opinion TRY/S_FMT should never return an error other than EINVAL (if the buffer type is unsupported) or EBUSY (for S_FMT if streaming is in progress). Returning an error for any other reason doesn't help the application since the app will have no way of knowing what to do next. 5) VIDIOC_QUERYCAP allows bus_info to be empty. Since the purpose of bus_info is to distinguish multiple identical devices this makes no sense. I propose to make the spec more strict and require that bus_info is always filled in with a unique string. 6) Deprecate V4L2_BUF_TYPE_PRIVATE. None of the kernel drivers use it, and I cannot see any good use-case for this. If some new type of buffer is needed, then that should be added instead of allowing someone to abuse this buffer type. 7) A driver that has both a video node and a vbi node (for example) that uses the same struct v4l2_ioctl_ops for both nodes will have to check in e.g. vidioc_g_fmt_vid_cap or vidioc_g_fmt_vbi_cap whether it is called from the correct node (video or vbi) and return an error if it isn't. That's an annoying test that can be done in the V4L2 core as well. Especially since few drivers actually test for that. Should such checks be added to the V4L2 core? And if so, should we add some additional VFL types? Currently we have GRABBER (video nodes), VBI, RADIO and SUBDEV. But if we want to do proper core checks, then we would also need OUTPUT, VBI_OUT and M2M. 8) Remove the experimental tag from the following old drivers: VIDEO_TLV320AIC23B USB_STKWEBCAM VIDEO_CX18 VIDEO_CX18_ALSA VIDEO_ZORAN_AVS6EYES DVB_USB_AF9005 MEDIA_TUNER_TEA5761 Removing this tag from these drivers might be too soon, though: VIDEO_NOON010PC30 VIDEO_OMAP3 9) What should VIDIOC_G_STD/DV_PRESET/DV_TIMINGS return if the current input or output does not support that particular timing approach? EINVAL? ENODATA? This is relevant for the case where a driver has multiple inputs/outputs where some are SDTV (and support the STD API) and others are HDTV (and support the DV_TIMINGS API). I propose ENODATA. 10) Proposal: add these defines: #define V4L2_IN_CAP_TIMINGS V4L2_IN_CAP_CUSTOM_TIMINGS #define V4L2_OUT_CAP_TIMINGS V4L2_OUT_CAP_CUSTOM_TIMINGS Since
Re: [Workshop-2011] RFC: V4L2 API ambiguities
Hi, snip Easy: 1) Split off the control part from videodev2.h. Controls are almost 30% of videodev2.h. I think maintaining controls would be easier if they are moved to e.g. linux/v4l2-controls.h which is included by videodev2.h. Ack. 2) Currently there are three types of controls: standard controls, controls that are specific to a chipset (e.g. cx2341x, mfc51) and driver-specific controls. The controls of the first two types have well defined and unique IDs. For driver-specific controls however there are no clear rules. It all depends on one question: should driver-specific controls have a unique control ID as well, or can they overlap with other drivers? If the answer is that they should be unique as well, then all driver-specific controls will have to be defined in a single header so you can be certain that there is no overlap. If the answer is that they may overlap, then each driver can either define their controls inside their own driver, or in a driver-specific public header. In both cases a control ID range has to be defined for such controls, to ensure that they never clash with standard or chipset-specific control IDs. E.g. = V4L2_CTRL_CLASS_XXX + 0x8000 (no overlap) or + 0xf000 (overlap allowed). My preference is to allow overlap. +1 for allowing overlap, and only when it is expected that some special app will actually use the device specific controls (versus the user changing them in a generic v4l2 control panel app), then the private controls should be defined in a public header. If no such special app is expected, the private controls should be defined inside a private header of the driver. 3) What should VIDIOC_STREAMON/OFF do if the stream is already started/stopped? I believe they should do nothing and just return 0. The main reason for that is it can be useful if an application can just call VIDIOC_STREAMOFF without having to check whether streaming is in progress. +1 for just returning 0 4) What should a driver return in TRY_FMT/S_FMT if the requested format is not supported (possible behaviours include returning the currently selected format or a default format). The spec says this: Drivers should not return an error code unless the input is ambiguous, but it does not explain what constitutes an ambiguous input. Frankly, I can't think of any and in my opinion TRY/S_FMT should never return an error other than EINVAL (if the buffer type is unsupported) or EBUSY (for S_FMT if streaming is in progress). Returning an error for any other reason doesn't help the application since the app will have no way of knowing what to do next. Ack on not returning an error for requesting an unavailable format. As for what the driver should do (default versus current format) I've no preference, I vote for letting this be decided by the driver implementation. 5) VIDIOC_QUERYCAP allows bus_info to be empty. Since the purpose of bus_info is to distinguish multiple identical devices this makes no sense. I propose to make the spec more strict and require that bus_info is always filled in with a unique string. Ack. 6) Deprecate V4L2_BUF_TYPE_PRIVATE. None of the kernel drivers use it, and I cannot see any good use-case for this. If some new type of buffer is needed, then that should be added instead of allowing someone to abuse this buffer type. Ack. 7) A driver that has both a video node and a vbi node (for example) that uses the same struct v4l2_ioctl_ops for both nodes will have to check in e.g. vidioc_g_fmt_vid_cap or vidioc_g_fmt_vbi_cap whether it is called from the correct node (video or vbi) and return an error if it isn't. That's an annoying test that can be done in the V4L2 core as well. Especially since few drivers actually test for that. Should such checks be added to the V4L2 core? And if so, should we add some additional VFL types? Currently we have GRABBER (video nodes), VBI, RADIO and SUBDEV. But if we want to do proper core checks, then we would also need OUTPUT, VBI_OUT and M2M. I'm in favor of adding checks to the core. 8) Remove the experimental tag from the following old drivers: VIDEO_TLV320AIC23B USB_STKWEBCAM VIDEO_CX18 VIDEO_CX18_ALSA VIDEO_ZORAN_AVS6EYES DVB_USB_AF9005 MEDIA_TUNER_TEA5761 ACK. Removing this tag from these drivers might be too soon, though: VIDEO_NOON010PC30 VIDEO_OMAP3 I've no opinion on these. 9) What should VIDIOC_G_STD/DV_PRESET/DV_TIMINGS return if the current input or output does not support that particular timing approach? EINVAL? ENODATA? This is relevant for the case where a driver has multiple inputs/outputs where some are SDTV (and support the STD API) and others are HDTV (and support the DV_TIMINGS API). I propose ENODATA.
Re: [Workshop-2011] RFC: V4L2 API ambiguities
On Mon August 13 2012 15:13:34 Hans de Goede wrote: Hi, snip 5) 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 change owner or return EBUSY if streaming is in progress. That won't work, as there is no such thing as streaming from a radio node, There is, actually: read() for RDS data and alsa streaming (although that might be hard to detect in the case of USB audio). I suggest we go with the simple approach we discussed at our last meeting in your Dutch House: Calling S_FREQ, S_TUNER, S_MODULATOR or S_HW_FREQ_SEEK will make an app the tuner-owner, and *closing* the device handle makes an app release its tuner ownership. If an other app already is the tuner owner -EBUSY is returned. So the ownership is associated with a filehandle? - Ditto for STREAMON, read/write and polling for read/write. No, streaming and tuning are 2 different things, if an app does both, it will likely tune before streaming, but in some cases a user may use a streaming only app together with say v4l2-ctl to do the actual tuning. I think keeping things simple here is key. Lets just treat the tuner and stream as 2 separate entities with a separate ownership. That would work provided the ownership is associated with a filehandle. - Ditto for ioctls that expect a valid tuner configuration like QUERYSTD. QUERY is a read only ioctl, so it should not be influenced by any ownership, nor imply ownership. It is definitely influenced by ownership, since if the tuner is in radio mode, then it can't detect a standard. Neither is this necessarily a passive call as some (mostly older) drivers need to switch the receiver to different modes in order to try and detect the current standard. - Just opening a device node should *not* switch ownership. Ack! 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. Ack. - 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. Right, G_TUNER should not change ownership, if the tuner is currently in radio mode and a G_TUNER is done on the video node just 0 out the fields which we cannot fill with useful info. - 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. +1 on delaying the mode switch until it is actually necessary to switch mode. - How about hybrid tuners? No opinion. Regards, Hans -- 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
Re: [Workshop-2011] RFC: V4L2 API ambiguities
Hi, On 08/13/2012 04:52 PM, Hans Verkuil wrote: On Mon August 13 2012 15:13:34 Hans de Goede wrote: Hi, snip 5) 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 change owner or return EBUSY if streaming is in progress. That won't work, as there is no such thing as streaming from a radio node, There is, actually: read() for RDS data and alsa streaming (although that might be hard to detect in the case of USB audio). I suggest we go with the simple approach we discussed at our last meeting in your Dutch House: Calling S_FREQ, S_TUNER, S_MODULATOR or S_HW_FREQ_SEEK will make an app the tuner-owner, and *closing* the device handle makes an app release its tuner ownership. If an other app already is the tuner owner -EBUSY is returned. So the ownership is associated with a filehandle? Yes, that is how it works for videobuf streams too, right? The only difference being that with videobuf streams there is an expilict way to release the ownership, where as for tuner ownership there is none, so the ownership is released on device close. - Ditto for STREAMON, read/write and polling for read/write. No, streaming and tuning are 2 different things, if an app does both, it will likely tune before streaming, but in some cases a user may use a streaming only app together with say v4l2-ctl to do the actual tuning. I think keeping things simple here is key. Lets just treat the tuner and stream as 2 separate entities with a separate ownership. That would work provided the ownership is associated with a filehandle. Right. - Ditto for ioctls that expect a valid tuner configuration like QUERYSTD. QUERY is a read only ioctl, so it should not be influenced by any ownership, nor imply ownership. It is definitely influenced by ownership, since if the tuner is in radio mode, then it can't detect a standard. Neither is this necessarily a passive call as some (mostly older) drivers need to switch the receiver to different modes in order to try and detect the current standard. Hmm, then I guess that this call should fail with EBUSY if: The tuner is owned by another app *and* 1) The tuner is in radio mode; or 2) The tuner is in tv mode *and* doing QUERYSTD requires prodding the device snip Regards, Hans -- 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
Re: [Workshop-2011] RFC: V4L2 API ambiguities
Hi, I've got one limitation for v4l2-mem2mem devices: a v4l2-mem2mem device driver which can't support *both* V4L2_BUF_TYPE_VIDEO_CAPTURE and V4L2_BUF_TYPE_VIDEO_CAPTURE_MPLANE capture buffers. AFAIK/U, this limitation is unjustified. So, with v4l2-mem2mem : 1. It's not possible to alternatively queue these capture buffers in the same v4l2-mem2mem instance (fd). 2. It's possible to have one v4l2-mem2mem instance for V4L2_BUF_TYPE_VIDEO_CAPTURE and another one (separate fd) for V4L2_BUF_TYPE_VIDEO_CAPTURE_MPLANE; but .. 3. In order to get 2., the driver has to call v4l2_m2m_ctx_init() in v4l2_ioctl_ops::vidioc_reqbufs(), not in v4l2_file_operations::open() - which is kind of 'OKay' 4. v4l2_m2m_ctx_init() take a callback function as an argument, which will be called to setup *both* the output and capture vb2 queue. 5. Still in order to get 2., the driver has to call vidioc_reqbufs() on the capture buffers first, then on the output buffers. If not, v4l2_m2m_ctx_init() will attempt to setup both output and capture queues, but still w/ incomplete information on the type of the capture queue, the userspace really wants. A solution would be to decouple the output and capture queues initialization in v4l2_m2m_ctx_init(). -Ilyes On Mon, Aug 13, 2012 at 2:13 PM, Hans de Goede hdego...@redhat.com wrote: Hi, snip Easy: 1) Split off the control part from videodev2.h. Controls are almost 30% of videodev2.h. I think maintaining controls would be easier if they are moved to e.g. linux/v4l2-controls.h which is included by videodev2.h. Ack. 2) Currently there are three types of controls: standard controls, controls that are specific to a chipset (e.g. cx2341x, mfc51) and driver-specific controls. The controls of the first two types have well defined and unique IDs. For driver-specific controls however there are no clear rules. It all depends on one question: should driver-specific controls have a unique control ID as well, or can they overlap with other drivers? If the answer is that they should be unique as well, then all driver-specific controls will have to be defined in a single header so you can be certain that there is no overlap. If the answer is that they may overlap, then each driver can either define their controls inside their own driver, or in a driver-specific public header. In both cases a control ID range has to be defined for such controls, to ensure that they never clash with standard or chipset-specific control IDs. E.g. = V4L2_CTRL_CLASS_XXX + 0x8000 (no overlap) or + 0xf000 (overlap allowed). My preference is to allow overlap. +1 for allowing overlap, and only when it is expected that some special app will actually use the device specific controls (versus the user changing them in a generic v4l2 control panel app), then the private controls should be defined in a public header. If no such special app is expected, the private controls should be defined inside a private header of the driver. 3) What should VIDIOC_STREAMON/OFF do if the stream is already started/stopped? I believe they should do nothing and just return 0. The main reason for that is it can be useful if an application can just call VIDIOC_STREAMOFF without having to check whether streaming is in progress. +1 for just returning 0 4) What should a driver return in TRY_FMT/S_FMT if the requested format is not supported (possible behaviours include returning the currently selected format or a default format). The spec says this: Drivers should not return an error code unless the input is ambiguous, but it does not explain what constitutes an ambiguous input. Frankly, I can't think of any and in my opinion TRY/S_FMT should never return an error other than EINVAL (if the buffer type is unsupported) or EBUSY (for S_FMT if streaming is in progress). Returning an error for any other reason doesn't help the application since the app will have no way of knowing what to do next. Ack on not returning an error for requesting an unavailable format. As for what the driver should do (default versus current format) I've no preference, I vote for letting this be decided by the driver implementation. 5) VIDIOC_QUERYCAP allows bus_info to be empty. Since the purpose of bus_info is to distinguish multiple identical devices this makes no sense. I propose to make the spec more strict and require that bus_info is always filled in with a unique string. Ack. 6) Deprecate V4L2_BUF_TYPE_PRIVATE. None of the kernel drivers use it, and I cannot see any good use-case for this. If some new type of buffer is needed, then that should be added instead of allowing someone to abuse this buffer type. Ack. 7) A driver that has both a video node and a vbi node (for example) that uses the same struct
Re: [Workshop-2011] RFC: V4L2 API ambiguities
Le lundi 13 août 2012 15:27:56 Hans Verkuil, vous avez écrit : 1) What is the right/best way to set the timestamp? The spec says gettimeofday, but is it my understanding that ktime_get_ts is much more efficient. Some drivers are already using ktime_get_ts. Options: a) all drivers must comply to the spec and use gettimeofday gettimeofday() is wrong for use other than getting the wall clock time. In particular, it breaks if the real-time clock gets adjusted while streaming. Practically all modern multimedia applications on Linux use the monotonic POSIX clock in a way or another. b) we change the spec and all drivers must use the more efficient ktime_get_ts Unfortunately, that would not be enough to be immediately useful. Userspace needs a way to know that it can (finally!) trust the timestamps. Currently, since different drivers use different clocks, the only reasonable option for user space consists of ignoring the V4L2 timestamp. Thus userspace has to fall back to the current clock time after ioctl(DQBUF) returns, as an approximation. c) we add a buffer flag V4L2_BUF_FLAG_MONOTONIC to tell userspace that a monotonic clock like ktime_get_ts is used and all drivers that use ktime_get_ts should set that flag. Yes, either a buffer or a capability flag ought to work. If we go for c, then we should add a recommendation to use one or the other as the preferred timestamp for new drivers. IMHO, all drivers should be adapted to the new specification as far as possible. Of course, that will break any user space application that would have trusted V4L2 to return valid CLOCK_REALTIME timestamps so far. I'd argue such an application was already broken in practice even if it conformed to the letter of the V4L2 specification. -- Rémi Denis-Courmont C/C++ software engineer looking for a job http://www.linkedin.com/in/remidenis -- 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
Re: [Workshop-2011] RFC: V4L2 API ambiguities
Hi! On 08/13/2012 03:13 PM, Hans de Goede wrote: 2) If a driver supports only formats with more than one plane, should V4L2_CAP_VIDEO_CAPTURE still be defined? No Agreed. And if a driver also supports single-plane formats in addition to 1 plane formats, should V4L2_CAP_VIDEO_CAPTURE be compulsary? Yes, so that non multi-plane aware apps keep working. There is the multi-planar API and there are multi-planar formats. Single- and multi-planar formats can be handled with the multi-planar API. So if a driver supports single- and multi-planar formats by means on multi-planar APIs, there shouldn't be a need for signalling V4L2_CAP_VIDEO_CAPTURE, which normally indicates single-planar API. The driver may choose to not support it, in order to handle single-planar formats. Thus, in my opinion making V4L2_CAP_VIDEO_CAPTURE compulsory wouldn't make sense. Unless the driver supports both types of ioctls (_mplane and regular versions), we shouldn't flag V4L2_CAP_VIDEO_CAPTURE. Regards, Sylwester -- 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
Re: RFC: V4L2 API ambiguities
On Mon, 13 Aug 2012 14:27:56 +0200, Hans Verkuil hverk...@xs4all.nl wrote: Hi all! As part of the 2012 Kernel Summit V4L2 workshop I will be discussing a bunch of V4L2 ambiguities/improvements. ... If something is unclear, or you think another topic should be added, then let me know as well. For me there is a an issue in the V4L specs for the support of DVB-S/C/T devices where the CI device is decoupled from the Tuners. At the moment there is no standard solution on which device drivers implementers and Application programmers can fall back. This is for hardware with multiple tuners and one CI device that can handle multiple streams (or even streams from different cards). The solution should explain how the Tuners are linked to the CI module(s). The current situation leads to device drivers that are implemented but that are not (fully) usable in any application. The application developers are waiting for API specs to explain how to implement the CI capabilities. In my experience a solution for this would bring more users to use DVB-S/T/C capabilities of Linux (as the average TV user in many countries uses a payed subscription). Walter -- 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
Re: RFC: V4L2 API ambiguities
On Mon, Aug 13, 2012 at 4:27 PM, Walter Van Eetvelt wal...@van.eetvelt.be wrote: For me there is a an issue in the V4L specs for the support of DVB-S/C/T devices where the CI device is decoupled from the Tuners. At the moment there is no standard solution on which device drivers implementers and Application programmers can fall back. DVB isn't part of the V4L spec. There are *tons* of problems with DVB, none of which are being discussed in this meeting (out of scope). Devin -- Devin J. Heitmueller - Kernel Labs http://www.kernellabs.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
Re: RFC: V4L2 API ambiguities
Em 13-08-2012 18:31, Devin Heitmueller escreveu: On Mon, Aug 13, 2012 at 4:27 PM, Walter Van Eetvelt wal...@van.eetvelt.be wrote: For me there is a an issue in the V4L specs for the support of DVB-S/C/T devices where the CI device is decoupled from the Tuners. At the moment there is no standard solution on which device drivers implementers and Application programmers can fall back. DVB isn't part of the V4L spec. There are *tons* of problems with DVB, none of which are being discussed in this meeting (out of scope). No, it is not out of scope. The thing is that none of the developers that are going to be there proposed a DVB-specific themes, unfortunately. Yet, there are two themes there that are not V4L only: the userspace discussions and the SoC discussions. I expect that it will focus at the media API's as a hole, and not just V4L API. Regards, Mauro -- 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
Re: RFC: V4L2 API ambiguities
On Mon, Aug 13, 2012 at 5:39 PM, Mauro Carvalho Chehab mche...@redhat.com wrote: No, it is not out of scope. The thing is that none of the developers that are going to be there proposed a DVB-specific themes, unfortunately. Yet, there are two themes there that are not V4L only: the userspace discussions and the SoC discussions. I expect that it will focus at the media API's as a hole, and not just V4L API. I'm talking specifically about a discussion of V4L2 API Ambiguities, which is the topic of this thread and the meeting in question. I realize other parts of the conference include DVB. If you want me to start piling onto this thread will all the problems/deficiencies related to our DVB API, we can certainly do that. However, none of the people on this thread will have any real insight into them given those individuals focus entirely on V4L2. Devin -- Devin J. Heitmueller - Kernel Labs http://www.kernellabs.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
Re: RFC: V4L2 API ambiguities
Em 13-08-2012 18:42, Devin Heitmueller escreveu: On Mon, Aug 13, 2012 at 5:39 PM, Mauro Carvalho Chehab mche...@redhat.com wrote: No, it is not out of scope. The thing is that none of the developers that are going to be there proposed a DVB-specific themes, unfortunately. Yet, there are two themes there that are not V4L only: the userspace discussions and the SoC discussions. I expect that it will focus at the media API's as a hole, and not just V4L API. I'm talking specifically about a discussion of V4L2 API Ambiguities, which is the topic of this thread and the meeting in question. OK. With that regards, you're right. I realize other parts of the conference include DVB. If you want me to start piling onto this thread will all the problems/deficiencies related to our DVB API, we can certainly do that. However, none of the people on this thread will have any real insight into them given those individuals focus entirely on V4L2. Yeah, but anyway we can try to cover the points that Walter made during the DVB topics. I suspect, however, that we need an RFC with a proposal for CI decoupled from the demux, in order to be able to discuss it. Regards, Mauro -- 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
Re: [Workshop-2011] RFC: V4L2 API ambiguities
Hi Hans, On Monday 13 August 2012 14:27:56 Hans Verkuil wrote: Hi all! As part of the 2012 Kernel Summit V4L2 workshop I will be discussing a bunch of V4L2 ambiguities/improvements. I've made a list of all the V4L2 issues and put them in two categories: issues that I think are easy to resolve (within a few minutes at most), and those that are harder. If you think I put something in the easy category that you believe is actually hard, then please let me know. If you attend the workshop, then please read through this and think about it a bit, particularly for the second category. If something is unclear, or you think another topic should be added, then let me know as well. Easy: [snip] 4) What should a driver return in TRY_FMT/S_FMT if the requested format is not supported (possible behaviours include returning the currently selected format or a default format). The spec says this: Drivers should not return an error code unless the input is ambiguous, but it does not explain what constitutes an ambiguous input. Frankly, I can't think of any and in my opinion TRY/S_FMT should never return an error other than EINVAL (if the buffer type is unsupported) or EBUSY (for S_FMT if streaming is in progress). Returning an error for any other reason doesn't help the application since the app will have no way of knowing what to do next. That wasn't my point. Drivers should obviously not return an error. Let's consider the case of a driver supporting YUYV and MJPEG. If the user calls TRY_FMT or S_FMT with the pixel format set to RGB565, should the driver return a hardcoded default format (one of YUYV or MJPEG), or the currently selected format ? In other words, should the pixel format returned by TRY_FMT or S_FMT when the requested pixel format is not valid be a fixed default pixel format, or should it depend on the currently selected pixel format ? [snip] 11) What should video output drivers do with the sequence and timestamp fields when they return a v4l2_buffer from VIDIOC_DQBUF? I think the spec is clear with respect to the timestamp: The driver stores the time at which the first data byte was actually sent out in the timestamp field. The complete text says For input streams this is the system time (as returned by the gettimeofday() function) when the first data byte was captured. For output streams the data will not be displayed before this time, secondary to the nominal frame rate determined by the current video standard in enqueued order. Applications can for example zero this field to display frames as soon as possible. The driver stores the time at which the first data byte was actually sent out in the timestamp field. This permits applications to monitor the drift between the video and system clock. Splitting it into two paragraphs after the first sentence would in my opinion be clearer. For sequence the spec just says: Set by the driver, counting the frames in the sequence. So I think that output drivers should indeed set both sequence and timestemp. I'm fine with that, I would then just like to clarify the spec. [snip] Hard(er): 1) What is the right/best way to set the timestamp? The spec says gettimeofday, but is it my understanding that ktime_get_ts is much more efficient. Some drivers are already using ktime_get_ts. Options: a) all drivers must comply to the spec and use gettimeofday b) we change the spec and all drivers must use the more efficient ktime_get_ts c) we add a buffer flag V4L2_BUF_FLAG_MONOTONIC to tell userspace that a monotonic clock like ktime_get_ts is used and all drivers that use ktime_get_ts should set that flag. If we go for c, then we should add a recommendation to use one or the other as the preferred timestamp for new drivers. I'd like to take this opportunity to introduce a proposed extension to the V4L2 API. UVC devices send a device timestamp for each frame in device clock units. I expect other devices to have similar capabilities. That device timestamp can be converted to a host timestamp by a clock recovery algorithm that uses clocks correlation information provided by the device. The uvcvideo driver currently converts the device timestamp to a host timestamp in kernelspace and fills the v4l2_buffer timestamp field with the computed value (which is BTW something that I would like the spec to allow, we should specify which clock the timestamp field must refer to, but should not mandate the use of a specific kernel function to retrieve the value). A userspace implementation of the clock recovery algorithm would produce better results. For this to be possible, applications (or libraries/middlewares) must retrieve the clock correlation information (a driver-specific ioctl makes sense here, as the information is device- specific), and receive the device timestamp corresponding to each frame in v4l2_buffer.
Re: [Workshop-2011] RFC: V4L2 API ambiguities
Hi Hans, On Monday 13 August 2012 15:13:34 Hans de Goede wrote: [snip] 4) What should a driver return in TRY_FMT/S_FMT if the requested format is not supported (possible behaviours include returning the currently selected format or a default format). The spec says this: Drivers should not return an error code unless the input is ambiguous, but it does not explain what constitutes an ambiguous input. Frankly, I can't think of any and in my opinion TRY/S_FMT should never return an error other than EINVAL (if the buffer type is unsupported) or EBUSY (for S_FMT if streaming is in progress). Returning an error for any other reason doesn't help the application since the app will have no way of knowing what to do next. Ack on not returning an error for requesting an unavailable format. As for what the driver should do (default versus current format) I've no preference, I vote for letting this be decided by the driver implementation. That's exactly the point that I wanted to clarify :-) I don't see a good reason to let the driver decide on this, and would prefer returning a default format as TRY_FMT would then always return the same result for a given input format regardless of the currently selected format. -- Regards, Laurent Pinchart -- 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
