protonscr

Can we enforce games to open on the primary screen instead of the one which on the left?

dxvkclosed
doitsujin/dxvk#1308 · opened 2019-12-25 by ghost · updated 2020-04-28 · 8 comments · github
?ghost 2019-12-25 github

I don't think that windows games understand the "primary display" concept and a lot of them can't be moved to the right screen either because they'll either crash or start glitching. This is not really a problem with native linux games.

Mmisyltoad 2019-12-25 github

a lot of them can't be moved to the right screen either because they'll either crash or start glitching

This sounds like a setup issue on your end. I've never seen such behaviour.

Proper multi-monitor support is possible but needs work from Wine.

Make sure the mouse cursor is on the screen you want to launch the game on also... (That works for me on KDE but ymmv)

?ghost 2019-12-25 github

@Joshua-Ashton for certain games it doesn't matter where my cursor is, that's why I opened this issue. I also tried it on KDE and it was the same as on gnome-shell, games like ark: survival evolved and plague tale innocence open on the monitor on the left, no matter where my cursor is or which one is the primary monitor.

Jjarrard 2019-12-26 github

you can setup window rules via application. That might work

SSveSop 2019-12-26 github

a lot of them can't be moved to the right screen either because they'll either crash or start glitching

This sounds like a setup issue on your end. I've never seen such behaviour.

Proper multi-monitor support is possible but needs work from Wine.

Make sure the mouse cursor is on the screen you want to launch the game on also... (That works for me on KDE but ymmv)

Not really sure what actually makes this happen, but i have different behavior depending on app. Eg. if i open "unigine valley" it will always open on my right (main) monitor, but opening "Battlestate game launcher" it will always open on the monitor where my mousepointer is.

This has something to do with the default layout of the window manager/screenserver i think. Cos default "starting point" afaik is coordinates: 0:0. If you have your second monitor to the LEFT, this is the upper LEFT corner. The default behavior in Linux seems to always have the "main" monitor at coordinates 0:0 (On the left side), and any extra monitor will be to the RIGHT of this.
It is the same if you use wine's "emulate desktop" mode, cos then it will always open on your left monitor - coordinates 0:0.
So to me it kinda seems that if the app itself does not have any particular knowledge of "primary monitor", it will just go to the monitor the mouse pointer is, or if that does not work some placement referenced to where coordinates 0:0 starts (and that is to your left).

You can use things like "devilspie2" and override this by window name (works quite well once you figure it out).

Jjarrard 2020-01-05 github

Sometimes you can run the application in WINDOW mode and drag it to the other monitor, then alt-enter to enlarge it there. Doesn't always work but often does.

Ddoitsujin maintainer 2020-01-06 github

Two things:

  • It is the game which creates the window, and also decides where to create the window. (0,0) is, by definition, the top-left corner of the primary monitor on Windows, so usually it should end up there.
  • Wine still has very poor multi-monitor support.

So, no, it is not possible to fix these issues this on our end.

SSveSop 2020-01-06 github

There has been some development for better multimonitor support with wine.
4.12: winex11.drv: Use generic EnumDisplayMonitors.
https://bugs.winehq.org/show_bug.cgi?id=34978 (Down to the bottom of that bug is links to some of the commits being made to solve stuff like this.)
4.15: user32: Return correct showCmd from GetWindowPlacement() for other process window.

Part of the problem (i think) is the way nVidia "TwinView" communicates with the X-server and Wine. (I have no idea how this works for AMD tho) It is not a problem DXVK should try to solve, as it is wine's job to place windows basically. Why some apps/games seems to do this more correct than others is anyone's guess...

SSveSop 2020-02-11 github

Another thing you could try is to untick the option Allow the windows manager to control the windows under the "Graphics" tab in winecfg.

Atleast this seems rather buggy if enabled when using gnome as a wm...

Other than that (not that it is for me to decide), i vote to close this as a "not a DXVK issue".

Upstream links