On Tue, Jun 16, 2026 at 09:21:01AM +0200, Michel Dänzer wrote: > On 6/15/26 15:06, Ville Syrjälä wrote: > > > > What we're doing here is selecting the actual timings to drive an internal > > laptop > > panel, given some random cooked up modeline from userspace. > > How can user space know what cooked-up modes it can (not) expect to work with > this?
Without VRR support it can only expect modes that have the same refresh rate as one of the modes on the connector's mode list to work. With VRR support anything within the VRR range should generally work. That's assuming other parameters (eg. scaling) are acceptable of course. > > > > We pick the actual mode from the set of "fixed modes" (ie. the modes > > that the panel/system itself has reported as supported via > > EDID/VBT/ACPI/etc.). For non-VRR panels we just pick the fixed mode > > whose refresh rate is closest to the user specified mode, and reject > > the commit if it's not close enough (<= 1 Hz). > > Can't programming different mode timings result in the panel blanking > intermittently? Userspace can specify that a modeset is not allowed, thus if the driver can't achieve the refresh rate change without blinks the commit will be rejected. -- Ville Syrjälä Intel
