Hello @RailRanger, while there is a long standing issue with many games launching on the left most monitor in multi-monitor configurations, Steam doesn't influence this.

I see, thanks.

A few minutes ago I tried launching a game and it would launch on the left monitor. I then switched to the steam beta channel right after, now it's launching on the correct monitor. I wouldn't know if there were any changes made under the hood, but I feel like Steam re-read my ~/.config/monitors.xml file again after updating. I would go back to the normal channel again to test, but on the off chance things break again I will be stuck.

The reason I mention that because the only thing I changed was updating Steam and it works now. So I want to say that Steam does have some influence, but you would know better.

If anyone still has this problem, I came across a fix. You have to set the primary display in xrandr to your primary Wayland display for applications to launch on it.

So after identifying your primary display with

$ xrandr

All you have to do is:

$ xrandr --output <primary display> --primary

Upstream bug report where this is hopefully going to be fixed: https://gitlab.gnome.org/GNOME/mutter/-/issues/1407

It's year 2023 - the same issue still exists. It applies to both Steam games and system applications.
I followed the xrandr advice and refreshed user session manually through a relog (although xrandr seems to change the primary output setting)

Nothing changes, tested different monitors as primary (both with Gnome utilities and this xrandr tool).
Both games and programs still launch on the monitor with the highest index... (in my case XWAYLAND2)

I tried switching the plugs the other day with no effect. I don't know, maybe I could give it another try but I remember that I tried different combinations with no results. It would either appear on the right or the left one, never in the middle. It would appear only in the middle if I set my primary somewhere else, like... to the right side for example.

I find it ridiculous that there is a problem with multi-monitor setup. It's probably an issue with Wayland.
I use Fedora in my case. It doesn't matter if it's Flatpak, RPM, Steam game.

Some apps just launch on the bad screen and ignore system settings (games like Tyranny for example).
My system is up to date and I have been updating it just recently. It's the newest kernel and the newest libs.

PS: It is also the left monitor for me, like OP's. It seems to be the same case with apps launching on X+0 instead of X+(screen-resolution). That would explain why switching physical outputs doesn't matter. It would only care about the resolution offset, not the index... (because you align the "virtual resolution" and corresponding alignment through Gnome's settings, so the index doesn't matter theoretically).

PS2: Although XRANDR calls my left monitor "XWAYLAND2" it appears as "1" under displays settings.

Tests

OS - Fedora Linux 37 (Workstation Edition)
Desktop environment - Gnome/Wayland

Okay. I ran some tests to make sure that I didn't share a bad thesis or anything.
In my case gnome displays tool started acting up and it replicated screens x3 (into 3 configuration tags inside the same XML file) after I switched the plugs...

It didn't act like that in the past, it must have been an update that broke it (?).
Either way. I booted up and checked which monitor is detected as the primary one by GRUB (aka where the booting screen is displayed on before loading the session).

Config

I changed cables in such a way that the primary Display Port is my middle monitor.
That DP is called DP1.

I have set 3 different refresh rates on all 3 monitors and checked for where the appended monitors.xml file's real content is. For some reason Gnome/Fedora generates broken XML file for me today.

