Do you have examples of such games?

I don't really understand the question? This affects all games that use SDL

I've never seen a game try to fullscreen itself on anything but its current display. I looked at Baldur's Gate 3, Celeste, Counter-Strike 2, Elden Ring, Hollow Knight, and Outer Wilds and they do not allow the user to select a display.

This is about Wayland native games, not about Xwayland - where SDL checks the "primary" output, which many compositors set to make games behave at least somewhat sanely. Half the games you list even run through Wine, which does something similar too.

Do you have examples of such games?

All SDL games with the upcoming SDL 3, where Wayland support will be enabled by default. By extension, also all SDL 2 games when the compatibility layer to run it on SDL 3 is used.

Sorry I think I'm not saying clearly what I mean. I'm asking if there are any (many?) games out right now that have this kind of functionality (e.g. on windows) so that I can better understand the context.

I listed some popular games above that don't have this functionality.

If this is a widely used feature that many games depend on, then that puts this issue in a different light than if this is a feature that SDL offers but nobody actually cares about.

All SDL games pick a screen to be fullscreen on, it's not an optional thing in its API. To just pick the three games in my Steam library I played last, Counter-Strike 2 (win32, X11), No Man's Sky (win32, X11) and Spider-Man Miles Morales (Proton, X11), all launch on the screen marked as primary by Xwayland, instead of the screen they're launched on. No Man's Sky and Spider-Man also have settings for which screen they should use.

Curious. I tested CS2 and it always seems to launch on the currently active display.

That sounds like your compositor just ignores the output argument in xdg_toplevel.set_output? Or it sets the Xwayland primary thing to the currently active output

Since it's all running via Xwayland, I don't think any xdg_toplevel calls are involved. However, I also noticed that CS2 always launches windowed even if I set it to fullscreen in game. Possibly a CS2 issue since other Xwayland games fullscreen themselves at startup.

You've clarified below that this issue is about games that don't adapt to different resolutions and refresh rates when moved between outputs. I tried one native linux SDL game wich SDL_VIDEODRIVER=wayland and it did adapt when I moved it between screens with different resolutions when configured to run in exclusive fullscreen mode.

Therefore it would be good to have an actual example.

Xash3D doesn't reload avaliable resolutions when it moved to another output. It only enumarate resolutions for the output where window was created.

Are you talking about this: https://github.com/FWGS/xash3d-fwgs? That's not a game.

It's an open source game engine that is used to run Half-Life, Counter-Strike, TF classsic and derivatives.

Thanks, I was able to reproduce the issue with Counter-Strike. Is there a way to make the engine use wayland or is it X only?

It should follow SDL_VIDEODRIVER=wayland hint and if you're on SDL3 with sdl2-compat and compositor supporting fifo-v1 it should use Wayland by default.

I guess the SDL version shipped with Counter-Strike in steam is too old, but SDL_VIDEODRIVER=wayland did work.

If I set the mode of one of my monitors to 640x480, the game indeed only shows a maximum of 640x480 in the video settings even if I move the window to a 1920x1080 monitor. However, if I set the game to windowed, it renders at 1920x1080 even if the setting shows 640x480.

Are there any games that don't have such a workaround?

vkQuake doesn't change resolution list no matter what you do. It will only enumarate resolutions from primary screen. Turok doesn't allow resolutions higher than from primary's monitor either. Both games render at their maximum capped resolution. That was for SDL-based games. GLFW-based games such as re3/reVC are also suffering from this when they enumerate resolutions only for the primary monitor.

Can we maybe not name this preferred, but default or something else? After all the compositor doesn't really prefer apps to be placed there.

For cosmic this would expose the focused output, which is not optimal given we want to avoid applications inferring focus and building hacky workarounds with that information. I feel like this might just be enough to give some application developers some weird ideas, but I also don't see a much better option without updating the SDL api.

Just to understand this properly: Games would still need an updated SDL version to make use of this protocol, so this is to aid... porting? Instead of forcing game developers (and engine developers I assume) to use some new api to pass a null output? I would hope such an api could be added in a way, where on other platforms it just selects the first output, so are there really downsides to add just that?

Apps doing stupid things with this is my number one concern as well, but as long as this is tied to a surface / xdg_toplevel, and specifically about games, I think it should be relatively safe.

Just to understand this properly: Games would still need an updated SDL version to make use of this protocol, so this is to aid... porting? Instead of forcing game developers (and engine developers I assume) to use some new api to pass a null output?

SDL has wrappers for its old versions; there's sdl12-compat for running games using SDL 1.2 on top of SDL 2, and there will be the same for running SDL 2 games on SDL 3.

Games that don't statically link SDL2 and instead ship in the Steam runtime or use the system libraries when available would also get an updated SDL2 version that uses this without doing anything.

I would hope such an api could be added in a way, where on other platforms it just selects the first output, so are there really downsides to add just that?

Yeah, that would be good, but it's still up to games to use it. As it's shorter than something like set_position(outputs[0]->position); set_fullscreen(), maybe it would get adopted a lot, but I frankly don't have that much faith in game developers to use the correct APIs.

Could SDL expose a fake "preferred" output that doesn't really exist, appears first in the list, and results in a set_fullscreen request with a NULL output?

That's an interesting idea. As many games are really dumb about outputs and fullscreen modes, I'm not sure if that would break some of them though, because you can't expose the "correct" modes right away.

Then you have an app that lists screens and is trying to put things explicitly across multiple screens and now that goes wrong.

#153 has prior discussion about a concept of a "primary" display. But for presentations.

Generally the idea seems a bit problematic to me. "Primary" display is somewhat ill defined, and not always something the compositor has a good idea of either.

• If I have a desktop with two identical monitors, which is "primary"? If a compositor has a concept of a primary monitor, one of them will be considered primary, but this can seem somewhat artificial.
• If I plug my laptop into a monitor, does the laptops display continue to be considered "primary"?
  • But if I plug a monitor into my laptop and then start a game, I almost certainly want to run it on the external monitor.
• If this protocol exists, and is also used for presentation software... is the "primary" display the one connected to the projector, or the one the presenter is looking at?
  • Probably you'd want the external display to show a presentation or a game, but the word "primary" doesn't really fit.

I don't know how best to deal with this in SDL, but it definitely seems like games should just launch on the output they are opened on. And it doesn't really make sense to have a Wayland protocol only to have a slightly-less-bad fallback than having SDL itself guess which output to use.

This is explicitly not about a "primary" display! Quite the opposite, this issue was originally motivated by SDL getting code to abuse the kde_output_order protocol for this purpose. The goal is that game toolkits don't do things like that.

It's also not about presentation software, or anything else except games.

it doesn't really make sense to have a Wayland protocol only to have a slightly-less-bad fallback than having SDL itself guess which output to use

The compositor does not guess which output things go on, it's a big part of its job to decide exactly that.

Ah, I guess I missed this part:

effectively a racy version of xdg_toplevel.set_fullscreen(null)

