[Q] {enum,s,g}_input for subdev ops

[Q] {enum,s,g}_input for subdev ops

[Guennadi Liakhovetski]

Hi

Any thoughts about the subj? Hasn't anyone run into a need to select 
inputs on subdevices until now? Something like

struct v4l2_subdev_video_ops {
	...
	int (*enum_input)(struct v4l2_subdev *sd, struct v4l2_input *inp);
	int (*g_input)(struct v4l2_subdev *sd, unsigned int *i);
	int (*s_input)(struct v4l2_subdev *sd, unsigned int i);

For example, we discussed implementing sensor test patterns as separate 
inputs.

Thanks
Guennadi
---
Guennadi Liakhovetski, Ph.D.
Freelance Open-Source Software Developer
http://www.open-technology.de/

Re: [Q] {enum,s,g}_input for subdev ops

[Hans Verkuil]

On Tuesday, February 22, 2011 17:39:25 Guennadi Liakhovetski wrote:
> On Tue, 22 Feb 2011, Hans Verkuil wrote:
> 
> > > Hi
> > >
> > > Any thoughts about the subj? Hasn't anyone run into a need to select
> > > inputs on subdevices until now? Something like
> > >
> > > struct v4l2_subdev_video_ops {
> > > 	...
> > > 	int (*enum_input)(struct v4l2_subdev *sd, struct v4l2_input *inp);
> > > 	int (*g_input)(struct v4l2_subdev *sd, unsigned int *i);
> > > 	int (*s_input)(struct v4l2_subdev *sd, unsigned int i);
> > 
> > That's done through s_routing. Subdevices know nothing about inputs as
> > shown to userspace.
> > 
> > If you want a test pattern, then the host driver needs to add a "Test
> > Pattern" input and call s_routing with the correct values (specific to
> > that subdev) to set it up.
> 
> Hm, maybe I misunderstood something, but if we understand "host" in the 
> same way, then this doesn't seem very useful to me. What shall the host 
> have to do with various sensor inputs? It cannot know, whether the sensor 
> has a test-pattern "input" and if yes - how many of them. Many sensors 
> have several such patterns, and, I think, some of them also have some 
> parameters, like colour values, etc., which we don't have anything to map 
> to. But even without that - some sensors have several test patterns, which 
> they well might want to be able to switch between by presenting not just 
> one but several test inputs. So, shouldn't we have some enum_routing or 
> something for them?

What you really want is to select a test pattern. A good solution would be
to create a sensor menu control with all the test patterns it supports.

Regards,

