Bug 101193

First, I don't think this is a Weston issue. Maybe this should be moved to Xwayland instead?

As for the scaling protocol mentioned in the GNOME bug report, it does exist: wl_viewport.

*If* Xwayland had some way of knowing that a Window should cover the whole output but the size is not a match, it could use wl_viewport to let the Wayland compositor do the scaling, which for a fullscreen game would hopefully translate into scaling in display hardware rather than a GPU rendering pass.

But, I would also expect problems with input event coordinates if wl_viewport is used naively.

Maybe Xwayland could support multiple resolutions via RandR by programming wl_viewport to scale everything back to the native resolution? Setting a mode via RandR would then be the trigger for switching the scaling settings in Xwayland globally.

It does feel to me it could be pretty difficult, I don't really know Xwayland that well.

As for Xwayland actually changing the real video modes on hardware, I'd rather not have that. Let's not make X11 RandR a Wayland compositor configuration interface. Likewise, 'xinput' is not a Wayland compositor configuration interface either.

(In reply to Pekka Paalanen from comment #1)
> First, I don't think this is a Weston issue. Maybe this should be moved to
> Xwayland instead?
> 

I must've click on Weston accidentally as it was next to XWayland.

> As for the scaling protocol mentioned in the GNOME bug report, it does
> exist: wl_viewport.
> 
> *If* Xwayland had some way of knowing that a Window should cover the whole
> output but the size is not a match, it could use wl_viewport to let the
> Wayland compositor do the scaling, which for a fullscreen game would
> hopefully translate into scaling in display hardware rather than a GPU
> rendering pass.
> 
> But, I would also expect problems with input event coordinates if
> wl_viewport is used naively.
> 
> Maybe Xwayland could support multiple resolutions via RandR by programming
> wl_viewport to scale everything back to the native resolution? Setting a
> mode via RandR would then be the trigger for switching the scaling settings
> in Xwayland globally.
> 
> It does feel to me it could be pretty difficult, I don't really know
> Xwayland that well.
> 

Personally I would like the RandR working on XWayland. I have HiDPI display and the non-HiDPI programs are suboptimal. I'd like to just set 1920x1080 instead of 4K for them and be done with them. I don't know XWayland that well but I assume it renders to texture at some point to pass to compositor - I imagine it could render lower-res texture onto highier-res so to present highier-res image to compozitor.

> As for Xwayland actually changing the real video modes on hardware, I'd
> rather not have that. Let's not make X11 RandR a Wayland compositor
> configuration interface. Likewise, 'xinput' is not a Wayland compositor
> configuration interface either.

Agree, at least partially. The most annoying thing is when game changes the resolution on exit of whole desktop. That said it might be needed for performance to use native resolution in full screen (this would be perf hack though, not configuration as it). That said I don't know (and most avenues I have would go under NDA) if this is the case and rendering texture might be fast enough.

(In reply to Maciej Piechotka from comment #2)
> Personally I would like the RandR working on XWayland. I have HiDPI display
> and the non-HiDPI programs are suboptimal. I'd like to just set 1920x1080
> instead of 4K for them and be done with them. I don't know XWayland that
> well but I assume it renders to texture at some point to pass to compositor
> - I imagine it could render lower-res texture onto highier-res so to present
> highier-res image to compozitor.

Yet another orthogonal approach coming to mind is having Xwayland use the output scale to divide the resolution it exposes to X11 clients. There is no way to detect which "buffer scale" X11 clients use for drawing, which means we pretty much have to just assume something, and scale=1 is the default. If the output scale was 2, the Wayland compositor would automatically scale up to 2x. This could work in the cases where the output is configured as HiDPI. I just wonder if it would break something.

> Agree, at least partially. The most annoying thing is when game changes the
> resolution on exit of whole desktop. That said it might be needed for
> performance to use native resolution in full screen (this would be perf hack
> though, not configuration as it). That said I don't know (and most avenues I
> have would go under NDA) if this is the case and rendering texture might be
> fast enough.

It should not be needed, not for fullscreen apps at least. The trick is to get the display device (CRTC) do the scaling on the fly, not changing the video mode (monitor scaling) and not using the GPU (rendering pass for scaling).

There are essentially two ways to tell the Wayland compositor to scale things: wl_viewport and output/buffer scales. Optimally the Wayland compositor will defer the scaling to the display device.

Achieving monitor scaling, i.e. temporarily changing the video mode, would need a Wayland protocol extension (which might be eventually developed anyway) and it might be a bit hard in the Xwayland case as it would then apply to all X11 apps, not just the one that used RandR. That might be awkward to use in practice.

What about changing modes not only for the resolution, but for selecting a different framerate, or a mode with a different flag such as interlaced?

(In reply to Jonas Ådahl from comment #4)
> What about changing modes not only for the resolution, but for selecting a
> different framerate, or a mode with a different flag such as interlaced?

Given that we don't even have a solution for Wayland native clients, it's a bit hard to see how Xwayland should be mapped there.

The first idea coming to mind would be to associate the RandR chosen mode with *all* Xwayland windows, perhaps with some per-output heuristics, and let the Wayland window manager do the same standard magic it would do with native Wayland windows.

That is purely because X11 has no per-window video mode thing, so Xwayland cannot know which window a setting should apply to.

(In reply to Pekka Paalanen from comment #5)
> (In reply to Jonas Ådahl from comment #4)
> > What about changing modes not only for the resolution, but for selecting a
> > different framerate, or a mode with a different flag such as interlaced?
> 
> Given that we don't even have a solution for Wayland native clients, it's a
> bit hard to see how Xwayland should be mapped there.

I think it'd make sense to come up with a native Wayland client solution can work with Xwayland too, just as with pointer locking vs pointer warping emulation.

> 
> The first idea coming to mind would be to associate the RandR chosen mode
> with *all* Xwayland windows, perhaps with some per-output heuristics, and
> let the Wayland window manager do the same standard magic it would do with
> native Wayland windows.
> 
> That is purely because X11 has no per-window video mode thing, so Xwayland
> cannot know which window a setting should apply to.

Just as with pointer locking. We simply try to guess what window. I guess for a video mode changing client, we could figure out what window should trigger a fullscreen based temporary mode by matching the client setting the mode, with a window that has the same size and position covering the whole monitor.

-- GitLab Migration Automatic Message --

This bug has been migrated to freedesktop.org's GitLab instance and has been closed from further activity.

You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.freedesktop.org/xorg/xserver/issues/703.