It seems a bit odd to have a protocol that mainly just exists as a workaround for applications not being able to properly use set_fullscreen(null). Though it could also be useful if applications show a list of displays (not sure I've actually seen that before), to have a sane default that can be marked explicitly.

Though it could also be useful if applications show a list of displays (not sure I've actually seen that before), to have a sane default that can be marked explicitly.

I don't think so, the better default would always be the one that the UI is currently shown on.

This is really exclusively about working around games, there's no long term use case or purpose for this outside of that. I'd expect most compositors to just pick the output the window would be placed on with xdg_toplevel.set_fullscreen(null) anyways.

As a user, I would really like to have a primary screen support in Wayland. Many Wayland compositors already have the concept of primary screen, and adding the corresponding protocol to Wayland would be only natural.

Right now, I'm experiencing a bug where SDL2 and GLFW games put themselves on a random screen because they use first reported wl_output and outputs order doesn't actually mean anything and changes each boot.

wayland_bug3

The ideal solution would of course be that SDL just uses a null wl_output in the xdg_toplevel.set_fullscreen request

That wouldn't be an ideal solution because game launchers like Lutris and Steam could be placed on a screen other than primary, and launching games on that screen might be undesirable, especially when it's rotated screen which could even break the game forcing the user to restart it. Here's the demonstration of that behavior:

Kooha-2024-06-27-19-55-33

That wouldn't be an ideal solution because game launchers like Lutris and Steam could be placed on a screen other than primary, and launching games on that screen might be undesirable, especially when it's rotated screen which could even break the game forcing the user to restart it. Here's the demonstration of that behavior:

null doesnt mean fullscreen on the current output of the window (this is an entirely new process anyway in your example) or the last interacted window. It means the compositor will choose the output how it sees fit. If it has the concept of "primary" display it could very well do that.

People already start experiencing discussed issues with Wine-Wayland driver: https://bugs.winehq.org/show_bug.cgi?id=58316 Once SDL3 will start defaulting to Wayland (compositor with fifo support) people will start experiencing this with SDL as well.

Wine Wayland window only opens on "monitor 1" and cannot be moved

Compositors not having a clear UX how to move fullscreen windows is a compositor issue that should be fixed in the compositor. If there was a "primary monitor" property, the user would run into the same issue if they wanted to play that particular game on a different monitor.

The primary issue is that game goes on the secondary monitor because wine-wayland has no way to determine what monitor is primary so it selects first reported wl_output (well, at least SDL does, wine-wayland currently sorts monitors from left to right, but I think it will be changed in the future to match SDL behavior). First reported wl_output doesn't represent primary monitor, on KWin Wayland the order of reported wl_outputs matches the order of physical connectors on the GPU. Other compositors might have different logic for wl_outputs order, but there's no guarantee that first reported wl_output would be the primary screen. GNOME and KDE have concept of primary screen, but there's no wayland protocol to expose that to clients.

The primary issue is that game goes on the secondary monitor because wine-wayland has no way to determine what monitor is primary so it selects first reported wl_output (well, at least SDL does, wine-wayland currently sorts monitors from left to right, but I think it will be changed in the future to match SDL behavior).

That would be an SDL bug. The ordering of wl_output globals has no significance. It can also change randomly e.g. after suspend.

SDL should be not be passing any wl_output in this case. Applications such as SDL should almost never use wl_output as discussed in wayland#458.

SDL should be not be passing any wl_output in this case. Applications such as SDL should almost never use wl_output as discussed in wayland#458

That's not SDL bug, SDL doesn't even allow selecting display index in SetWindowFullscreen. That's how developers use SDL's public API which described in #179 (comment 2293912) Real life example: https://github.com/yquake2/yquake2/blob/3dbd58e0b82dea9ed4c7d3cdeefa05d74ba11793/src/client/vid/glimp_sdl3.c#L126

Wine-Wayland also can't do that because that's not how applications relying on win32 api work.

Ideally I think there should be request called get_primary_screen which will produce event primary_screen(output: object<wl_output>). That would solve all SDL and Wine-Wayland problems.

You said that

wine-wayland has no way to determine what monitor is primary so it selects first reported wl_output (well, at least SDL does

If SDL does select one of the monitors in this way and then advertises it to applications as the primary monitor, and that causes applications to misbehave, then that is an SDL bug. It can't be a compositor bug because the compositor does not claim that any monitor is primary. It cannot be an application bug, because it just listens to what SDL tells it.

If SDL doesn't actually do that and it's just some applications retrieving the full list of monitors and then treating the first one as primary, then sure, that's not an SDL bug.

@mahkoh Earlier you asked for an example of a game, if you're still interested you can have a look at Factorio

https://forums.factorio.com/viewtopic.php?p=657943#p657943

I tested the SDL3 "GetPrimaryDisplay" function and it doesn't appear to be any more reliable than our existing Vulkan method. The reality is that Wayland simply doesn't have the concept of a primary display and Factorio trying to specify a display to use is never going to work well on it.

It can't be a compositor bug because the compositor does not claim that any monitor is primary.

That is the problem: compositors can't claim any monitor as primary even if they have concept of primary monitor (Plasma and GNOME definitely have).

SDL has GetPrimaryDisplay function which works just fine on other platforms because they expose their primary display to clients, but on Wayland we can't do that.

Just chiming in here after reading these threads, the question to me is maybe asked better like this, in this case more specific to wine-wayland as I have actually used it hands on:

What is the UX for a fullscreen wine-wayland game expected to be?

Keeping in mind most games I encounter query screen modes exactly once (on launch), and do not offer monitor selection in game.
So just "moving" the game would not actually solve the issue, as if the two screens differ in modes, the game will offer wrong resolution options.
The game must initially launch on the correct monitor, so it can query the correct screen modes.
If you want examples: Dyson Sphere Program, ULTRAKILL, ... (pretty much any Windows game without monitor selection will be hit by this if it tries to run borderless or fullscreen)

Would the desired solution here be "Wine should offer its own way to pick what monitor to launch a game on"? Say, via environment variables or similar, rather than solving this with a Wayland protocol?

The primary issue is that game goes on the secondary monitor because wine-wayland has no way to determine what monitor is primary so it selects first reported wl_output (well, at least SDL does, wine-wayland currently sorts monitors from left to right, but I think it will be changed in the future to match SDL behavior). First reported wl_output doesn't represent primary monitor, on KWin Wayland the order of reported wl_outputs matches the order of physical connectors on the GPU.

SDL2 picks the first output from the order in which they were received, which can be completely random as the order often isn't stable across sleep-wake cycles on some compositors.

SDL3 sorts displays from top-left to bottom-right, so the order should be stable unless the desktop is reconfigured, and tries to pick a primary by making a guess as to which display is "best", based on the capabilities that a game cares about (resolution, HDR, landscape vs portrait) for the reasons mentioned in the post above. There is also a hint that can be set if the user wants to manually override the selection logic. If you have multiple, identical displays, it falls back to the display at 0,0 though, so it's not perfect and will still be wrong if you have, for example, three identical displays with the primary in the center, but it's better than the random order in SDL2.

It can't be a compositor bug because the compositor does not claim that any monitor is primary. It cannot be an application bug, because it just listens to what SDL tells it.

It's not a bug, it's a missing feature. The reality is that there's a ginormous catalogue of clients that expect to be given a primary display, Do you not think that that should be handled by a wayland protocol instead of a 3rd party like wine or each DE?

The reality is that there's a ginormous catalogue of clients that expect to be given a primary display

Win32 allowing applications to act as keyloggers or reposition themselves arbitrarily is not a very convincing argument to me for allowing wayland applications to do the same.

You made a good argument against having such a concept:

Unfortunately since windows has the option for users to select a primary display many games expect that to be available and will use the primary display to limit their render resolution to that of the display.

Which will not work if the user uses a 1080p monitor as their primary display but wants to play games on their 4k TV that is connected to the same PC.

Win32 allowing applications to act as keyloggers or reposition themselves arbitrarily is not a very convincing argument to me for allowing wayland applications to do the same.

I'm sorry but you completely lost me, I don't see the connection between a primary display protocol and keyloggers.

Which will not work if the user uses a 1080p monitor as their primary display but wants to play games on their 4k TV that is connected to the same PC.

That is true and would mean the user has to select their TV every time they swap between playing on it and on their 1080p display which definitely isn't ideal, but it's certainly better than the current behavior which is essentially randomness. Also, at that point it would be the fault of the client for not allowing display selection rather than the compositor for missing a feature.

Please understand that many of these games are abandon-ware at this point, and the ones that aren't won't be getting new features to appease their (relatively) tiny linux audience

I still don't understand why you would want to handle this anywhere other than the compositor

I'm sorry but you completely lost me, I don't see the connection between a primary display protocol and keyloggers.

The argument that you are using, that there are lots of applications (usually running via wine) using a win32 feature, can and has been used to argue for lots of things that are not done in wayland.

I still don't understand why you would want to handle this anywhere other than the compositor

I'm saying that applications should never tell the compositor how to position them. Instead they should tell the compositor what they are (a game) so that the compositor can make an intelligent decision about how to position them. In the example above, the user might configure their compositor to put all fullscreen games on their TV.

The content type hint protocol can already been used for this but it looks like at least the SDL version used by factorio does not use it. And it might not work for wine-wayland at all.

As someone using two monitors with primary monitor on the right I'm basically already doing this. Every game I play launches on the left monitor and I have to drag it over or select the correct monitor in the in game settings.

using a win32 feature

It's not an exclusively win32 feature. X11 and macOS have it as well.

I'm saying that applications should never tell the compositor how to position them.

We already have output: object<wl_output> argument in xdg_toplevel::set_fullscreen request though.

The content type hint protocol can already been used for this but it looks like at least the SDL version used by factorio does not use it.

Content type is a Wayland specific protocol that makes little sense in cross-platform API such as SDL. It would require application developers to explicitly support that feature because SDL used not only by game developers (mpv, scrcpy).

The argument that you are using, that there are lots of applications (usually running via wine) using a win32 feature, can and has been used to argue for lots of things that are not done in wayland.

The fact that this argument was used before doesn't negate the fact that there are many users that need this feature, please actually address that. Especially with how this feature is already built into most DEs and just needs to be supported by the backend.

I'm saying that applications should never tell the compositor how to position them. Instead they should tell the compositor what they are (a game) so that the compositor can make an intelligent decision about how to position them. In the example above, the user might configure their compositor to put all fullscreen games on their TV.

Even though I disagree with it, I see how that could be a good system for positioning.

My argument isn't about positioning though, its about the fact that most games lock their maximum resolution to that of the primary display. So in the example you gave me with the 1080p monitor and the 4k TV, the game will either (1) lock its maximum resolution to 1080p even when moved to the 4k TV or (2) it'll lock its maximum resolution to 4k and then the user will have to manually change it to 1080p when swapping displays.

Please remember that currently the user has no control over which of these 2 options happen to them. Unless they somehow found this thread they can (as Frank detailed earlier) move their desired primary display to be the one top left every time they want to play something.

The fact that this argument was used before doesn't negate the fact that there are many users that need this feature

Maybe so, but people say the same about those other features. People have been making well-thought-out arguments for why wayland needs absolute positioning for the sake of compatibility for many years. The topic has been thoroughly explored by its advocates. And yet, it has gone nowhere in terms of protocol support. Arguing from the point of compatibility with ancient windowing systems has a large negative multiplier in terms of effectiveness, in my experience.

You're saying that

most games lock their maximum resolution to that of the primary display

which I don't believe but let's say it is so. Such games are broken by design on windows. Arguing that wayland should be enhanced such that

1. such games can be broken as designed on wayland as well
2. in the future new wayland-native applications can be written that are broken in the same way (you're making it sound like a popular design, after all)

doesn't appeal to me.

You've also not explained why copying windows is the only possible solution or even close to the best solution (although that might have been discussed elsewhere in this issue.) Maybe it would be better if wine or SDL just lied to such applications about output capabilities such that they work well on all connected monitors.

such games can be broken as designed on wayland as well

I don't see why that form of '"broken" by design' is better than 'non-functioning by stubbornness'. I agree it's dumb, why not make it at least usable?

in the future new wayland-native applications can be written that are broken in the same way (you're making it sound like a popular design, after all)

I can't argue with you admitting that you want current software to stay broken for the sake of influencing future software (which in regards to the gaming industry I doubt would happen). I just think that's a wrong thing to do.

You've also not explained why copying windows is the only possible solution

Because thus far no other solution was suggested.

Maybe it would be better if wine or SDL just lied to such applications about output capabilities such that they work well on all connected monitors

That workaround would probably work but leads to a degraded UX, especially since they tend to use the primary display's resolution to adjust graphics settings on startup and would make the user need to adjust the resolution with each new wine program and every time they swapped display. I think it's a better experience to allow the user to select their preferred display once and forget about it.

Also, please consider that what I'm suggesting is that we continue the current expected behavior that (from my understanding) is already implemented in most DEs through xwayland and any suggested change to this behavior should need to be good enough (or at least as good as the current behavior) to warrant the friction that changing this behavior would necessarily cause to users.

Because thus far no other solution was suggested.

Pretend that any display is the one the app wanted to be on, and then wl_viewporter it.

Hello, I am Factorio's Linux developer. From the Factorio point of view, users expect a game to launch in fullscreen on their primary display. This is simply a fact, and no amount of arguing about whether or not primary display "makes sense" in Wayland will change that. Right now, what is considered as the "primary" display is undefined on Wayland, which leads to a bad user experience because the game will randomly change which display it launches on.

SDL2 does not have a function to query the primary display, so we either use the first one returned (arbitrary on Wayland) or the one at 0,0 (which is incorrect in my setup because my primary display is on the right). SDL3 has some smarter heuristics, including querying DBUS for Gnome's primary display, but this does not work on all compositors. We have received bug reports from Wayland users about inconsistent window positioning.

Aside from Factorio, another game that suffers from this is Cogmind. The game queries the primary display to figure out the dimensions of the window, and builds the UI around that. The game window cannot be resized, so in cases where the returned primary display is incorrect, the UI size is simply incorrect:

Now, should the game make its window resizable and dynamically resize the GUI based on what the user sets? Sure. But that is not what is happening here, and in many cases of legacy and/or unsupported games, there is no solution other than correctly exposing this information on the Wayland side.

Every desktop environment that I can think of has the concept of a primary display, and many many programs assume this to be the case, so I do not agree with any argument that it does not belong in Wayland. I can't think of any setup, practical or theoretical, where a primary display should not be defined.

users expect a game to launch in fullscreen on their primary display

You don't get to speak for all users. In fact, wayland was designed to give the compositor and thus user control over this, not the application. You want to take away the users control by forcing the window management behavior to conform to what you want, not what any particular user wants.

Stating things as fact which are in fact not facts is not going to get you anywhere.

Pretend that any display is the one the app wanted to be on

That's irrelevant to this issue, this is about giving the app the correct "primary" display so it can use it to limit its render resolution instead of going off of a random display like it currently does.

Even if you disagree that apps should be allowed to set their own positions you cannot ignore the fact that they need to know what the users' preferred primary display for other important reasons.

Right now, what is considered as the "primary" display is undefined on Wayland, which leads to a bad user experience because the game will randomly change which display it launches on.

Does SDL support not specifying the display on which to go fullscreen? If no screen is specified in the wayland request, then the compositor will choose the screen which will likely lead to more desirable results than choosing a random display. E.g. if factorio is launched from steam, then it will likely go fullscreen on the same display that contains steam.

Right now, what is considered as the "primary" display is undefined on Wayland, which leads to a bad user experience because the game will randomly change which display it launches on.

That is not true. It will launch on the display the compositor wants it to launch on, which by extension is what the user has chosen.

If users are unhappy with what display something gets fullscreened on, they can and should take that up with their compositor.

You as an application developer have no say in what the desired window management behavior is for any particular user.

You want to take away the users control by forcing the window management behavior to conform to what you want

You as an application developer have no say in what the desired window management behavior is for any particular user.

I think there is a misunderstanding happening here, no one here is arguing that apps should be allowed to dictate their positions to the user.

We want a user defined primary display that apps should be given for their own internal uses, such as render resolution and UI scaling, and many apps expect to be told which display that is on startup.

e: before the parent post was edited, it left out the crucial part that some non-native apps want this information beforehand

That is not true either. You get the size of the fullscreen when you go fullscreen, so any wayland client can render at the right resolution and apply the right UI scaling.

many apps expect to be told which display that is on startup.

That is the crux here. They are not wayland apps, because wayland apps have to deal with it at runtime.

In fact, there is no way around dealing with it at runtime because compositors can move the fullscreen window to any monitor at any time. What people are proposing here doesn't even fix the issue.

If you use SDL or Vulkan WSI right, you are forced to deal with "the size of fullscreen changing". Factorio uses SDL and should be able to do this. So the only thing they are complaining about is that there are some compositors who do not do window management as they want window management to be done!

That is the crux here. They are not wayland apps, because wayland apps have to deal with it at runtime.

Yes. Wayland is missing that feature, which is causing compatibility issues with many older apps and we want to add it.

In fact, there is no way around dealing with it at runtime because compositors can move the fullscreen window to any monitor at any time.

We are explicitly talking about apps that don't support that. If they get moved and break that would be their fault, as opposed to the compositor missing a feature that is available on virtually every single desktop environment which would be wayland's fault.

I apologize for crossing wires between resolution and positioning. I will put aside the positioning issue, as that is separate and has been beaten to death numerous times.

Factorio is a native Linux (and native Wayland) game, so I am willing to conform to some Wayland behaviors, in this case by removing our in-game display selection feature. We also natively support window resizing and our UI is fairly responsive to this.

However, the vast majority of games are Windows games running via Proton, so these games do not take into account the Wayland way of things whatsoever. They expect to be able to query the primary display before startup to set their resolution and aspect ratio, but we don't have that concept, so it leads to undesirable behavior. See the Cogmind example above.

My main point of confusion is why not have this in Wayland? I cannot think of any situation where a compositor would not benefit from being able to specify a primary display. Even in esoteric cases such as VR, it would be beneficial for the compositor to set the VR "display" as the "primary" so that games don't think they are being launched on a separate 2D monitor that the compositor might have connected at the same time.

My main point of confusion is why not have this in Wayland?

For the record, as far as I know, this feature is CURRENTLY AVAILABLE for xwayland apps on all the popular desktop environments including KDE and gnome.

Does SDL support not specifying the display on which to go fullscreen?

No, it always specifies display when setting window fullscreen: https://github.com/libsdl-org/SDL/blob/d7939abf42de34fff409f5e7c4b77ace79dff4de/src/video/wayland/SDL_waylandwindow.c#L626

On Wayland it tracks internal window position and then set window fullscreen on a monitor where window would be if it could change its position. Most applications ask for primary display, move their window to primary display and then set window fullscreen. On Wayland they don't know what display is primary so they "move" to wrong screen and ask to be fullscreen and SDL.

You can't use null in xdg_toplevel_set_fullscreen in SDL because it would break applications that have UI option to choose display (Factorio has such functionality for example).

We also natively support window resizing and our UI is fairly responsive to this.

So, just for the record: this is not a wayland issue! Everything works well and as designed.

You can't use null in xdg_toplevel_set_fullscreen in SDL because it would break applications that have UI option to choose display (Factorio has such functionality for example).

SDL has chosen to provide an API that we told them is not going to work well on wayland. Go complain to them and tell them to fix their API.

Although there is SDL_WINDOWPOS_UNDEFINED introduced in SDL3 that would get window pos from windowing system and when setting window fullscreen it will go on the display selected by compositor. Yet it's an SDL3 feature that developers must use explicitly. Applications that work through SDL2 and SDL12 compatibility libraries would never get this fixed. I've implemented such mechanics in Xash3D: https://github.com/FWGS/xash3d-fwgs/pull/2010

Letting compositor blindly decide where to put our game windows isn't right either: we have output: object<wl_output> argument in xdg_toplevel::set_fullscreen for a reason. Currently, most compositors put new windows on active display. What if I open the game on my secondary rotated monitor, and it will indeed open on the secondary rotated monitor? Was it really my choice as user? Should've I move to my "primary" screen before launching the game?

Also, GLFW suffers from similar problem https://github.com/glfw/glfw/pull/2583. I've made a hack that unsets output just lie from xdg_toplevel_set_fullscreen but it basically kills any multimonitor support of this library.

Letting compositor blindly decide where to put our game windows isn't right either: we have output: object<wl_output> argument in xdg_toplevel::set_fullscreen for a reason

Yes it is right. It is a hint after all.

What if I open the game on my secondary rotated monitor, and it will indeed open on the secondary rotated monitor? Was it really my choice as user?

That is between the user and its compositor, not your game.

Everything works well and as designed.

I wouldn't say that apps that run perfectly well through xwayland suddenly breaking (by limiting their render resolution to that of a random display) because of a missing feature is well and working as intended...

Just to clarify, do you have any reason for why this shouldn't be added for compatibility?

Applications being broken and not conforming to what wayland requires isn't an issue with wayland, it's an issue with applications.

Let me rephrase that: wayland works well and as designed.

You haven't answered my question.

Do you have any reason for why this shouldn't be added for compatibility?

1. It doesn't solve the issue
2. You can work around this in the compatibility layer to some degree
3. It takes away control from users

That is between the user and its compositor, not your game.

1. I've set up primary screen in my compositor
2. I launch the game that I know for sure should go to the primary screen
3. It goes on the secondary screen

Again, what as a user I did wrong and what my compositor did wrong when it presented me with primary screen option? Again, if we would simply have request called get_primary_screen which would produce event primary_screen(output: object<wl_output>) there would be no such issue and the usecase that was working for almost 20 years on other platforms would work on Wayland too.

1. It doesn't solve the issue
2. You can work around this in the compatibility layer to some degree
3. It takes away control from users

1. The issue is explicitly and directly caused by the fact that wayland doesn't have a primary monitor feature.
2. Why should it be up to the compatibility layer to dictate to the user what apps will think their primary display is? By moving this to the compatibility layer you are directly taking control from the user.
3. The control is currently given to the user through the primary display selection implemented by the desktop environment, implementing this in wayland would give the user control over this through the compositor.

It takes away control from users

How is it taking away control from me as a user when it's me who sets the primary screen (and I set it for a reason)? It is in the current situation I have no control where my fullscreen game would go because it's clearly dictated by dark magic of my compositor which decide in which order to present wl_outputs to the client, and then it obeys client's decision (which had no means to make a right decision to begin with).

How about this scenario:

1. I've set up primary screen in my compositor
2. I launch the game that I know for sure should go to the secondary screen
3. It goes on the secondary screen

Now it works exactly as I want, and it goes against what you want to make mandatory behavior.

1. I've set up primary screen in my compositor
2. I launch the game that I know for sure should go to the primary screen
3. It goes on the secondary screen

Then your compositor isn't doing what you want it to do.

This is becoming a rather stupid discussion tbh.

This is becoming a rather stupid discussion tbh.

I agree, I don't see why you keep bringing this back to positioning, as I said before:

This feature would only mean giving the apps a user selected primary display id that the app could use for its own internal uses, such as render resolution and UI scaling.

Please stop bringing the conversation back to positioning.

Applications being broken and not conforming to what wayland requires isn't an issue with wayland, it's an issue with applications.

I fundamentally disagree with this ideology. This statement can be true for applications that natively support Wayland, but we are primarily talking about Wine-based games. They expect things to work the Windows way, which Wayland is fundamentally incompatible with.

By standardizing a feature that the big three desktop environments already implement anyway, it will encourage all compositors to implement this behavior to give a more consistent user experience, and fix the fundamental issue we are facing with these games, which by their nature, will not make changes to conform to the behavior of a platform that they don't even support in the first place (with the exception of Factorio).

This feature would only mean giving the apps a user selected primary display id that the app could use for its own internal uses, such as render resolution and UI scaling

Neither of those are considered desirable on wayland. To put it concisely: wayland is a surface-oriented protocol, not an output-oriented protocol. Wayland has protocols to tell each surface individually what resolution and scale they should render at. It is not possible for applications to determine these values themselves based on outputs.

This feature would only mean giving the apps a user selected primary display id that the app could use for its own internal uses, such as render resolution and UI scaling.

Then all of the render resolution and UI scaling is wrong, if the primary display is not the one I want the game on.

This doesn't fix anything.

By standardizing a feature that the big three desktop environments already implement anyway

So, we're back here again. "Because Windows does it."

So, we're back here again. "Because Windows does it."

I was referring to GNOME, Plasma, and COSMIC.

I was referring to GNOME, Plasma, and COSMIC.

Sorry, I misunderstood then. This doesn't change anything though. Fullscreening all clients on the primary monitor might be what we do currently, but that certainly doesn't mean that this is what we want to do forever and for all clients.

Neither of those are considered desirable on wayland

Your philosophical arguments do not change the fact that you want to break compatibility with many apps. Are there any reasons to actually justify breaking compatibility? A user whose games are rendering at 720p on their 4k display doesn't care about that.

So, we're back here again. "Because Windows does it."

You're hand-waving away what people are saying without actually addressing them, so I ask both of you again:

Why should control over this be handed to the compatibility layer instead of staying with the user through the compositor?

Your philosophical arguments do not change the fact that you want to break compatibility with many apps

Something that never was can't be broken

Fullscreening all clients on the primary monitor might be what we do currently

You are bringing this back to positioning again...

Please stop bringing the conversation back to positioning.

How does it help if there is a primary monitor if that is not the intended target? It's just as random as guessing.

Something that never was can't be broken

As I said before, these apps currently work through xwayland and identify the correct user-selected primary display.

How does it help if there is a primary monitor if that is not the intended target? It's just as random as guessing.

It's not as random as guessing and It would help by solving the issues I detailed above.

The primary display is user-selected and going off of what you said before so is the primary target.

I would argue that if the user selects a primary output through their DE, then they will be more likely to expect clients to make decisions based on that. This is in contrast to the current situation, where clients make a decision based on a completely arbitrary output that the user has no control over.

It's not as random as guessing and It would help by solving the issues I detailed above.

No it doesn't. You just like to pretend that somehow everyone wants their games to always run on the primary display.

If you give up that assumption, it becomes equal to randomly guessing.

Both of you keep repeating this. This is "hardcoding" window management expectations and taking away user control because now apps only work well in fullscreen on your primary display, not any other one that the user actually wants it to be on and work well.

No it doesn't. You just like to pretend that somehow everyone wants their games to always run on the primary display.

I already addressed this before here and you are correct, this means that for these games the user would have to select a new primary display which isn't ideal but it's definitely better than the current behavior which is that the game will select a display at random and limit its render resolution to that display.

Do you have any other solution to this incompatibility that doesn't involve a degraded UX or taking control over this behavior away from the user and handing it to the compatibility layer?

but it's definitely better than the current behavior

Only if you, as you still do, and I repeatedly told you, assume that the primary display is somehow relevant to where the user wants the fullscreen thing to be. That is the flawed assumption you still don't want to let go.

Do you have any other solution to this incompatibility that doesn't involve a degraded UX or taking control over this behavior away from the user and handing it to the compatibility layer?

Start the thing on the monitor the user want it to start. If it doesn't match what the game chose, scale the thing for it to fit on the actual monitor. Let the user select the right monitor in the application or through the compatibility layer.

Start the thing on the monitor the user want it to start. If it doesn't match what the game chose, scale the thing for it to fit on the actual monitor

I think there's a misunderstanding, where ever it starts is irrelevant. What matters is that once it does start it will limit its internal rendering resolution to that of the primary display, Even if you rescale and move it the internal rendering resolution will still be capped to that of the display it thinks is the primary.

Let the user select the right monitor in the application

Please remember that we are talking about games that don't allow that and are essentially abandon-ware. If the user could do that we wouldn't be here...

or through the compatibility layer

That means handing control to the compatibility layer over something that is currently controlled by the user through the compositor

That means handing control to the compatibility layer over something that is currently controlled by the user through the compositor

No, it's not. The primary display has nothing to do with the display the user wants a fullscreen thing to run on.

I've repeated this for more than 10 times already and you still use this in all of your arguments. I'm done having this conversation.

The primary display has nothing to do with the display the user wants a fullscreen thing to run on.

I've repeated this for more than 10 times already and you still use this in all of your arguments

That doesn't address the fact that applications expect to be given one for their internal uses. The control I'm speaking about in that sentence is the control over which display the applications will think is the primary one and use for things like resolution and UI scaling.

Currently the user controls what display these applications think is the primary through the compositor (communicated to the application through xwayland) and you want to change that so it's controlled by the compatibility layer, I'm asking if you have any reason why that's better, especially considering the fact that this is already implemented in every major DE

It is probably time to put this issue to the side for a while

No, it's not. The primary display has nothing to do with the display the user wants a fullscreen thing to run on.

Except that it does - this has literally been a pattern in desktop environments for decades, and I have users who actively expect this to be the case.

It is probably time to put this issue to the side for a while

I agree that we are talking in circles at the moment, but I would hate to see this issue rot for another year with no forward progress. This is a real issue with real consequences for users.

In that vein, here's an alternative idea: Wine will determine which output it is opened on, and expose that output and that output only to the underlying game. If the game runs on SDL, this would have the effect of SDL_GetDisplays only returning that output, and SDL_GetPrimaryDisplay also behaving correctly. This way, the user could use a compositor's existing infrastructure (i.e. window rules on Sway) to determine where it goes, leaving the power in the user's hands.

I am not a Wine developer, so I can't speak as to the feasibility of this approach on their side, but it is an alternative. This also doesn't solve the issue of moving the fullscreen game between outputs after it is launched, but I don't think there is a good solution for that.

I have done something similar in the past with misbehaving games by wrapping the game with gamescope and manually specifying a resolution. It's ugly, but it works pretty well.

As for Factorio, I am going to go ahead and entirely remove the display preference setting when running on Wayland, since it is not reliable.

Just for the record: COSMIC does not have a concept of a primary display by design.

It does have an Xwayland compatibility setting to set what X considers its primary display via RandR specifically to avoid bugs in legacy applications.

We do not wish to carry something like this into the Wayland world.

So much discussion here, but most of it is missing the point of the issue.

This issue is not about exposing a "primary" output to applications. It's about providing a backwards compatibility mechanism that toolkits can use to fake such information to games that were not meant to be run Wayland-native originally.

I would expect most compositors to implement it the same way they implement xdg_toplevel.set_fullscreen(null) - picking some preferred output, and not necessarily always the same. In KWin I'd use the active output at the time of the request being processed.

Two kinds of arguments were made in this thread IIRC:

1. games don't start on the primary monitor,
2. games limit their resolution/refresh rate/scaling to the primary monitor and this is fixed when the game is launched.

The first one might be solved by your suggestion in the common case where a game opens a single window over its lifetime and does so immediately after starting. Otherwise the game might retrieve the primary window only once and that might be long out of date by the time the window is opened. Either way, this issue is a trivial annoyance compared to the second one.

The second one does not seem to be solved by your suggestion.

---

Which is not to say that what you described in the OP isn't solved by your suggestion. I'm only talking about this thread.

This issue is only about the second case. If the games properly adjusted to the screens they're moved to, we wouldn't need any new Wayland protocol.

Well, people came in here and started conflating things, arguing that they want a primary output thing for all kinds of reasons...

Anyway, in all of the cases where apps do not properly adjust to the screen, we have a translation layer in between that can handle this. There really is no reason to involve wayland at all. Solutions such as the one pointed out by @Drakulix exist and can be added to wine/wine-wayland as well.

This issue is only about the second case.

How does your suggestion solve the second case?

In KWin I'd use the active output at the time of the request being processed.

That would require the user to always start games from the output they want to run them on. If the user prefers to keep their game launcher on a secondary screen, it won't work.

Just for the record: COSMIC does not have a concept of a primary display by design.

My bad, I misinterpreted the Xwayland compatibility setting to be a full setting.

---

After thinking on this for a while, I have come around on some of the arguments and am now of the opinion that this should be handled in the compatibility layer. Some of this will be a repeat of what I already said but I want it all in one place.

I see two main usecases for a client within the compatibility layer:

1. The client uses the "primary" output to set its internal resolution and perhaps do positioning (on Windows). This is the common case for video games.
2. The client wants to know all of your outputs, and which one is "primary", so that it can perform window sizing/positioning logic across all of them. This is a less common usecase.

To solve case 1, the compatibility layer can use the output that its window is placed on by the compositor, and pass only that output to the client. This gives the user full control over the positioning via their compositor and allows problematic game logic to work correctly, as it only sees one output and sets its resolution to that. If the user wants to have the game launch on a certain output, then they use their compositor's configuration to do so (such as Sway window rules). Obviously, any positioning requests are still ignored.

To solve case 2, the compatibility layer can use logic similar to SDL3 to make an educated guess (such as reading GNOME's DBUS property and falling back to some positional heuristics), and allow the "primary" output to be overridden via an environment variable or other configuration method. This gives the user full control over which output is considered "primary", and positioning requests are still ignored and left to the user to handle.

Case 1 is the case that ought to be solved ASAP, and does not require anything from Wayland. Case 2 would be helped by standardizing a primary output, but it is certainly not required, as giving the user a way to control it will allow them to coerce problematic clients into behaving correctly. In the case of Proton, Steam could provide a UI in their compatibility settings to select the output that Proton will consider "primary" on compositors that don't provide this information.

---

Extra line to bypass the spam filter because I accidentally posted a toplevel comment instead of a reply...

To solve case 1, the compatibility layer can use the output that its window is placed on by the compositor, and pass only that output to the client.

If it was that simple, we would've never had any problem. Games create a window after choosing an output. Clients do not know which output a window is on until the window is both created and mapped.

This is about making the compositor choose the output before there is a window in the first place.

To solve case 2, the compatibility layer can use logic similar to SDL3 to make an educated guess (such as reading GNOME's DBUS property

The point of this is for applications to stop abusing completely unrelated DE-internal APIs like kde-output-order-v1, which are very much not about positioning windows, and which will be locked down to avoid that nonsense.

That would require the user to always start games from the output they want to run them on

Yes, just like with every other application that doesn't behave nicely when moved around. For most users that applies to every single application that doesn't have a setting for which output it goes on, as they don't know how to move fullscreen windows between outputs.

Solutions for backwards compatibility do not need to be magically perfect, they just need to be good enough. If you think your compositor's users need a setting for which output to choose for such backwards compatibility measures, then you can just go and do that instead.

Yes, just like with every other application that doesn't behave nicely when moved around. For most users that applies to every single application that doesn't have a setting for which output it goes on, as they don't know how to move fullscreen windows between outputs.

I don't think it's useful to mix these two things. Applications restricting themselves to the resolution of one output for their entire lifetime is not something the compositor or user can do anything about. Moving fullscreen windows for applications that do adapt to new outputs can be solved through compositor-only UX improvements and educating the user about that UX.

Exposing the primary output is still not a good idea because

1. Some compositors don't have that concept
2. We in wayland have all agreed that we want to reduce the reliance on outputs
3. The primary output and where a user actually wants the fullscreen window can disagree

Having some kind of setting in Xwayland and/or wine that compositors can somehow influence does look like the right approach to me.

Applications restricting themselves to the resolution of one output for their entire lifetime is not something the compositor or user can do anything about.

Yes, it is. The user can just start the relevant application on the correct screen directly.

Exposing the primary output

Again, this is not about exposing a primary output. This is about stopping SDL and co from doing that nonsense with compositor-specific hacks.

We in wayland have all agreed that we want to reduce the reliance on outputs

No amount of wanting to get rid of them changes that these applications depend on them.

Yes, it is. The user can just start the relevant application on the correct screen directly.

Not without the protocol that you've suggested. I'm talking about the current state. The compositor assisting the user in moving fullscreen windows that are otherwise reactive does not require new protocols. That's the distinction I'm making.

Maybe this would be better as a portal which would allow the user to select the primary output for an application interactively ("Application wants to know your primary output"/"Application wants to know the output to start on"). The answers could be cached and the user could also configure the portal to automatically return a specific output.

We in wayland have all agreed that we want to reduce the reliance on outputs

Maybe this would be better as a portal which would allow the user to select the primary output for an application interactively ("Application wants to know your primary output"/"Application wants to know the output to start on").

I thought about this and I think continuing the status quo is the better option. From what I see applications fall into 3 buckets

• Anyone developing new wayland native applications doesn't have that option and would know to not rely on it.
• x11 applications still have access to a primary screen through xwayland which is already implemented in most DEs, this is practically a deprecated feature.
• wine/proton applications currently rely on xwayland's primary display selection and will soon need to transition to some wayland native option.

Personally, I think users would want to just have a display priority option like the one KDE has, and I would love to hear what KDE has to say about this. @swick @mahkoh has this truly been discussed between the voting members before? Considering that from my understanding most of them still have this feature.

However, I do recognize that it is presumptuous to expect wayland to - in effect - ditch the reduced reliance on outputs philosophy just for compatibility (since adding it for compatibility could/would cause newer wayland native applications to start relying on it too).

For wine/proton applications it should be implemented in wine/proton, perhaps with some compositor specific hacks.

This is about stopping SDL and co from doing that nonsense with compositor-specific hacks.

If it truly has been decided that we don't want to rely on outputs on wayland then it maybe should be messy to get this feature back, right?

For SDL, from my understanding it seems like a mistake on their part. Since display priority on wayland is de-facto a deprecated feature, they should mark their functions as such. Referring back to the Factorio case, they wouldn't have had any issues if they knew this from the start.

For SDL, from my understanding it seems like a mistake on their part. Since display priority on wayland is de-facto a deprecated feature, they should mark their functions as such. Referring back to the Factorio case, they wouldn't have had any issues if they knew this from the start.

Factorio, and other apps/games, would have had to know this long before Wayland was gaining traction, because in the past, the concept of a primary display was a fairly standard concept on every desktop platform (and still is on everything except Wayland). While we can recommend not querying it since it isn't reliable on all supported platforms, there is still the issue that a lot of legacy clients query it, and will break or behave in an undesirable way on multi-display setups if they don't get what they expect.

To note for the record, support for the proprietary KDE display priority protocol was removed from SDL before the final version of 3.0 shipped in favor of the current sorted list + "best guess" algorithm. There is also an envvar that can be set if users wish to override the internal selection algorithm.

You want to take away the users control by forcing the window management behavior to conform to what you want, not what any particular user wants. (@swick)

You want users to have no control over window management and desire for the compositor to define where things go. A protocol to allow users to define which display is the one they prefer full screen applications to appear on, which this would undoubtedly be, would also be a definite solution to the problem. Heck, this could be solved by providing a setting for display priority as a Wayland protocol.

For an easy example of a situation where the status quo just doesn't work, my personal setup. My leftmost monitor is higher refresh rate (240hz vs 75hhz) and my rightmost one is higher color depth (10bit vs 12bit). My primary display is the 240hz one for gaming, and I can move anything I need higher color depth on to the other display much easier as I'm not locked into it as the full screen display. BUT I had to use KDE settings to define which monitor was on the left or right because the order i had them plugged into my GPU decided my leftmost monitor was my rightmost monitor. This caused (some of) my games to open in fullscreen on the rightmost monitor despite my leftmost monitor being set as default. The mixed refresh rates are still an issue on Wayland if I can't choose which monitor the application opens on by default.

From the Factorio point of view, users expect a game to launch in fullscreen on their primary display. This is simply a fact

As a factorio player, please don't state facts that are completely untrue about your users. My primary monitor is where many things go but explicitly not my games for reasons specific to my setup. There is no sound assumption an application can or should ever make about such things. Applications should go exactly where told by the compositor and the compositor should remember where I last placed things.

The primary output and where a user actually wants the fullscreen window can disagree

I think this is extremely important to emphasise. Assuming "primary" even means "the monitor that users want games launched on" is a bad assumption. I have also had really annoying experiences with games that think they are being so clever switching monitors every time they regain focus to the primary monitor which gets annoying really fast, so in my humble opinion as a user, the less games can attempt to do that in wayland the better. Me and my compositor can place the game where I want it and it should just stay there with as few assumptions as possible.

Having some kind of setting in Xwayland and/or wine that compositors can somehow influence does look like the right approach to me.

Just FTR, XRandR has the concept of primary output, so there is no need for a setting in Xwayland, the compositor just has to mark the output as primary in XrandR and X11 applications running on Xwayland will be able to tell (that's what mutter does, for example).

Any more 'everyone wants

$thing' or '$

foo is the only acceptable behaviour' blanket assertions, or any more 'you are trying to $badthing' accusations will get deleted. Discuss reasonably or don't discuss at all.

As a factorio player, please don't state facts that are completely untrue about your users.

You are right. That was not correct, and I apologize. I did not intend to come out swinging like that, and I could not tell you the thought process that led to me writing it that way.

I agree with you - as a user, I do not want programs to be able to override the compositor's positioning logic whatsoever. In fact, I will often wrap problematic games in gamescope to prevent them from grabbing the incorrect resolution or forcing themselves into fullscreen or other such nonsense.

As long as compositors give the users a way to control where clients appear through their mechanisms, I believe that is the best solution. As for the resolution problem, that could be configured in the compatibility layer, perhaps on a per-client basis. Unfortunately, it will likely be difficult to solve the resolution issue for problematic clients in a way that will not require fiddling on the user's part.

If it was that simple, we would've never had any problem. Games create a window after choosing an output. Clients do not know which output a window is on until the window is both created and mapped.

The intention here was that the compatibility layer would create a window separately from the game, then allow the game to create its output and change settings. But in hindsight, that would not work well because the game could change various surface properties that would affect how the compositor would position it (i.e. different color mode, resolution, refresh rate, etc), so that idea is no good.

Ultimately it comes down to toolkits and compositors being unable to determine intent. A client may be requesting to be placed on a specific output because the user explicitly requested it via a menu or command line parameter, in which case not honoring the request is bad UX, or if it is doing it "just because" or "that's how Windows does it" (i.e. most legacy games), in which case the request should be ignored in favor of compositor preference.

Removing all agency from clients is not ideal, as it also removes a degree of user control over their desktop, but the current situation where toolkits and compatibility layers that aren't XWayland have to play guessing games, and potentially guess incorrectly, isn't ideal either. This small bit of information would fill a gap and allow both scenarios to coexist, at least in a better state than they do now.

As @mak suggested below, it doesn't have to officially be a part of Wayland itself as a protocol either, as a portal would work just as well (speaking just for SDL, we already have to dig into DBus for several things, adding another is trivial).

As for Factorio, I am going to go ahead and entirely remove the display preference setting when running on Wayland, since it is not reliable.

I think having a display preference setting is actually a good thing compared to nothing if the game relies on having to pick a screen.

I'll leave my 2 cents here as a both the main developer of a fairly large (but niche) rhythm game and a Linux user who thinks that a lot of how Wayland works unnecessarily over complicates things for developers.

As a user for games I expect my games to launch on the specific monitor that I specify as the primary as a user. In my specific case(which I don't think is particularly unique) I have a gaming monitor (high resolution high refresh rate) that I set as my primary both in gnome and windows when I'm booted into that environment. And this is what I always expect to happen game goes full screen on my gaming monitor.

And so from the development side I don't have any code that sets or determines a default. I use a game engine(unity) that mostly handles all of this for me but we do still have code in the game to allow the user to configure what display the game launches and runs if they want to change from the default.

Having done work with lower level apis in the past as a developer I personally think having the ability to query the default display is a useful addition. I don't see any downsides to this personally.

This issue is primarily about games that limit their refresh rate or resolution to the first monitor they see or whatever monitor they identify as the primary monitor. Is that the case for your game?

I'm going to leave my opinion on this

For context:

I moved to CachyOS with KDE full-time 3 weeks ago, and I nearly switched back to Windows because of how frustrating it was knowing that the new WAYLAND driver for Proton-CachyOS offered exceptional performance and smoothness compared to Windows as well as HDR Support.

I have a 3 monitor setup as follows.

• Display 1: Primary Dell AW3423DWF 3440x1440p 165hz HDR, the GAMING monitor
• Display 2: Koorio GP01 2560x1440p 165hz, placed above Display 1
• Display 3: LG 24GN600-B 1920x1080p 144hz, Placed above Display 1 and to the left of Display 2

The issue:

With the way KDE and Wayland works currentl every time I would go to launch a game using the Proton Wayland driver, it would use the display located at 0,0(Display 3) including its resolution, regardless of the launch options I used, and there was NO easy way to bring it to my main monitor(Display 1) and get it to respect the aspect ratio and resolution.

Now I understand the concerns about giving an application control of a user's workspace,

However, an application should be allowed to query information about its environment(Such as which is the primary display) so that it can initially open on the primary display(Display 1) and use the Primary display features (Resolution, Refresh Rate, and HDR Status) Should the user decide otherwise, they can move the window or set a launch arg to use a differant display.

in conclusion.

I cannot speak for all users, but as an ex-Windows user, setting a Primary Display (Like in KDE settings with the display priority) means that I want Applications to treat that as the preferred output where windows and games should open on, not wherever the Desktop compositor feels like placing the window because thats genuinly what it seemed like was happening.

You can see my Reddit post where I was frustrated here.

Given that Microsoft is killing Windows 10 soon, a small number of people may switch to Linux and will have a terrible experience with gaming on KDE or other Wayland DE's, IF Proton starts using the Wayland driver by default.

Anyway, I expect some of you reading this will disagree, but I'm only applying my input here as a user.

There's one other option that is potentially worth considering: Do not make this a Wayland protocol, but a D-Bus protocol under the Freedesktop umbrella instead. Basically, standardize the GNOME D-Bus solution, so other compositors can expose org.freedesktop.Displays (or whatever it would be) and offer SDL and Wine and anyone else the functionality that is already there.

If we want to go one step further, we could even specify more output management features in future (not just read-only "who is the default display?" properties) and implement something like gdctl as cross-desktop solution (see https://gitlab.gnome.org/GNOME/mutter/-/blob/main/doc/man/gdctl.rst ). But obviously that's a stretch-goal, no app wants to (or should ever want to!) change display properties.

This feature does not necessarily have to have a solution as a Wayland protocol... ;-)

I would be wary to interleave two different use-cases (querying the "primary" output, and configuring outputs) with wildly different use-cases and security concerns into a single API.

(FWIW, wlroots and other compositors already expose a Wayland protocol to configure outputs.)

Same here. The dbus interface in question is also not stable on purpose but changes in lockstep with GNOME releases.

I would be wary to interleave two different use-cases (querying the "primary" output, and configuring outputs) with wildly different use-cases and security concerns into a single API.

Yes, I fully agree with that. Having a targeted read-only and single-purpose but extensible interface on the bus for specifically this would help most, if it isn't going the Wayland-protocol route. (And anything more, especially anything that changes settings, I'd see out of scope - I should probably not have mentioned the possibility of doing more things in future in the original post, to keep things more focused)

The point of this rout would be to have a stable interface that is cross-desktop that apps can rely on for this feature.

What do you make of the idea that Julian raised earlier? that applications shouldn't be limiting their resolution and refresh rate in the first place.

@kontrabant You can correct me if I'm wrong, but it seems that the resolution issue is exclusive to wine applications, and so if you leave it up to wine to allow the user to select a primary display you don't have to introduce tools that would allow wayland native applications to start limiting their resolution as well.

Given the publicity this issue gained, we might consider locking this issue and/or turning it confidential. Random drive-by comments will be deleted. Repeated offenders will get their accounts blocked.

We welcome productive participation in this space, we don't welcome people who just want to stir things up or add unnecessary heat to the discussion.

Users are generally welcomed to give their view and explain their use cases, but this should happen in a constructive way. Users are encouraged to reach out to their respective desktops directly for discussing their use cases they want solutions for from their desktop environments. And everybody should keep in mind that this is a highly technical space intended for developers with the required domain knowledge.

There will be disagreements, but it's for the developers themselves to figure out how to approach them and to create a mutual understanding of the problems and sustainable solutions to solve those.

Some of my thoughts going through this thread:

Tagging

There's also #153, which was about determining a "presentation" display vs the "primary" display.

To that end, maybe there can be a protocol where the compositor may or may not give different displays different tags/roles. A display can be tagged as the presentation display, and presentation software will prefer to place itself there. Similarly, there could be a "gaming" display which is the primary display for the purpose of games

This is different from simply marking a display as "primary", because unlike the heavily-overloaded "primary" definition (which can either mean "the compositor opens windows here by default" or "the compositor shows the system shell UI here" or "this is the monitor I want to launch my games on" or ...) we can have multiple different tags for different usecases

Overriding

Whatever solution comes of this, it should probably be overridable by game launchers like Steam. We're trying to shoehorn software for one platform onto another platform. When this misbehaves, fixups of some kind will be necessary by the user to force the game to look at a different monitor (especially if the game doesn't have these settings on its own).

To that end, I'm not entirely convinced that this should happen within Wayland. How should Steam go about telling Wine "no, actually, the user wants this other display to be the emulated primary display for this game"? I suppose Wine can listen to Wayland, unless there's an environment variable which it respects instead? But at that point, it seems reasonable to just put the "Primary game display" setting directly into your preferred game launcher, have it always set the env var, and then completely bypass the compositor.

Improved heuristics

If the issue is that games are limiting their resolution and refresh rate to those of the primary display, a simple question follows: why don't you just pick the highest-resolution highest-refresh-rate display and report that as the "primary" display?

After all, it's incredibly likely that this display is the main gaming display anyway. And if it's not about positioning the game, but only about picking a maximum resolution/refreshrate, then picking the best available display would solve that neatly. Even if the game is placed on a lower-res, lower-refresh-rate monitor, it's within the maximum limit and thus it'll work.

Going prescriptive (tag wl_output with arbitrary roles, fullscreen on outputs) instead of descriptive (set_fullscreen with an intent, e.g. "presentation" or "game") has its own set of problems, and isn't necessarily a solution that we should go after for presentations either. It e.g. removes the reason why an application wants its surface to be fullscreen from the compositors logic flow. It removes window management control from the window manager, and it'd also make implementing certain features (e.g. handling multiple presentation outputs, dedicated presentation monitors not part of the regular set of usable monitors / screen estate) harder.

It has the same problem as tagging an output as "primary", not mentioning the complete lack of such concepts in some compositors, where it's impossible for a compositor to know if the intent was "fullscreen on an output suitable for gaming" vs "user explicitly configured window to be fullscreen on that monitor".

IMO, ideally we should move away from prescriptive window management operations, where possible, also for becoming fullscreen, as it creates unsolvable window management issues.

Handling edge cases like unfixable, unchangable games that are simply incompatible with descriptive window management and implemented in a very awkward way (i.e. configure itself based on guessing before being configured by the window manager), should be handled differently than properly designed fullscreen semantics that are meant to solve problems in ways more in line with the Wayland philosophy.