	Hans

> 
> Feel free to re-add the ML to CC.
> 
> Thanks
> Guennadi
> 
> > The saa7127 subdev does something like this (see include/media/saa7127.h).
> > The ivtv host driver only selects this during firmware load, though. It's
> > not mapped to a user input.
> > 
> > Regards,
> > 
> >      Hans
> > 
> > >
> > > For example, we discussed implementing sensor test patterns as separate
> > > inputs.
> > >
> > > Thanks
> > > Guennadi
> > > ---
> > > Guennadi Liakhovetski, Ph.D.
> > > Freelance Open-Source Software Developer
> > > http://www.open-technology.de/
> > > --
> > > To unsubscribe from this list: send the line "unsubscribe linux-media" in
> > > the body of a message to majordomo@vger.kernel.org
> > > More majordomo info at  http://vger.kernel.org/majordomo-info.html
> > >
> > 
> > 
> 
> ---
> Guennadi Liakhovetski, Ph.D.
> Freelance Open-Source Software Developer
> http://www.open-technology.de/
> 

-- 
Hans Verkuil - video4linux developer - sponsored by Cisco

Re: [Q] {enum,s,g}_input for subdev ops

[Guennadi Liakhovetski]

On Tue, 22 Feb 2011, Hans Verkuil wrote:

> On Tuesday, February 22, 2011 17:39:25 Guennadi Liakhovetski wrote:
> > On Tue, 22 Feb 2011, Hans Verkuil wrote:
> > 
> > > > Hi
> > > >
> > > > Any thoughts about the subj? Hasn't anyone run into a need to select
> > > > inputs on subdevices until now? Something like
> > > >
> > > > struct v4l2_subdev_video_ops {
> > > > 	...
> > > > 	int (*enum_input)(struct v4l2_subdev *sd, struct v4l2_input *inp);
> > > > 	int (*g_input)(struct v4l2_subdev *sd, unsigned int *i);
> > > > 	int (*s_input)(struct v4l2_subdev *sd, unsigned int i);
> > > 
> > > That's done through s_routing. Subdevices know nothing about inputs as
> > > shown to userspace.
> > > 
> > > If you want a test pattern, then the host driver needs to add a "Test
> > > Pattern" input and call s_routing with the correct values (specific to
> > > that subdev) to set it up.
> > 
> > Hm, maybe I misunderstood something, but if we understand "host" in the 
> > same way, then this doesn't seem very useful to me. What shall the host 
> > have to do with various sensor inputs? It cannot know, whether the sensor 
> > has a test-pattern "input" and if yes - how many of them. Many sensors 
> > have several such patterns, and, I think, some of them also have some 
> > parameters, like colour values, etc., which we don't have anything to map 
> > to. But even without that - some sensors have several test patterns, which 
> > they well might want to be able to switch between by presenting not just 
> > one but several test inputs. So, shouldn't we have some enum_routing or 
> > something for them?
> 
> What you really want is to select a test pattern. A good solution would be
> to create a sensor menu control with all the test patterns it supports.

Ok, so, we think using extra inputs for test patterns is not all that of a 
good idea after all? Maybe you're right. A control menu seems a pretty 
good option to me too.

Thanks
Guennadi
---
Guennadi Liakhovetski, Ph.D.
Freelance Open-Source Software Developer
http://www.open-technology.de/

Re: [Q] {enum,s,g}_input for subdev ops

[Guennadi Liakhovetski]

On Tue, 22 Feb 2011, Hans Verkuil wrote:

> On Tuesday, February 22, 2011 17:39:25 Guennadi Liakhovetski wrote:
> > On Tue, 22 Feb 2011, Hans Verkuil wrote:
> > 
> > > > Hi
> > > >
> > > > Any thoughts about the subj? Hasn't anyone run into a need to select
> > > > inputs on subdevices until now? Something like
> > > >
> > > > struct v4l2_subdev_video_ops {
> > > > 	...
> > > > 	int (*enum_input)(struct v4l2_subdev *sd, struct v4l2_input *inp);
> > > > 	int (*g_input)(struct v4l2_subdev *sd, unsigned int *i);
> > > > 	int (*s_input)(struct v4l2_subdev *sd, unsigned int i);
> > > 
> > > That's done through s_routing. Subdevices know nothing about inputs as
> > > shown to userspace.
> > > 
> > > If you want a test pattern, then the host driver needs to add a "Test
> > > Pattern" input and call s_routing with the correct values (specific to
> > > that subdev) to set it up.
> > 
> > Hm, maybe I misunderstood something, but if we understand "host" in the 
> > same way, then this doesn't seem very useful to me. What shall the host 
> > have to do with various sensor inputs? It cannot know, whether the sensor 
> > has a test-pattern "input" and if yes - how many of them. Many sensors 
> > have several such patterns, and, I think, some of them also have some 
> > parameters, like colour values, etc., which we don't have anything to map 
> > to. But even without that - some sensors have several test patterns, which 
> > they well might want to be able to switch between by presenting not just 
> > one but several test inputs. So, shouldn't we have some enum_routing or 
> > something for them?
> 
> What you really want is to select a test pattern. A good solution would be
> to create a sensor menu control with all the test patterns it supports.

Ok, thinking a bit further about it. Let's take mt9p031 as an example - a 
pretty simple bayer-only sensor. The driver is not yet in the mainline, 
but I'll be pushing something simple in the mainline soon. I just picked 
it up as an example, because it has quite a few test modes.

On the total it can generate 9 test patterns, including gradients, bars, 
constant colour-field, etc. Apart from selecting a specific test pattern, 
the RGB colour values and monochrome "intensity" values and bar widths can 
be set for the colour-field and monochrome-bars test-patterns respectively.

Using a control menu we can select one of the 9 test-modes. But do we also 
want standard controls for colour values and bar widths? Or are they too 
hardware-specific and too unimportant and can only be supported by private 
controls?

Thanks
Guennadi
---
Guennadi Liakhovetski, Ph.D.
Freelance Open-Source Software Developer
http://www.open-technology.de/

Re: [Q] {enum,s,g}_input for subdev ops

[Hans Verkuil]

On Wednesday, February 23, 2011 11:13:57 Guennadi Liakhovetski wrote:
> On Tue, 22 Feb 2011, Hans Verkuil wrote:
> 
> > On Tuesday, February 22, 2011 17:39:25 Guennadi Liakhovetski wrote:
> > > On Tue, 22 Feb 2011, Hans Verkuil wrote:
> > > 
> > > > > Hi
> > > > >
> > > > > Any thoughts about the subj? Hasn't anyone run into a need to select
> > > > > inputs on subdevices until now? Something like
> > > > >
> > > > > struct v4l2_subdev_video_ops {
> > > > > 	...
> > > > > 	int (*enum_input)(struct v4l2_subdev *sd, struct v4l2_input 
*inp);
> > > > > 	int (*g_input)(struct v4l2_subdev *sd, unsigned int *i);
> > > > > 	int (*s_input)(struct v4l2_subdev *sd, unsigned int i);
> > > > 
> > > > That's done through s_routing. Subdevices know nothing about inputs as
> > > > shown to userspace.
> > > > 
> > > > If you want a test pattern, then the host driver needs to add a "Test
> > > > Pattern" input and call s_routing with the correct values (specific to
> > > > that subdev) to set it up.
> > > 
> > > Hm, maybe I misunderstood something, but if we understand "host" in the 
> > > same way, then this doesn't seem very useful to me. What shall the host 
> > > have to do with various sensor inputs? It cannot know, whether the 
sensor 
> > > has a test-pattern "input" and if yes - how many of them. Many sensors 
> > > have several such patterns, and, I think, some of them also have some 
> > > parameters, like colour values, etc., which we don't have anything to 
map 
> > > to. But even without that - some sensors have several test patterns, 
which 
> > > they well might want to be able to switch between by presenting not just 
> > > one but several test inputs. So, shouldn't we have some enum_routing or 
> > > something for them?
> > 
> > What you really want is to select a test pattern. A good solution would be
> > to create a sensor menu control with all the test patterns it supports.
> 
> Ok, thinking a bit further about it. Let's take mt9p031 as an example - a 
> pretty simple bayer-only sensor. The driver is not yet in the mainline, 
> but I'll be pushing something simple in the mainline soon. I just picked 
> it up as an example, because it has quite a few test modes.
> 
> On the total it can generate 9 test patterns, including gradients, bars, 
> constant colour-field, etc. Apart from selecting a specific test pattern, 
> the RGB colour values and monochrome "intensity" values and bar widths can 
> be set for the colour-field and monochrome-bars test-patterns respectively.
> 
> Using a control menu we can select one of the 9 test-modes. But do we also 
> want standard controls for colour values and bar widths? Or are they too 
> hardware-specific and too unimportant and can only be supported by private 
> controls?

I think all test pattern controls would be prime candidates as subdev-specific 
controls: they are hardware specific so it's difficult anyway to make them 
generic controls and they are typically only used for debugging.

But we can't do that until the MC code is merged. This also requires that the 
subdev uses the control framework.

The MC code will hopefully be merged soon and I have worked on the control 
framework patches for soc-camera, although those need more work.

Regards,

	Hans

> 
> Thanks
> Guennadi
> ---
> Guennadi Liakhovetski, Ph.D.
> Freelance Open-Source Software Developer
> http://www.open-technology.de/
> --
> To unsubscribe from this list: send the line "unsubscribe linux-media" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>