On 6/18/26 20:39, Ville Syrjälä wrote: > 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.
This seems to contradict "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)" below. >>> 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. How can the refresh rate change without a modeset (without VRR)? -- Earthling Michel Dänzer \ GNOME / Xwayland / Mesa developer https://redhat.com \ Libre software enthusiast
