*** Bug 1286217 has been marked as a duplicate of this bug. ***

(In reply to Kamil Páral from comment #0)
> F) Crash - when configuring the game in the better case, on startup in the
> worst case
> Examples: Minecraft (according to bug 1287864, not tested)

Bug 1287864 is a bug in Minecraft itself, not something we can fix.

(In reply to Olivier Fourdan from comment #2)
> Bug 1287864 is a bug in Minecraft itself, not something we can fix.

Actually, a workarround for this was just added to Xwayland, included in xserver 1.18.3 so Minecraft should start in Wayland now (upstream).

This is still an issue in F25 (e.g. with openarena I can't change its resolution at all).

Well, for games using Xwayland this feature was denied:

https://fedoraproject.org/wiki/Wayland_features#XRandR_control_of_Wayland_outputs

That comment said it should be implemented in mutter, not Xwayland.

(In reply to Olivier Fourdan from comment #5)
> Well, for games using Xwayland this feature was denied:

Yes, and I understand why. However, the purpose of this ticket was whether we can find a different solution to this (because X11-based games will be with us for a long time still). For example:

(In reply to Kamil Páral from comment #0)
> For example, could we fake the resolution list for XWayland apps and if they
> try to set a custom fullscreen resolution, could we tell them it succeeded,
> but scale their output instead? (similarly to what we intend to do with
> Wayland-based games)

Is that doable (or something similar)? Is there a will and time to implement it?

I just like to add that a scaling solution as mentioned above would also heavily benefit wine games, probably a big factor.

Ok I started tinkering on this for fun and it looks surprisingly simple.
I changed xwayland in the xserver so it allows 1024x768 as resolution and mutter plays along quite nicely.
When changing the resolution in Warcraft 3, it properly resizes to that.
When minimizing the game and selecting again (this is not 100% reproducibly atm and probably a bug in mutter), the output even gets scaled up!

The input handling is limited to the official size of the window (1024x768 instead of 1366x768) thought, so I can't move the mouse to the far right anymore.

I'll try if I can make that behavior explicit in mutter and fix the input.

For those interested, here's some screenshots:
https://cloud.silentundo.org/s/7HnuNToHnvRBfcj

Little update:

If I understand everything correctly, mutter on X11 (or Xorg itself?) currently remembers randr settings for each application and sets them on focus change (e.g. taping out and back again).

We can maybe mirror that behaviour for xwayland, but instead of setting the resolution just apply a resize to the interface the application renders to and some sort of mouse coordinate wrapper.
I'll tinker on that a bit but I'm really slow as it's still hard for me how everything interacts and how many different ways there are to set the resolution.


The most clean solution would of course be to have one xwayland instance per application, but that will probably not happen anytime soon.

Ok I was totally wrong, the app always sets the resolution itself.

So the idea would be as follows: 
- make xwayland accept randr mode setting (not really setting it but remembering and reporting it on future request).
- make mutter check the set resolution when it sets an x-window to fullscreen on wayland. If the resolution is not the native one, take only the output of the reported resolution and scale it up to native size
- create a shim layer for mouse input that reports the current mouse position accordingly

This message is a reminder that Fedora 25 is nearing its end of life.
Approximately 4 (four) weeks from now Fedora will stop maintaining
and issuing updates for Fedora 25. It is Fedora's policy to close all
bug reports from releases that are no longer maintained. At that time
this bug will be closed as EOL if it remains open with a Fedora  'version'
of '25'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version'
to a later Fedora version.

Thank you for reporting this issue and we are sorry that we were not
able to fix it before Fedora 25 is end of life. If you would still like
to see this bug fixed and are able to reproduce it against a later version
of Fedora, you are encouraged  change the 'version' to a later Fedora
version prior this bug is closed as described in the policy above.

Although we aim to fix as many bugs as possible during every release's
lifetime, sometimes those efforts are overtaken by events. Often a
more recent Fedora release includes newer upstream software that fixes
bugs or makes them obsolete.

Created attachment 1355915 [details]
xwayland patch to enable some common resolutions

This is a small patch for xwayland to enable some common resolutions make xwayland accept/save the settings.
The rest probably has to get handled by the compositor (I'm focusing on mutter)

With the patch above applied, most applications somewhat work.

When fullscreened by mutter, all 3d-games I tested so far get scaled up well. What remains to be done here:
- when a fake resolution is set, mutter often doesn't set the fullscreen flag for the corresponding windows (or unsets them)
- mouse input is somewhat broken, needs some translation layer
- black-bar mode for resolutions not fitting the screen (should be relatively easy)


The 2d-games I've tested don't get scaled up right now. But that might have to do with the fact that all of them use legacy fullscreening, therefore mutter doesn't know how big they're supposed to be. If mutter knew, it should be easy.

I don't think making up modes in Xwayland is the right approach, it should retrieve those from the wl_output::mode given by the Wayland compositor (gnome-shell in this case).

Right now, gnome-shell doesn't list any but the current one, so adding this in gnome-shell would be a start.

But then Xwayland as of now ignores all modes but the current one (!), so you'd need to fix Xwayland to take thoise into account and list them in the available modes in XRandR.

  https://cgit.freedesktop.org/xorg/xserver/tree/hw/xwayland/xwayland-output.c#n102

But even with that in place, Xwayland would need a way to notify the Wayland compositor that one of its X11 client with a surface fullscreen has requested a different mode. However, We do not want Xwayland to control the output mode though (see https://fedoraproject.org/wiki/Wayland_features#XRandR_control_of_Wayland_outputs) as any XRandR client (including the command xrandr itself) would be able to change the modes in Wayland.

PS: I think you'd get probably more feedback and traction by discussing this upstream on xorg-devel and wayland devel mailing lists rather than in a bug downstream.

@Olivier Fourdan: thanks for the feedback, the reason I'm tracking it here is mainly for the fakt that it's not yet clear which components need to get changed (only xwayland or also mutter/the window manager).
But you're right.

For the other part: what I'm currently trying is exactly not to set the screen mode, as that is not supposed to happen under wayland. So xwayland should not tell the compositor to do that but only fake it.
The idea is to just scale up the output. That in turn makes it independent from the real modes the screen supports.
This feature overall is mostly about legacy support (old games which don't detect the actual screen resolution or don't know anything bigger than say 1024x768).

So we could add all supported screen resolutions, but I think it's important to make sure the most common ones are in the list (640x480, 800x600, 1024x768), as those basically are the ones which will get used.
Think of games like Diablo 2, Age of Empires 2, Counter Strike and the like.

Created attachment 1356127 [details]
Translate the mouse position when fake resolution is set

This patch translates the mouse position accordingly to the fake resolution. It assumes that, when a fake resolution is set, the window is fullscreen (therefore scaled up to the full screen size).
That would be the usual case.

Alright, with the two patches above everything on the xwayland side should be done, the rest probably has to get figured out on the compositor side (properly detecting when a window should get fullscreened, resetting the fake resolution if the application does not itself on quit etc.).

With these patches, I can already play most 3d-games with lower resolutions, like starcraft 2, source-engine based shooters (only the menu, shooters don't yet work in gnome/wayland, but that's another story) or the talos principle.

As soon as I have some mutter patches ready, I'll create a copr for those interested to test.

Created attachment 1358665 [details]
Translate the mouse position when fake resolution is set

Created attachment 1358678 [details]
Hack to make mutter fullscreen all games (unclean solution)

FWIW, I have just posted a patch for Xwayland to list all the wl_output::mode(s) advertised by the compositor as available XRandR modes, so that you wouldn't need to fake modes in Xwayland.

  https://patchwork.freedesktop.org/series/34628/

That works with weston which lists multiple available modes, but gnome-shell/mutter only lists the current mode.

Created attachment 1364382 [details]
mutter patch to expose some common resolutions (WIP)

With Oliviers patch (https://patchwork.freedesktop.org/series/34628/), xwayland exposes modes send by mutter. 
This makes mutter expose three hard-coded common modes. Actually it should expose all modes it would list in system-setting AND these modes (they are the most important modes for old games).

Created attachment 1364383 [details]
xwayland patch to accept fake modesetting

This makes xwayland fake/accept modes (WIP). Together with Oliviers patch and 1364382 (mutter patch to expose some common resolutions (WIP)), it makes it possible to launch games which don't work without modesetting, such as Diablo 2 over Wine.

Little status update of the todo list:
- make mutter expose all solutions it would in system-settings, in addition to some very import ones which are hard-coded so far
- implement wl_viewport. There's some old work here: https://mail.gnome.org/archives/commits-list/2014-November/msg00700.html
- make mutter add viewports to xwayland windows which don't have the screen resolution and want to become fullscreen
- done?

Created attachment 1364992 [details]
implement wp_viewporter (WIP)

This is based on old patches by Jasper St. Pierre, see
https://mail.gnome.org/archives/commits-list/2014-November/msg00799.html
and 
https://mail.gnome.org/archives/commits-list/2014-November/msg00800.html

This makes it work with gnome 3.26.2 and stabilizes it as wp_viewporter instead of wl_scaler.

It's not tested yet, but it builds :)

External bug-tracker for wp_viewport: https://bugzilla.gnome.org/show_bug.cgi?id=791405

And the external bug tracker for the xwayland part: using wp_viewporter to actually scale things.
https://bugs.freedesktop.org/show_bug.cgi?id=104643

Just for information, people who need a minimal solution for the problem can use the following copr with a patched mutter/xwayland which expose certain modes in xwayland. It doesn't include ongoing work to use the wp_viewporter protocol to actually scale things up, but it lets you start many games that otherwise would not.

https://copr.fedorainfracloud.org/coprs/treba/xwayland-list-modes/

Thanks, Robert, for working on this, much appreciated. Hopefully this gets into upstream.

This has finally been fixed in Xwayland, https://gitlab.freedesktop.org/xorg/xserver/merge_requests/270

Apps now start again. Viewport scaling needs some compositor help which will most likely land in Gnome-Shell 3.36, see https://gitlab.gnome.org/GNOME/mutter/merge_requests/739

Thanks for the update, Robert.

As Robert already explained fixes for this have recently landed upstream. I've just finished backporting these to Fedora 31's xorg-x11-xserver and mutter packages, so an update which resolves this issue will become available soon.

FEDORA-2019-103a594d07 has been submitted as an update to Fedora 31. https://bodhi.fedoraproject.org/updates/FEDORA-2019-103a594d07

mutter-3.34.1-6.fc31, xorg-x11-server-1.20.5-8.fc31 has been pushed to the Fedora 31 testing repository. If problems still persist, please make note of it in this bug report.
See https://fedoraproject.org/wiki/QA:Updates_Testing for
instructions on how to install test updates.
You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2019-103a594d07

FEDORA-2019-103a594d07 has been submitted as an update to Fedora 31. https://bodhi.fedoraproject.org/updates/FEDORA-2019-103a594d07

ClanLib06-0.6.5-47.fc31, mutter-3.34.1-6.fc31, xorg-x11-server-1.20.5-8.fc31 has been pushed to the Fedora 31 testing repository. If problems still persist, please make note of it in this bug report.
See https://fedoraproject.org/wiki/QA:Updates_Testing for
instructions on how to install test updates.
You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2019-103a594d07

ClanLib06-0.6.5-47.fc31, mutter-3.34.1-6.fc31, xorg-x11-server-1.20.5-8.fc31 has been pushed to the Fedora 31 stable repository. If problems still persist, please make note of it in this bug report.