Re: [RFC/PATCH v4 00/11] Media controller (core and V4L2)
Hi Hans, On Tuesday 14 September 2010 15:24:41 Hans Verkuil wrote: > > On Thursday 09 September 2010 03:44:15 Mauro Carvalho Chehab wrote: > > > >> It should also say that no driver should just implement the media > >> controller API. > > > > I haven't thought about that, as it would be pretty useless :-) > > I actually think that it should be possible without too much effort to > make the media API available automatically for those drivers that do not > implement it themselves. For the standard drivers it basically just has to > enumerate what is already known. > > It would help a lot with apps like MythTV that want to find related > devices (e.g. audio/video/vbi). I think Mauro meant that no driver should implement the media controller API without implementing any other standard API (ALSA, DVB, FB, IR, V4L, ...). -- 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: [RFC/PATCH v4 00/11] Media controller (core and V4L2)
Hi Mauro, On Tuesday 14 September 2010 15:34:26 Mauro Carvalho Chehab wrote: > Em 14-09-2010 09:25, Laurent Pinchart escreveu: > > On Thursday 09 September 2010 03:44:15 Mauro Carvalho Chehab wrote: > >> Em 20-08-2010 12:29, Laurent Pinchart escreveu: > >>> Hi everybody, > >>> > >>> Here's the fourth version of the media controller patches. All comments > >>> received so far have hopefully been incorporated. > >>> > >>> Compared to the previous version, the patches have been rebased on top > >>> of 2.6.35 and a MEDIA_IOC_DEVICE_INFO ioctl has been added. > >>> > >>> I won't submit a rebased version of the V4L2 API additions and OMAP3 > >>> ISP patches right now. I will first clean up (and document) the V4L2 > >>> API additions patches, and I will submit them as a proper RFC instead > >>> of sample code. > >> > >> Hi Laurent, > >> > >> Sorry for a late review on the media controller API. I got flooded by > >> patches and other work since the merge window. > > > > No worries. I was on holidays last week anyway. > > > >> Anyway, just finished my review, and sent a per-patch comment for most > >> patches. > > > > Thanks. > > > >> One general comment about it: the userspace API should be documented via > >> DocBook, to be consistent with V4L2 and DVB API specs. > > > > I feared so :-) I'll work on it. > > > >> It should also be clear at the API specs there that not all media > >> drivers will implement the media controller API, > > > > I agree. > > > >> as its main focus is to allow better control of SoC devices, where there > >> are needs to control some intrinsic characteristics of parts of the > >> devices, complementing the V4L2 spec. > > > > Some consumer devices (ivtv for instance) will also benefit from the > > media controller, the API is not specific to SoC devices only. > > I'm still in doubt about adding support for it at not so complex hardware > devices. Yes, there are some consumer devices that can benefit on it, like > cx25821, where it offers to 16 input/output video streams that can be > grouped and changed from input into output (as far as I understood). So, > for such devices, yes, it makes sense to use. But a simpler devices that > has just one or two stream inputs, alsa and IR, I don't see much sense on > using it. The media controller API is also used to find out which audio, dvb, fb, ir and v4l devices belong together. Applications such as mythtv are interested in that. > >> This means that it is needed to add some comments at the kernelspace API > >> doc, saying that the drivers implementing the media controller API are > >> required to work properly even when userspace is not using the media > >> controller API; > > > > That's another issue. Drivers should make a best effort to allow pure > > V4L2 applications to work with a subset of the video device nodes, but > > they will only offer a subset of the hardware capabilities. > > Ok, but this subset is enough for 99.9% of the cases on non-embedded > hardware. Yes, I was thinking about embedded hardware. > > For SoC devices it's even worse, it might be way too difficult to > > implement support for pure V4L2 applications in the kernel driver(s). In > > that case a device-specific libv4l plugin will configure the driver using > > the media controller API for pure V4L2 applications. > > SoC devices used on embedded hardware will have different requirements. I'm > ok on having an ancillary open source application to help to set the > device, as we've discussed at Helsinki's meeting, but this should be an > exception, handled case by case, and not the rule. > > >> This also means that it is needed to add some comments at the userspace > >> API doc, saying that userspace applications should not assume that > >> media drivers will implement the media controller API. > > > > Agreed. Many V4L2 drivers will not implement the media controller API. > > > >> So, userspace applications implementing the media controller and V4L2 > >> API's are required to work properly if the device doesn't present a > >> media controler API interface. > > > > Applications can require support for the media controller API, but they > > should only do so for specific cases (for instance applications tied to > > specific SoC hardware, or graphical user interfaces on top of the media > > controller API similar to qv4l2). > > Yes. > > >> It should also say that no driver should just implement the media > >> controller API. > > > > I haven't thought about that, as it would be pretty useless :-) > > Well, it doesn't hurt to write it at the spec ;) I won't doubt that people > might try to merge bad things, abusing on the api, and later saying that > they have an "open source driver" that it is not open at all. We've seen > cases like that in the past, where one "open" webcam driver used to work > only with an specific closed-source userspace application [1]. We need to > take extra care with any API that might be used to control devices in raw
Re: [RFC/PATCH v4 00/11] Media controller (core and V4L2)
Em 14-09-2010 09:25, Laurent Pinchart escreveu: > Hi Mauro, > > On Thursday 09 September 2010 03:44:15 Mauro Carvalho Chehab wrote: >> Em 20-08-2010 12:29, Laurent Pinchart escreveu: >>> Hi everybody, >>> >>> Here's the fourth version of the media controller patches. All comments >>> received so far have hopefully been incorporated. >>> >>> Compared to the previous version, the patches have been rebased on top of >>> 2.6.35 and a MEDIA_IOC_DEVICE_INFO ioctl has been added. >>> >>> I won't submit a rebased version of the V4L2 API additions and OMAP3 ISP >>> patches right now. I will first clean up (and document) the V4L2 API >>> additions patches, and I will submit them as a proper RFC instead of >>> sample code. >> >> Hi Laurent, >> >> Sorry for a late review on the media controller API. I got flooded by >> patches and other work since the merge window. > > No worries. I was on holidays last week anyway. > >> Anyway, just finished my review, and sent a per-patch comment for most >> patches. > > Thanks. > >> One general comment about it: the userspace API should be documented via >> DocBook, to be consistent with V4L2 and DVB API specs. > > I feared so :-) I'll work on it. > >> It should also be clear at the API specs there that not all media drivers >> will implement the media controller API, > > I agree. > >> as its main focus is to allow better control of SoC devices, where there are >> needs to control some intrinsic characteristics of parts of the devices, >> complementing the V4L2 spec. > > Some consumer devices (ivtv for instance) will also benefit from the media > controller, the API is not specific to SoC devices only. I'm still in doubt about adding support for it at not so complex hardware devices. Yes, there are some consumer devices that can benefit on it, like cx25821, where it offers to 16 input/output video streams that can be grouped and changed from input into output (as far as I understood). So, for such devices, yes, it makes sense to use. But a simpler devices that has just one or two stream inputs, alsa and IR, I don't see much sense on using it. >> This means that it is needed to add some comments at the kernelspace API >> doc, saying that the drivers implementing the media controller API are >> required to work properly even when userspace is not using the media >> controller API; > > That's another issue. Drivers should make a best effort to allow pure V4L2 > applications to work with a subset of the video device nodes, but they will > only offer a subset of the hardware capabilities. Ok, but this subset is enough for 99.9% of the cases on non-embedded hardware. > For SoC devices it's even > worse, it might be way too difficult to implement support for pure V4L2 > applications in the kernel driver(s). In that case a device-specific libv4l > plugin will configure the driver using the media controller API for pure V4L2 > applications. SoC devices used on embedded hardware will have different requirements. I'm ok on having an ancillary open source application to help to set the device, as we've discussed at Helsinki's meeting, but this should be an exception, handled case by case, and not the rule. >> This also means that it is needed to add some comments at the userspace API >> doc, saying that userspace applications should not assume that media >> drivers will implement the media controller API. > > Agreed. Many V4L2 drivers will not implement the media controller API. > >> So, userspace applications implementing the media controller and V4L2 API's >> are required to work properly if the device doesn't present a media >> controler API interface. > > Applications can require support for the media controller API, but they > should > only do so for specific cases (for instance applications tied to specific SoC > hardware, or graphical user interfaces on top of the media controller API > similar to qv4l2). Yes. >> It should also say that no driver should just implement the media controller >> API. > > I haven't thought about that, as it would be pretty useless :-) Well, it doesn't hurt to write it at the spec ;) I won't doubt that people might try to merge bad things, abusing on the api, and later saying that they have an "open source driver" that it is not open at all. We've seen cases like that in the past, where one "open" webcam driver used to work only with an specific closed-source userspace application [1]. We need to take extra care with any API that might be used to control devices in raw mode, as we'll never allow any driver to abuse on it to deny open source applications to use it. Cheers, Mauro [1] http://marc.info/?l=linux-kernel&m=109356393610149&w=2 -- 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/PATCH v4 00/11] Media controller (core and V4L2)
> Hi Mauro, > > On Thursday 09 September 2010 03:44:15 Mauro Carvalho Chehab wrote: >> Em 20-08-2010 12:29, Laurent Pinchart escreveu: >> > Hi everybody, >> > >> > Here's the fourth version of the media controller patches. All >> comments >> > received so far have hopefully been incorporated. >> > >> > Compared to the previous version, the patches have been rebased on top >> of >> > 2.6.35 and a MEDIA_IOC_DEVICE_INFO ioctl has been added. >> > >> > I won't submit a rebased version of the V4L2 API additions and OMAP3 >> ISP >> > patches right now. I will first clean up (and document) the V4L2 API >> > additions patches, and I will submit them as a proper RFC instead of >> > sample code. >> >> Hi Laurent, >> >> Sorry for a late review on the media controller API. I got flooded by >> patches and other work since the merge window. > > No worries. I was on holidays last week anyway. > >> Anyway, just finished my review, and sent a per-patch comment for most >> patches. > > Thanks. > >> One general comment about it: the userspace API should be documented via >> DocBook, to be consistent with V4L2 and DVB API specs. > > I feared so :-) I'll work on it. > >> It should also be clear at the API specs there that not all media >> drivers >> will implement the media controller API, > > I agree. > >> as its main focus is to allow better control of SoC devices, where there >> are >> needs to control some intrinsic characteristics of parts of the devices, >> complementing the V4L2 spec. > > Some consumer devices (ivtv for instance) will also benefit from the media > controller, the API is not specific to SoC devices only. > >> This means that it is needed to add some comments at the kernelspace API >> doc, saying that the drivers implementing the media controller API are >> required to work properly even when userspace is not using the media >> controller API; > > That's another issue. Drivers should make a best effort to allow pure V4L2 > applications to work with a subset of the video device nodes, but they > will > only offer a subset of the hardware capabilities. For SoC devices it's > even > worse, it might be way too difficult to implement support for pure V4L2 > applications in the kernel driver(s). In that case a device-specific > libv4l > plugin will configure the driver using the media controller API for pure > V4L2 > applications. > >> This also means that it is needed to add some comments at the userspace >> API >> doc, saying that userspace applications should not assume that media >> drivers will implement the media controller API. > > Agreed. Many V4L2 drivers will not implement the media controller API. > >> So, userspace applications implementing the media controller and V4L2 >> API's >> are required to work properly if the device doesn't present a media >> controler API interface. > > Applications can require support for the media controller API, but they > should > only do so for specific cases (for instance applications tied to specific > SoC > hardware, or graphical user interfaces on top of the media controller API > similar to qv4l2). > >> It should also say that no driver should just implement the media >> controller >> API. > > I haven't thought about that, as it would be pretty useless :-) I actually think that it should be possible without too much effort to make the media API available automatically for those drivers that do not implement it themselves. For the standard drivers it basically just has to enumerate what is already known. It would help a lot with apps like MythTV that want to find related devices (e.g. audio/video/vbi). Regards, Hans -- Hans Verkuil - video4linux developer - sponsored by TANDBERG, part of Cisco -- 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/PATCH v4 00/11] Media controller (core and V4L2)
Hi Mauro, On Thursday 09 September 2010 03:44:15 Mauro Carvalho Chehab wrote: > Em 20-08-2010 12:29, Laurent Pinchart escreveu: > > Hi everybody, > > > > Here's the fourth version of the media controller patches. All comments > > received so far have hopefully been incorporated. > > > > Compared to the previous version, the patches have been rebased on top of > > 2.6.35 and a MEDIA_IOC_DEVICE_INFO ioctl has been added. > > > > I won't submit a rebased version of the V4L2 API additions and OMAP3 ISP > > patches right now. I will first clean up (and document) the V4L2 API > > additions patches, and I will submit them as a proper RFC instead of > > sample code. > > Hi Laurent, > > Sorry for a late review on the media controller API. I got flooded by > patches and other work since the merge window. No worries. I was on holidays last week anyway. > Anyway, just finished my review, and sent a per-patch comment for most > patches. Thanks. > One general comment about it: the userspace API should be documented via > DocBook, to be consistent with V4L2 and DVB API specs. I feared so :-) I'll work on it. > It should also be clear at the API specs there that not all media drivers > will implement the media controller API, I agree. > as its main focus is to allow better control of SoC devices, where there are > needs to control some intrinsic characteristics of parts of the devices, > complementing the V4L2 spec. Some consumer devices (ivtv for instance) will also benefit from the media controller, the API is not specific to SoC devices only. > This means that it is needed to add some comments at the kernelspace API > doc, saying that the drivers implementing the media controller API are > required to work properly even when userspace is not using the media > controller API; That's another issue. Drivers should make a best effort to allow pure V4L2 applications to work with a subset of the video device nodes, but they will only offer a subset of the hardware capabilities. For SoC devices it's even worse, it might be way too difficult to implement support for pure V4L2 applications in the kernel driver(s). In that case a device-specific libv4l plugin will configure the driver using the media controller API for pure V4L2 applications. > This also means that it is needed to add some comments at the userspace API > doc, saying that userspace applications should not assume that media > drivers will implement the media controller API. Agreed. Many V4L2 drivers will not implement the media controller API. > So, userspace applications implementing the media controller and V4L2 API's > are required to work properly if the device doesn't present a media > controler API interface. Applications can require support for the media controller API, but they should only do so for specific cases (for instance applications tied to specific SoC hardware, or graphical user interfaces on top of the media controller API similar to qv4l2). > It should also say that no driver should just implement the media controller > API. I haven't thought about that, as it would be pretty useless :-) -- 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: [RFC/PATCH v4 00/11] Media controller (core and V4L2)
Em 20-08-2010 12:29, Laurent Pinchart escreveu: > Hi everybody, > > Here's the fourth version of the media controller patches. All comments > received > so far have hopefully been incorporated. > > Compared to the previous version, the patches have been rebased on top of > 2.6.35 > and a MEDIA_IOC_DEVICE_INFO ioctl has been added. > > I won't submit a rebased version of the V4L2 API additions and OMAP3 ISP > patches > right now. I will first clean up (and document) the V4L2 API additions > patches, > and I will submit them as a proper RFC instead of sample code. Hi Laurent, Sorry for a late review on the media controller API. I got flooded by patches and other work since the merge window. Anyway, just finished my review, and sent a per-patch comment for most patches. One general comment about it: the userspace API should be documented via DocBook, to be consistent with V4L2 and DVB API specs. It should also be clear at the API specs there that not all media drivers will implement the media controller API, as its main focus is to allow better control of SoC devices, where there are needs to control some intrinsic characteristics of parts of the devices, complementing the V4L2 spec. This means that it is needed to add some comments at the kernelspace API doc, saying that the drivers implementing the media controller API are required to work properly even when userspace is not using the media controller API; This also means that it is needed to add some comments at the userspace API doc, saying that userspace applications should not assume that media drivers will implement the media controller API. So, userspace applications implementing the media controller and V4L2 API's are required to work properly if the device doesn't present a media controler API interface. It should also say that no driver should just implement the media controller API. > > Laurent Pinchart (9): > media: Media device node support > media: Media device > media: Entities, pads and links > media: Media device information query > media: Entities, pads and links enumeration > media: Links setup > v4l: Add a media_device pointer to the v4l2_device structure > v4l: Make video_device inherit from media_entity > v4l: Make v4l2_subdev inherit from media_entity > > Sakari Ailus (2): > media: Entity graph traversal > media: Reference count and power handling > > Documentation/media-framework.txt| 574 > Documentation/video4linux/v4l2-framework.txt | 72 +++- > drivers/media/Makefile |8 +- > drivers/media/media-device.c | 377 > drivers/media/media-devnode.c| 310 + > drivers/media/media-entity.c | 614 > ++ > drivers/media/video/v4l2-dev.c | 35 ++- > drivers/media/video/v4l2-device.c| 45 ++- > drivers/media/video/v4l2-subdev.c| 27 ++- > include/linux/media.h| 105 + > include/media/media-device.h | 90 > include/media/media-devnode.h| 78 > include/media/media-entity.h | 112 + > include/media/v4l2-dev.h |6 + > include/media/v4l2-device.h |2 + > include/media/v4l2-subdev.h |7 + > 16 files changed, 2440 insertions(+), 22 deletions(-) > create mode 100644 Documentation/media-framework.txt > create mode 100644 drivers/media/media-device.c > create mode 100644 drivers/media/media-devnode.c > create mode 100644 drivers/media/media-entity.c > create mode 100644 include/linux/media.h > create mode 100644 include/media/media-device.h > create mode 100644 include/media/media-devnode.h > create mode 100644 include/media/media-entity.h > -- 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/PATCH v4 00/11] Media controller (core and V4L2)
Hi everybody, Here's the fourth version of the media controller patches. All comments received so far have hopefully been incorporated. Compared to the previous version, the patches have been rebased on top of 2.6.35 and a MEDIA_IOC_DEVICE_INFO ioctl has been added. I won't submit a rebased version of the V4L2 API additions and OMAP3 ISP patches right now. I will first clean up (and document) the V4L2 API additions patches, and I will submit them as a proper RFC instead of sample code. Laurent Pinchart (9): media: Media device node support media: Media device media: Entities, pads and links media: Media device information query media: Entities, pads and links enumeration media: Links setup v4l: Add a media_device pointer to the v4l2_device structure v4l: Make video_device inherit from media_entity v4l: Make v4l2_subdev inherit from media_entity Sakari Ailus (2): media: Entity graph traversal media: Reference count and power handling Documentation/media-framework.txt| 574 Documentation/video4linux/v4l2-framework.txt | 72 +++- drivers/media/Makefile |8 +- drivers/media/media-device.c | 377 drivers/media/media-devnode.c| 310 + drivers/media/media-entity.c | 614 ++ drivers/media/video/v4l2-dev.c | 35 ++- drivers/media/video/v4l2-device.c| 45 ++- drivers/media/video/v4l2-subdev.c| 27 ++- include/linux/media.h| 105 + include/media/media-device.h | 90 include/media/media-devnode.h| 78 include/media/media-entity.h | 112 + include/media/v4l2-dev.h |6 + include/media/v4l2-device.h |2 + include/media/v4l2-subdev.h |7 + 16 files changed, 2440 insertions(+), 22 deletions(-) create mode 100644 Documentation/media-framework.txt create mode 100644 drivers/media/media-device.c create mode 100644 drivers/media/media-devnode.c create mode 100644 drivers/media/media-entity.c create mode 100644 include/linux/media.h create mode 100644 include/media/media-device.h create mode 100644 include/media/media-devnode.h create mode 100644 include/media/media-entity.h -- 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
