Hi Sakari, On 1/29/24 19:40, Sakari Ailus wrote: > 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. As I mentioned currently libcamera's sensor class sets vblank to its default value at initialization time and some pipelines simply leave it there so having a somewhat sane default is important to not have a very high fps / have low max exposure for modes with a low height. > 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. This is mostly to have clear guidelines for when adding vblank support to existing drivers without vblank support. Existing drivers often have a fixed vts value independend of the mode / amount of cropping so that they always run at a fixed fps. Ideally we would not change the behavior of these drivers when adding vblank control. Having these drivers pick a default vblank value (when adjusting the range) so that the old fixed vts is again achieved and then resetting vblank to that default value ensures that the behavior of the driver does not change for userspace which does not touch vblank. Where as for userspace implementations which already set vblank to their own value the default does not matter. >>> 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. IMHO it is important to where possible not change the behavior of register list based drivers when adding improvements like vblank control. As I said above these often use a fixed vts for modes, the idea is to set a default vblank value so that the vts does not change compared to before the introduction of the vblank control. This is just about the default value after a set_mode pad-op call. Vblank aware userspace will likely override that anyway. Regards, Hans
