Hi Hans, On Mon, Jan 29, 2024 at 06:18:08PM +0100, Hans de Goede wrote: > Hi, > > On 1/29/24 15:45, Jacopo Mondi wrote: > > Hi Hans > > > > +dave, laurent and sakari > > > > On Mon, Jan 29, 2024 at 01:24:31PM +0100, Hans de Goede wrote: > >> Hi Jacopo, > >> > >> On 1/29/24 13:05, Jacopo Mondi wrote: > >>> Hi Hans > >>> > > <snip (getting too long)> > > >> OTOH I do believe that we want a simple default for vblank which gets > >> set on every set_mode call to keep things KISS. > >> > >> How about something like this: (based on your doc patch): > >> > >> """ > >> The vblank control default value is reset so that the sensor runs > >> at 30 fps. Except when 30 fps cannot be achieved, in that case > >> the vblank control default value is reset to the control's minimum. > >> > >> After adjusting the range, the vblank control's value must be set to its > >> new default value for consistent behavior after applying a new frame size. > >> """ > >> > > > > Sorry but I'm not super excited about blessing 30fps as the > > preferred or suggested setting in the documentation. For some use > > cases 30fps might be extremely slow or extremely fast, if a sensor or > > a mode cannot achieve this we then suggest the minimum... not sure > > what's best. What's others opinion here ? > > I'm fine with loosing the 30 fps language. I was actually > already thinking about dropping specifying 30 fps myself. > > In the pending documentation patch you write: > > "The value used to initialize the vertical and horizontal blanking controls > should be selected in order to realize, in association with the driver default > format and default pixel rate, a reasonable frame rate output, usually one of > the standard 15, 30 or 60 frame per second." > > How about: > > "When a new frame size is applied on the subdevice, sensor drivers are required > to update the limits of their blankings controls. > > ... part about calling __v4l2_ctrl_modify_range()... > > The control's default value is adjusted to achieve a reasonable framerate > again and the control's value is set to the new default for consistent > behavior after applying a new frame size." > > ? > > This basically blesses the existing ov5693 driver's behavior :) What would be the purpose of this? Presumably the user space will set the vblank value based on its needs in any case, before starting streaming. It would require changing many that currently don't have this. Changing this could also adversely affect some user space software but presumably is unlikely to break it. > > > Maybe we're getting too concerned on this, as if an application sets a > > new mode, it's likely setting new blankings and exposure as well.. > > ATM libcamera sets vblank to whatever default the sensor driver > advertises and not all pipelines change it after that, so IMHO we > need to have a somewhat sane default (and we probably want > libcamera pipelines to do a bit better, esp. with increasing > vblank to allow higher exposure in low light conditions). It should be easy to calculate the right value, given the necessary information. This is related to the needs of improving the sensor APIs for register list based drivers. > > > > > >>>> What about enum/get/set frame_interval vs set_mode vs > >>>> vblank ctrl ? Options: > >>>> > >>>> a) Sensor drivers MUST not implement enum/get/set frame_interval? > >>> > >>> Ideally they shouldn't, for RAW sensors at least. > >>> > >>> For YUV/RGB sensors instead the high-level parameters used by > >>> frame_interval might be ok as some of those sensors might not even > >>> allow you to control blankings explicitly. > >>> > >>> Whenever the hardware allows that, blankings should always be > >>> preferred over frame_interval imho. > >>> > >>>> b) enum/get/set frame_interval only enum/get/set the default > >>>> frame_interval set by set_mode (e.g. fixed 30 fps). > >>>> Any vblank changes made after the set_mode are not reflected > >>>> by get_frame_interval and set_frame_interval only influences > >>>> the next set_mode call, not the current mode ? Or maybe > >>>> only allow set_frame_interval when not streaming and then > >>>> have it set vblank to match the interval like it would > >>>> have done when called before the last set_mode call ? > >>>> c) enum/get/set frame_interval are a second way to control > >>>> hts (lets not go there just here for completeness sake) > >>>> > >>>> My own preference here would be to go with a) . > >>> > >>> Mine as well, but as said for YUV/RGB sensors it might not even be > >>> possible to control blankings explicitly. In this case > >>> set_frame_interval can be used but if the driver registers the vblank > >>> control the newly computed blanking value (in response to a > >>> set_frame_interval) should be reflected there ? > >> > >> IMHO if the driver registers the vblank control then it *must not* > >> implement enum/get/set frame_interval . Trying to support both at > >> the same time is just going to cause pain. > > > > Well, a RO vblank wouldn't hurt :) > > Yes and I guess that for sensors where we cannot explicitly > control vblank we would need a RO vblank to satisfy libcamera's > sensor requirements. Vertical blanking is virtually always controllable, horizontal blanking not nearly as often. -- Regards, Sakari Ailus
