Erratic behavior in multi-monitor setups

[nhurtt]

Steam seems to find the top left corner of the screen space, and launches games there on whatever monitor is displaying that screen space. This isn't really ideal in multi-monitor setups. My particular setup is nvidia twinview, but there may be more to consider to accomodate xinerama, for example. Ideally I think there should be a flag or option to specify which monitor/screen/(workspace? *fingers crossed) to launch games on.

Initially, trying to move the window using the "alt+mouse1" combination over the game window caused tf2 to crash. I added -windowed -noborder to tf2 launch options and was able to move the window to the desired monitor without crashing.

[sreich]

To be honest, and to provide a different perspective, Nvidia twinview pretty much sucks. For example, it treats all of your screens as 1 big screen which is inevitably going to cause issues. I believe it also treats it as one whole texture, so I have a feeling it doesn't even scale to a bigger screen count than MAX_TEXTURE_SIZE of opengl.

Anyways, radeon open source and nouveau drivers for instance, with multiple monitors, detect them individually Just Fine, with no config to do on my end. And the rest of the OS knows what the monitors are, since it isn't trying to "pretend".

I do agree with the which screen to launch fullscreen on though, I encounter that issue as well. My "fix" is just to have it go into windowed, remove the border and place it on the entire screen.

[nhurtt]

You're not wrong about nvidia twinview.... but (in ubuntu / kubuntu), multimonitor support is falling to the wayside rather quickly. For a particularly depressing example of such neglect read through the developer responses here.

https://bugs.kde.org/show_bug.cgi?id=256242

So for the time being those of us using nvidia's drivers are basically screwed. I guess I could try nouveau, but my understanding is that there is a performance loss in games. Is that not true now that we have steam linux?

[sreich]

Performance loss is still true of nouveau and radeon.

The response you linked to is not neglect at all. Separate X servers should not be supported or done. There are simply no use cases where that is necessary, and you instantly lose the ability to transfer input between those.

So you cannot drag windows between monitors and such.

Really, it is a completely deprecated feature that with the X server makes things SUPER complicated to support. Multimonitoring in X is already extremely difficult because X doesn't just say "oh, there's a new screen, here are the coordinates". No. Whenever you think it should do something properly, it does exactly the opposite of what you expect.

Almost every single time somebody says they want separate X servers, you realize that is not at all what they want.

I imagine the concept of separate X servers won't even be existent in wayland. It just doesn't make any sense. And hopefully Waylands monitor signals will be excellent, or at least better than the fuster cluck it is now ;)

As for multiple monitor handling in KDE, it has been better than ever, especially so with the open source drivers. It isn't flawless, but it gets the job done reasonably well.

[Agent24]

I tested with Radeon HD5770 and fglrx 12.11 Beta, two monitors (one extended) and found that Steam would center itself in the middle of the monitors. Not a big deal, can move it, but annoying.

But TF2 if run in fullscreen, the cursor didn't line up with the buttons. Ran fine in windowed mode though. Maybe due to the fact my monitors are on different resolutions.

[nhurtt]

I don't understand what you mean by this:

"As for multiple monitor handling in KDE, it has been better than ever"

