[PATCH 2/3] gstreamer: Generate controls from control_ids_*.yaml files

[Nicolas Dufresne]

Hi Jaslo,


Le lundi 30 septembre 2024 à 11:31 +0200, Jaslo Ziska a écrit :
> Hi Nicolas,
> 
> > 

[...]

> > And finally, there is triggers. This is the same concept as V4L2 
> > buttons, except
> > that you group multiple actions in the same button by passing an 
> > argument. That
> > is not a property. If we introduce a classification for 
> > settables, metadata and
> > triggers, that will be enough for the python generator to avoid 
> > this. My
> > recommandation Jaslo, would be to try and reduce the set of 
> > properties we expose
> > in a first pass, or make them opt-in.
> 
> Could you maybe elaborate which controls should be which GStreamer 
> kind property?
> 
> I think I understand it this way: the plain normal libcamera 
> controls should be GStreamer properties and the libcamera metadata 
> should be read-only GStreamer properties. But what about the other 
> controls?
> 
> Which kind of libcamera controls do you image to be GStreamer 
> actions? And what should be done about the libcamera "triggers"?
> 
> And also how should we specify which libcamera control is which 
> kind of GStreamer property/action/...? In the main yaml (if this 
> would be allowed just for GStreamer) or somewhere else?


In order to move on, maybe you can build a list of obvious controls from
libcamera that requires no wrapping to be useful. We need to limit the generator
in some ways and that would be a good start and a way to get v3 included.

For the rest, we have to stop thinking generically and go back to the items one
by one, and eventually we'll have have a common understanding of what goes
where. Some of them will have to be per pads, some of them might endup in a
stats property (rather then millions of little props), etc.

Nicolas 

> 
> Best regards,
> 
> Jaslo