I have removed the bugged entries (I have no idea from where it takes them from. They regenerate after modifying displays settings, but they do not remove the other old entries... I uninstalled xrandr to check whether it produced some weird output into that file, doesn't seem to be the case?)

This way I have concluded (from the autogenerated configuration tag block) that:

• the left is 120Hz, called "2" by "displays" tool, but labelled as DP2
• middle is 60Hz, called "3" by "displays" tool, but labelled as DP1
• the right is 144Hz, called "1" by "displays" tool, but labelled as DP3
  (I could comment on this labelling algorithm...)

Manually fixing ~/.config/monitors.xml

<monitors version="2">
  <configuration>
    <logicalmonitor>
      <x>3840</x>
      <y>0</y>
      <scale>1</scale>
      <monitor>
        <monitorspec>
          <connector>DP-3</connector>
          <vendor>AOC</vendor>
          <product><removed></product>
          <serial><removed></serial>
        </monitorspec>
        <mode>
          <width>1920</width>
          <height>1080</height>
          <rate>144.000</rate>
        </mode>
      </monitor>
    </logicalmonitor>
    <logicalmonitor>
      <x>1920</x>
      <y>0</y>
      <scale>1</scale>
      <primary>yes</primary>
      <monitor>
        <monitorspec>
          <connector>DP-1</connector>
          <vendor>AOC</vendor>
          <product><removed></product>
          <serial><removed></serial>
        </monitorspec>
        <mode>
          <width>1920</width>
          <height>1080</height>
          <rate>60.000</rate>
        </mode>
      </monitor>
    </logicalmonitor>
    <logicalmonitor>
      <x>0</x>
      <y>0</y>
      <scale>1</scale>
      <monitor>
        <monitorspec>
          <connector>DP-2</connector>
          <vendor>AOC</vendor>
          <product><removed></product>
          <serial><removed></serial>
        </monitorspec>
        <mode>
          <width>1920</width>
          <height>1080</height>
          <rate>120.000</rate>
        </mode>
      </monitor>
    </logicalmonitor>
  </configuration>
</monitors>

The file was then saved and I created a separate copy in case the Gnome config tools broke it once again...
(I have no idea why it does it. It didn't act that way like 3-5 kernels and system updates ago)

Further config

I do:

sudo cp -v ~/.config/monitors.xml /var/lib/gdm/.config/ 
sudo chown gdm:gdm /var/lib/gdm/.config/monitors.xml

/var/lib/gdm/.config/ -> The files are the same.

I restart the OS, seek for any changes in the displays configuration, then compare the monitors.xml file.

Tests after restart:

• ~/.config/monitors.xml remains the same, it seems to be OK.
• I open a random program, in this case it's F3D from Flathub
• • F3D opens on the far left screen - DP2 - Monitor No. 2
• I run xrandr to compare the outputs

XWAYLAND0 connected primary 1920x1080+1920+0 (normal left inverted right x axis y axis) 530mm x 300mm
   1920x1080     59.96*+
XWAYLAND1 connected 1920x1080+0+0 (normal left inverted right x axis y axis) 530mm x 300mm
   1920x1080    119.93*+
XWAYLAND2 connected 1920x1080+3840+0 (normal left inverted right x axis y axis) 530mm x 300mm
   1920x1080    143.88*+

The results seem to make sense to me.

• The far left screen is 0+0, that's 120Hz, DP2, Monitor No.2
• The middle screen is 60Hz
• The right screen is 144Hz

Running a Steam game

• Tyranny launches on the left screen, then moves onto the right screen. The system rembered that I moved the game window from the screen into the screen No. 3 before switching the DP plugs. The window opens on the "default" screen, then gets corrected by Steam(?) or system settings. If I moved it into the middle screen, it would likely remember the settings again.
• Noita - opens on the middle screen. This game is emulated with Wine/Proton I believe. Seems to be fine.
• War Thunder - the left screen (Linux "native")
• Borderlands 2 - the middle screen, ran with Wine/Proton
• Borderlands Enhanced Edition - the middle screen (including the game launcher menu) (I think this one was also ran with Proton).

Summary

I am not sure what else I can present. I think it's just broken on the system level.
Wine stuff seems to be working fine (?)

TL;DR
I think it proves my assumption, that some programs and games totally ignore the output enumerators and simply render the windows on the screen that has X=0 (checked it twice, the +0 screen is at 120Hz, that's the left one, AGAIN).
I switched the outputs for this test and generated a new XML file. Xrandr confirms the XML configuration.

I could be wrong, can't find any other explanation :man_shrugging:

If anyone still has this problem, I came across a fix. You have to set the primary display in xrandr to your primary Wayland display for applications to launch on it.

So after identifying your primary display with

$ xrandr

All you have to do is:

$ xrandr --output <primary display> --primary

Thank you for this fix, it works very fine ! Just for your information, this problem is not only on gnome wayland + steam. I am running KDE wayland + Lutris games, and the issue is exactly the same. But your fix is good for each case :)

This is still a problem (not valves obviously) with basically EVERY native linux game regardless of X or Wayland. Its ridiculous, how on earth in 2024, with a new display server specifically designed to solve the problems of X, do we STILL have games not identifying the primary monitor.