On Fri, Jun 19, 2026 at 10:48:45AM +0200, Michel Dänzer wrote: > 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)?
Given a capable eDP panel we can reprogram the dotclock/Mvid/Nvid atomically so that the refresh rate changes from one frame to another. -- Ville Syrjälä Intel
