If I understand correctly, that this is essentially the same or very similar to what AMD implemented in amdgpu-kms for VRR capable displays as "freesync_video", then a thumbs up from the sideline from a happy user of that amdgpu feature with a native X11 client on the native X-Server :). Psychtoolbox uses that feature to allow users to select fine-grained refresh rates on VRR capable displays, without need for full modesets, ie. almost glitch free. Very useful for vision research applications that benefit from unusual video refresh rates or the ability to quickly switch at fine granularity.
The useful feature for us here is the ability to do this with a native X11 client, using standard RandR api's on existing, unmodified, many years old, native X-Server versions which generally don't use or support atomic modesetting. Iow. the apps that don't live in a Wayland native (or client atomic modesetting) world yet. We are restricted to what standard X11 api's can do, or setting or reading a standard connector property exposed as RandR output property - without the need to first enhance the good ol' X-Server and then hope for a release of said improved X-Server maybe years down the road - or never. Psychtoolbox uses this since over a year, see the following commit if interested: https://github.com/Psychtoolbox-3/Psychtoolbox-3/commit/96970e6d98c9f6ee293f018186d3d898d27e77bb I'm not saying a more advanced atomic modesetting based approach won't be better / more flexible etc. Just that this is something that can benefit real world use cases of people inhabiting non-Wayland world quickly. Can do one thing without not doing the other thing. Best -mario On Mon, Jun 22, 2026 at 1:14 PM Ville Syrjälä <[email protected]> wrote: > > 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
