Skip to contentSkip to conversation

qv4l2 and media controller support

DISCUSSION Laurent Pinchart 2 participants 4 messages Jan 22, 2014 – Jan 25, 2014 Media (V4L/DVB)

lore
Share & tools
lore
#0 lore raw

Hi Hans and Detlev,

While reviewed driver code that models the hardware using the media controller, I noticed a patch that enabled subdev controls inheritance for the video nodes. While this is useful for fixed devices, the complexity, genericity and flexibility of the hardware at hand makes this undesirable, given that we can't guarantee that a control won't be instantiated more than once in the pipeline.

I've thus asked what triggered the need for controls inheritance, and found out that the developers wanted to use qv4l2 as a demo application (congratulations to Hans for such a useful application :-)). As qv4l2 doesn't support subdevices, accessing controls required inheriting them on video nodes.

There's an existing GUI test application for media controller-based devices called mci (https://gitorious.org/mci) but it hasn't been maintained for quite some time, and isn't as feature-complete as qv4l2. I was thus wondering whether it would make sense to add explicit media controller support to qv4l2, or whether the two applications should remain separate (in the later case some code could probably still be shared).

Any opinion and/or desire to work on this ?

Signature · 3 lines
Regards,

Laurent Pinchart
#1 lore raw

Hi Laurent,

First, regarding the inheritance of subdev controls: I found it annoying as well that there is no way to do this. If you have a simple video pipeline, then having to create subdev nodes just to set a few controls is unnecessary complex. I've been thinking of adding a flag to the control handler that, when set, will 'import' the private controls. The bridge driver is the one that sets this as that is the only one that knows whether or not it is in fact a simple pipeline.

Secondly, I'd love to add MC support to qv4l2. But I'm waiting for you to merge the MC library into v4l-utils.git. It's basically the reason why I haven't looked at this at all.

Regards,

Hans

Quoted 24 lines · Laurent Pinchart

Hi Hans and Detlev,

While reviewed driver code that models the hardware using the media controller, I noticed a patch that enabled subdev controls inheritance for the video nodes. While this is useful for fixed devices, the complexity, genericity and flexibility of the hardware at hand makes this undesirable, given that we can't guarantee that a control won't be instantiated more than once in the pipeline.

I've thus asked what triggered the need for controls inheritance, and found out that the developers wanted to use qv4l2 as a demo application (congratulations to Hans for such a useful application :-)). As qv4l2 doesn't support subdevices, accessing controls required inheriting them on video nodes.

There's an existing GUI test application for media controller-based devices called mci (https://gitorious.org/mci) but it hasn't been maintained for quite some time, and isn't as feature-complete as qv4l2. I was thus wondering whether it would make sense to add explicit media controller support to qv4l2, or whether the two applications should remain separate (in the later case some code could probably still be shared).

Any opinion and/or desire to work on this ?

#2 lore raw

Hi Hans,

Quoted 9 lines · On Thursday 23 January 2014 00:13:01 Hans Verkuil wrote:

Hi Laurent,

First, regarding the inheritance of subdev controls: I found it annoying as well that there is no way to do this. If you have a simple video pipeline, then having to create subdev nodes just to set a few controls is unnecessary complex. I've been thinking of adding a flag to the control handler that, when set, will 'import' the private controls. The bridge driver is the one that sets this as that is the only one that knows whether or not it is in fact a simple pipeline.

In my case the pipeline is potentially complex, given that it's implemented in an FPGA. The bridge driver just parses the DT pipeline representation and binds subdevs together. It has no concept of simple or complex pipelines. I've thus decided to go for an MC model, even for simple pipelines.

Quoted 3 lines

Secondly, I'd love to add MC support to qv4l2. But I'm waiting for you to merge the MC library into v4l-utils.git. It's basically the reason why I haven't looked at this at all.

I assume that's a hint :-)

I've just posted a series of patches for libmediactl. Let's take it from there.

Signature · 3 lines
Regards,

Laurent Pinchart
#3 lore raw

Hi Laurent,

Quoted 13 lines · Laurent Pinchart

Hi Hans,

Quoted 9 lines · On Thursday 23 January 2014 00:13:01 Hans Verkuil wrote:

Hi Laurent,

First, regarding the inheritance of subdev controls: I found it annoying as well that there is no way to do this. If you have a simple video pipeline, then having to create subdev nodes just to set a few controls is unnecessary complex. I've been thinking of adding a flag to the control handler that, when set, will 'import' the private controls. The bridge driver is the one that sets this as that is the only one that knows whether or not it is in fact a simple pipeline.

Quoted 4 lines

In my case the pipeline is potentially complex, given that it's implemented in an FPGA. The bridge driver just parses the DT pipeline representation and binds subdevs together. It has no concept of simple or complex pipelines. I've thus decided to go for an MC model, even for simple pipelines.

That makes a lot of sense. I was talking about e.g. PCI cards with a simple video capture pipeline where this would actually be useful.

Quoted 5 lines
Quoted 3 lines

Secondly, I'd love to add MC support to qv4l2. But I'm waiting for you to merge the MC library into v4l-utils.git. It's basically the reason why I haven't looked at this at all.

I assume that's a hint :-)

A big one :-)

Quoted 3 lines

I've just posted a series of patches for libmediactl. Let's take it from there.

Thanks!

Hans