The Many Mutter + Shell Improvements Coming With GNOME 3.38

[Space Heater]

The reality is the X11 server is not doing different rates. The drivers behind X11 server back is and that is what you are seeing.

So your idea that the monitors are running at different rates the reality it not the X11 server doing that. If X11 server has it way all monitors will be running at the exact same rate and that is how its internal logic works. So either you are rendering too many frames for your slow monitors or not enough frames for your fast monitors.

You clearly aren't great at reading -- as you keep ignoring what I write -- so I'll try to keep this short.

The reality is that I originally said you can support multiple monitor refresh rates while using X11 (note: that includes *other* software, not just X11), and that is obviously possible as you admit. The article you originally referenced is about splitting Gnome's *ClutterFrameClock* -- it's talking about fixing Gnome's previous limitation where it would not support independent monitor redraws.

[oiaohm]

You clearly aren't great at reading -- as you keep ignoring what I write -- so I'll try to keep this short.

The reality is that I originally said you can support multiple monitor refresh rates while using X11 (note: that includes *other* software, not just X11), and that is obviously possible as you admit. The article you originally referenced is about splitting Gnome's *ClutterFrameClock* -- it's talking about fixing Gnome's previous limitation where it would not support independent monitor redraws.

To be correct X11 server it self does not in fact support independent monitor redraws. X11 server drivers allow you to have monitors at different clock speeds by either over accepting frames or under accepting frames. If you are trying to be power effective this is not really running monitor correctly at its HZ.

Gnomes limitation where it would not support independent monitor redraws under X11 comes from X11 server and X11 protocol itself. Wayland protocol does not contain this limitation. Of course all the upper layers like opengl vsync and so on with X11 have been design that you don't in fact have independent monitor redraws to deal with.

The idea that is a Gnome only limitation to over come is wrong.

"support multiple monitor refresh rates while using X11" < This is wrong in fact like it or not. Yes the video drivers of X11 can support multiple monitor refresh rates but as soon as your software is on top of X11 you now are to the point of pick 1 refresh rate

If those making video card drivers for X11 you have to use have not implemented that graphics drivers will accept different frame rate to HZ(that is the case for some embedded GPUs don't implement the support) X11 server ceases to be able to support monitors at different frequencies at all. X.org X11 server core and X11 protocol like ir or not does not support multiple monitor refresh rate. Multi monitor refresh rate only appears to work with X11 because drivers contain work around that is not GPU power effective.

Since something was not in fact possible while on top X11 server this means KDE, Gnome.... all have to implement new stuff now that it possible under Wayland. Of course that its new there are a nice new set of bugs.

By the way Gnome on X11 on drivers that support different frame rate to HZ of monitor will have those monitors running at different HZ. This is not a generic X11 works feature this is you have the right drivers covering up the X11 defect.

X11 server with right drivers appears to work for refreshing monitors at different time when in reality the X11 protocol and the X11 core server is not doing that.

Space Heater what you missed is Gnome previous limitation of not supporting independent monitor redraws comes from the fact that while on top of X11 server you cannot support that. Gnome moving to wayland basically pulled the rug of driver will fix it from under Gnome Mutter. Due to problem being a X11 protocol defect the independant monitor redraw code Mutter has for Wayland cannot be ported to X11 because the framework is not there so it can be made work

[Space Heater]

Space Heater what you missed is Gnome previous limitation of not supporting independent monitor redraws comes from the fact that while on top of X11 server you cannot support that. Gnome moving to wayland basically pulled the rug of driver will fix it from under Gnome Mutter. Due to problem being a X11 protocol defect the independant monitor redraw code Mutter has for Wayland cannot be ported to X11 because the framework is not there so it can be made work

The ClutterFrameClock is clearly a Gnome-specific construct that they have now split up. While the limitation of having a single ClutterFrameClock is only clearly exposed on Wayland, the fix described in the article you linked is still specific to Gnome whether you like it or not.

The verbosity of your replies do not make your argument any more compelling or less repetitive.

[aufkrawall]

It was the X11 lead developer who pointed out that X11 server runs with 1 frame lag on top of the lag you need to do vsync .

I don't notice such a thing vs. Windows so I don't need to care about what anybody says.
What I notice is that on both Gnome and Sway XWayland games feel laggy vs. native Xorg without and with vsync. That is reality do date, not something else.

VRR Except that is broken on dual screen setups with X11 and has been for ages.

https://www.reddit.com/r/linux_gaming/comments/a1jv9q/gsync_w_dual_monitors/

I don't care for MM for gaming. Market trend btw. are 21:9 displays.

[oiaohm]

The ClutterFrameClock is clearly a Gnome-specific construct that they have now split up. While the limitation of having a single ClutterFrameClock is only clearly exposed on Wayland, the fix described in the article you linked is still specific to Gnome whether you like it or not.

https://blogs.gnome.org/shell-dev/2020/07/02/splitting-up-the-frame-clock/

In the X11 session, we composite the whole X11 screen at once, without any separation between monitors. This remains unchanged, with the difference being where scheduling takes place (as mentioned in an earlier point). The improvements described here are thus limited to using the Wayland session.

Space Heater the limitation of having only a single frame clock is X11 limitation. You need to draw the X11 screen at once and that includes all monitors. Drivers on X11 solutions have been hacking around the issue. So the issue has been hidden by drivers of course this has had a cost. Part of the reason why desktop Linux on laptops have had worst battery life when plugged into external monitors doing presentations is this problem.

ClutterMasterClock was lets just copy what on top of the X11 server where you only have a single clock to all other platforms. Of course it does not work when you have removed the X11 driver slide of hand. Once you are no longer on top of X11 drivers then you need to drive the monitor correctly so needing to expose a clock per monitor.

I don't notice such a thing vs. Windows so I don't need to care about what anybody says.

Of course not you have not checked windows properly either. Windows has 1 extra frame of lag that should not be there as well. When you compare two solutions that are both broken the same way you are not going to find a difference right. Some of the reason for bipass being required for VR class stuff is in fact this extra frame of lag.

What I notice is that on both Gnome and Sway XWayland games feel laggy vs. native Xorg without and with vsync. That is reality do date, not something else.

The problem is related, When the compositor under wayland has picked a frame rate the driver does not have the means to hack faster. So wayland compositors make the frame rate issues front and centre instead hidden. Of course the frame rate handling in the upper levels of X11 protocol has been broken the complete time.

Basically wayland compositors have been showing you how bad the problem really is once you strip away driver workaround.

Of course there are the libinput issues with gnome being not in it own thread and other issues making lag.

[aufkrawall]

Of course not you have not checked windows properly either. Windows has 1 extra frame of lag that should not be there as well.

Have a input-to-photon test at hand that shows this in exclusive fullscreen mode? If not, I don't believe it.

[oiaohm]

Have a input-to-photon test at hand that shows this in exclusive fullscreen mode? If not, I don't believe it.

Realy there is a in face issue in your input to photon results. Why at lower HZ you don't have cases input-to-photon test being always less than frame to frame milliseconds this is a direct issue of the extra frame that this does not happen.

Exclusive full screen mode vs DRM-lease on Linux in a input to photon test the DRM-lease shows lag running less than the frame to frame milliseconds. There is a reason why DRM-lease was made yes it possible for wayland to get to always having DRM lease class performance even when not in full screen mode.

Really you are asking me for test results when you should have them already and just need to look at them a little closer to notice the problem aufkrawall. Yes without the extra frame the difference between 120 to 360 HZ screens will reduce a lot for users.