Near as I can tell, the only way to accomplish a multi-monitor setup with the proprietary drivers uses twinview (though if there's an alternative I've overlooked then I'm all ears), and the complications are endless... Pretty much the most you can hope for is an ability to cope; in-so-far as TwinView is concerned, solutions aren't even on the distant horizon.

[sreich]

there's not much anyone can do to remedy TwinView honestly. it's basically all in Nvidia's court. Nvidia should no longer have a need for twinview anyways afiui.

[nhurtt]

I honestly don't think nouveau would even solve the problems with multi-monitor support... completely ignoring the performance and feature drops of nouveau, the major issues with multi-monitor setups are entirely feature oriented. The big ones that come to mind are: shared workspaces between monitors, and monitor specific application handling i.e. rules for opening / placing windows on specific monitors in specific workspaces.

[horazont]

If I might leave a comment, one good thing about TwinView is though, that it supports the Xinerama interface to enumerate screens etc. Xinerama is also supported by all window managers I know (so they respect monitor borders and understand fullscreen requests related to monitor geometry) and is not that hard to query for information about the screens geometries (it's really mostly one call to XineramaQueryScreens, after checking that it's available using XineramaQueryExtension and XineramaIsActive). Also, Xrandr (which is used by modern drivers) implements the Xinerama interface sufficiently to find out about the screen geometries (possibly more, I have not tried), so it's a one-catchs-it-all.

And if I might add some of my personal experience, one probably wants to go for the rather complicated but working window manager hints for fullscreening, which also include means to specify the monitors one wants a window to span across. One might want to check out support in the major window managers first though, I've been told that some still don't implement these properly.

[aaronp24]

This bug seems to be confusing several different concepts. Is there something specific that this bug is requesting from the NVIDIA driver?

Multiple X servers

This is when you have multiple different instances of the Xorg binary running. Each one of these has a different display number. E.g., one would be :0 and one would be :1. Applications have to connect to each one separately, and most applications don't have support for that.

Multiple X screens on a single X server

This is when a single instance of the Xorg program is running, but driving multiple GPUs. You can also configure some drivers (such as the NVIDIA driver) to have separate X screens for different display devices, but this is not the default. Each screen is numbered .0, .1, etc. So for example if your X server is on display :3, then your screens on that display would be :3.0, :3.1, etc.

This used to be supported by many desktop environments, but some have been dropping support for it lately.

Multiple display devices within a single X screen

This is where things get a little complicated, because the original X11 protocol written in 1987 didn't really support this. That's where two extensions come in: XINERAMA, and RANDR.

XINERAMA just lists where the different display devices are within the X screen, and their sizes. It doesn't tell applications anything about what those monitors are or what mode timings they are displaying. RANDR version 1.2 and up gives you more detailed information, such as the monitor's EDID, mode timings, scaling configuration, panning, etc. The NVIDIA driver supports RANDR 1.2 starting with version 302.*, and this is the default configuration for multiple display devices connected to a single GPU.

Multiple X screens on a single X server bound together with Xinerama

This is not to be confused with the XINERAMA protocol; it is a module within the X server that makes multiple physical X screens (:3.0, :3.1, etc. for example) appear as a single logical X screen to applications (:3.0 in this example). This code also uses the XINERAMA protocol to tell applications where the physical screen boundaries are. The advantage of this is that you can use it across multiple physical GPUs and even across drivers, but there is a performance penalty for doing so.

[nhurtt]

@aaronp24, To be honest I'm not sure whether the nVidia driver plays any role in this issue, I was hoping one of the devs could decide. Personally, I'm using TwinView, which I'm not sure fits in to any of the categories you outlined. The basic problem is that there is no means to specify which monitor the game opens on, and in my case steam has defaulted to opening games on the wrong monitor. When I tried to drag the game to the correct monitor it crashed.

[aaronp24]

What I described as "Multiple display devices within a single X screen" is what the NVIDIA driver used to call TwinView, though that name has been removed since you can have more than two display devices on some newer GPUs.

You can specify which one is "primary" by using the "xrandr --output <blah> --primary" command, though it's up to the application to actually honor that.

[Vash63]

Just FYI for Aaron here, the nvidia-settings application still refers to the Xinerama-style settings as "TwinView". This should probably be changed. This is on the latest 313.09's.

[ashelley]

I feel that when steam launches it should load on the center of the primary display (or center of current display in which launching was initiated. Currently it centers in the middle of both monitors which is non ideal because the borders of each display obstruct proper viewing of the window.

[johnv-valve]

It's not clear if this bug is talking about game multi-mon behavior or the Steam client.

If you have multi-mon issues with the steam client windows, please post the output of xrandr. Also include what WM you are using and maybe a screenshot or two. If your Xinerama configuration is correct, steam should never create its windows crossing a monitor boundary. And when you launch Big Picture it should always start on the primary monitor.

TF2 multi-mon bugs are being worked on right now.

[johnv-valve]

can't repro steam problems