Multimonitor problem, kinda

[ChemBroTron]

Hello there!

I have a little problem with SuperTuxKart and my multimonitor-setup. I use a 24" 1920x1200 monitor (primary) and a 19" 1280x1024 monitor (secondary). For some reason, I can only select screen resolutions for my secondary monitor (so everything up to 1280x1024) or fullscreen over both monitors, which looks kinda bad.

I am on Arch Linux 64bit, have a Radeon HD 7870 and I use Catalyst 14.4.

Well, okay, I can edit the config file to get for example 1920x1080, but I see this behaviour in many, many open-source games and in nearly no commercial game. The game itself, by default, sees the secondary monitor as a primary monitor or something like that. I just want to know, why is the way it is and why SuperTuxKart does not give me an option for screen resolutions, that would fit for the primary monitor.

Also, with having 2 screens side by side, why is there no option to split the multiplayer screen (2 player) vertically? Horizontally at 3200x1200 does not look good.

And a bonus question: Is this new Irrlicht/SuperTuxKart-thing alreade in svn? I mean the new engine with the new effects?

[Auria]

Hi,

unfortunately, we do not list resolutions ourselves, but rely on what irrlicht tells us. So I can't really say why this would be the case

And no, there is currently no way to split vertically, sorry

Regarding the new engine, yes you can get it, though we now use git, not svn

[cand]

irr uses either the vidmode or the randr extensions to list resolutions. STK is configured for vidmode.
In both cases irr queries the resolution of your primary monitor. So in this case you have configured your smaller monitor as primary/monitor 0.

Try changing that in catalyst control center.

[ChemBroTron]

So in this case you have configured your smaller monitor as primary/monitor 0.

I'm sorry, but this is just not the case. My bigger monitor is the primary monitor both in amdccc and in KDE (kscreen).

[deve]

Try to run:

xrandr --output VGA1 --crtc 0

Where VGA1 is your external monitor. I remember that it helped me some time ago when I had Openbox WM. Currently with Gnome 3 I don't have any issues with resolutions.

[ChemBroTron]

And how do I find out, what I need to type instead of "VGA1"? Also I don't use vga, I use hdmi (primary monitor) and dvi (secondary).

[deve]

When you will use:

xrandr

in console, you will get on output something like:
LVDS1 connected (...)
VGA1 disconnected (...)
HDMI1 connected (...)
with available resolutions.

This may be also something like HDMI-0, it depends on your drivers.

xrandr is part of x11-xserver-utils package (Debian/Ubuntu).

[ChemBroTron]

I'm on Arch Linux, but that's not so important.

{l Code}: {l Select All Code}

$ xrandr
DFP9 connected primary 1920x1200+0+0 (normal left inverted right x axis y axis) 518mm x 324mm
DFP10 connected 1280x1024+1920+0 (normal left inverted right x axis y axis) 376mm x 301mm

Everything like it should, or not?

[cand]

http://pastebin.com/bwMeSQqQ

This is a small test program I used to debug another vidmode problem today. Perhaps post the output from it?

[deve]

You can compile and test current git if you want. I added possibility to easily switch irrlicht to use xrandr instead of vidmode by cmake flag:

cmake -DUSE_XRANDR=on

In my case it works a bit better. It properly detects primary monitor, it turns off secondary monitor and sets the specified resolution. It only doesn't restore secondary monitor after exit.

[ChemBroTron]

http://pastebin.com/bwMeSQqQ

This is a small test program I used to debug another vidmode problem today. Perhaps post the output from it?

http://bpaste.net/show/i00hsPriWBvixCKPnz7I/


@deve: You say, it turns off the secondary monitor. This is something I really, really don't like. I appreciate, that it would work with my primary monitor, but I don't like to test it, if it shuts down my secondary monitor. I'm sorry.

[deve]

You could at least run STK with full resolution 1920x1200. Usually you don't use second screen when you play the game. Though you still need to restore it after exit

Generally this is problem in irrlicht. Upstream version does it in the same way. There isn't even possibility to choose which one screen you want to use. It uses default screen. At least I didn't notice it.

It's solved quite good in SDL2, where you can choose which one screen you would like to use and only this one screen is changed. Perhaps we should use something like libstkirrlichtsdl? ;-)

[cand]

Well the output is pretty clear. Perhaps you can play with the catalyst control center settings, and see how they affect the list as output by vidmodes?

[ChemBroTron]

You could at least run STK with full resolution 1920x1200. Usually you don't use second screen when you play the game. Though you still need to restore it after exit

Well, the restoring part is the one I don't like, because I use KDE and when the second monitor is switched off, all configurations on that monitor are gone and I have to do that again.

Also I don't know how you use your second screen, but I usually use it everytime for example having an irc-client on it and watching for new comments, pausing the game, if I want to reply. That might sound strange to you, but that's how I use my monitors. Or having spotify or amarok on the second screen and manage songs or podcasts WITHOUT leaving the game. Or I record SuperTuxKart videos and need the recording "monitor" on my second monitor. I think, you'll understand the last use case the most.

@cand: I don't see any setting possibility in amdccc. Also my question in my opening post was, why that happens so often with open-source games and nearly with no commercial game. I know most commercial Linux games use SDL2 so I guess, SDL2 just handles it way better. But that is a guess, not knowledge. I also don't know the difference between these "vidmodes" and xrandr and why xrandr detects it correct and these "vidmodes" not.

[deve]

Are you able to switch between fullscreen game and second screen? I don't use KDE, maybe it was solved there...

Generally you can't use "Alt + Tab" and other shortcuts in 99% of linux games. It's because developers use three commands: "XSetInputFocus, XGrabKeyboard, XGrabPointer" and they grab whole keyboard and mouse rather than use Window Manager fullscreen. Again it was solved in most of commercial games, maybe SDL2 does it in different way.

To be honest, it's not because developers are too lazy, but it's because we have too many window managers and every one can manage fullscreen in different way. I solved it in STK few months ago, so if people won't report the bugs, you will be able to switch window after next release. I tested it and after some modifications it works well with Gnome, Unity and Openbox. But what about KDE, Xfce, Fluxbox, Cinnamon, Mate, Enlightenment, Compiz modifications (eg. Xfce + Compiz) etc. Developers can't test every one WM in every one version. XSetInputFocus, XGrabKeyboard and XGrabPointer is easier if you want to be sure that everything will work.

About changing resolutions... Xrandr and vidmode are libraries which are used by applications for changing resolution. SDL2 also uses xrandr or vidmode (it depends on configuration), but it does it in different (better) way.

Why non-commercial games have issues with resolutions:
- they are non-commercial ;-)
- a lot of these applications were written a lot of years ago, they use old engines or do it on it's own way and they aren't 100% compatible with current systems/libraries
- in some applications/engines changing resolutions is poorly implemented
- some people have simply different point of view - some want to have game displayed on both screens, some want to use second screen for something other in the same time, some would like to have one gigantic resolution 3840x2160 displayed on their four monitors.

And what about the difference between vidmode and xrandr. I'm not an expert but vidmode looks for me much more raw. You need to do more things manually. Xrandr is more smart. It looks like xrandr is used more frequently by desktop environments - gnome-control-center depends on xrandr, xfce-settings depends on xrandr, LXDE environment has it's own gui for xrandr. This may be the reason why xrandr detects it correctly - the same tool is used for it. Wine also uses xrandr AFAIK.

[cand]

Also my question in my opening post was, why that happens so often with open-source games and nearly with no commercial game.

Oh, that one is very simple.

Open source games are done by small teams with no funding usually. This means they usually don't have special hw like joysticks, or two screens.

Commercial game with a big budget? They'll just buy any hw for testing, if there's >1% users who demand that.

[Arthur]

Using xrandr would be a good idea probably. Also in a year or two we'll have to look at Wayland integration, and hopefully things will be easier or at least more unified by then.

[sj04736]

I did some poking around to see how SDL does their multi-monitor stuff and I came across this nice little comment:

{l Code}: {l Select All Code}

/* I'm becoming more and more convinced that the application should never
 * use XRandR, and it's the window manager's responsibility to track and
 * manage display modes for fullscreen windows.  Right now XRandR is completely
 * broken with respect to window manager behavior on every window manager that
 * I can find.  For example, on Unity 3D if you show a fullscreen window while
 * the resolution is changing (within ~250 ms) your window will retain the
 * fullscreen state hint but be decorated and windowed.
 *
 * However, many people swear by it, so let them swear at it. :)
 */

Of course that's just in the x11 specific code. There's a whole other set of support libraries for Wayland, Mir, Windows, Win8, and several others that all need their own tweaks because they do things differently.

[ChemBroTron]

Are you able to switch between fullscreen game and second screen? I don't use KDE, maybe it was solved there...

If the developer was nice, I have the game fullscreen on my primary monitor and I can move my mouse out of the game to the second screen, where the rest of my desktop is still untouched.

Open source games are done by small teams with no funding usually. This means they usually don't have special hw like joysticks, or two screens.

I get that.

Commercial game with a big budget? They'll just buy any hw for testing, if there's >1% users who demand that.

I don't get that. The commercial games, I mean devs of those games I'm playing on Linux usually don't have enough money for that. There's a special neogaf thread for that named "indie developer thread of being professionally poor".


Well, I guess, it is that way: open-source: not enough man-power/old code. Commercial: they just use SDL2?

[Arthur]

A lot of the indie devs use Unity3D or other ready-made large game engines; some of them might use SDL as well but they usually don't try to figure this out on their own.

[deve]

I did some poking around to see how SDL does their multi-monitor stuff and I came across this nice little comment:

{l Code}: {l Select All Code}

/* I'm becoming more and more convinced that the application should never
 * use XRandR, and it's the window manager's responsibility to track and
 * manage display modes for fullscreen windows.  Right now XRandR is completely
 * broken with respect to window manager behavior on every window manager that
 * I can find.  For example, on Unity 3D if you show a fullscreen window while
 * the resolution is changing (within ~250 ms) your window will retain the
 * fullscreen state hint but be decorated and windowed.
 *
 * However, many people swear by it, so let them swear at it. :)
 */

Of course that's just in the x11 specific code. There's a whole other set of support libraries for Wayland, Mir, Windows, Win8, and several others that all need their own tweaks because they do things differently.

I saw this comment. I don't know how old it is, but about 2 years ago xrandr was disabled by default. Currently you can use both - xrandr and vidmode.

Also allegro previously was using vidmode (versions 4.x) and now they switched to xrandr in version 5.0

Main difference between irrlicht and sdl are in these lines:
Irrlicht:
XRRSetScreenConfig(display,config,DefaultRootWindow(display),bestMode,oldRandrRotation,CurrentTime);
SDL2
XRRSetCrtcConfig (display, res, output_info->crtc, CurrentTime, crtc->x, crtc->y, modedata->xrandr_mode, crtc->rotation, &data->xrandr_output, 1);

The first one changes resolution of first screen and disables second screen. The second one changes first screen and leaves second screen untouched.

But this is a bit more work than simply change this one command.

BTW. Every one commercial linux game which I have, uses SDL
Source based: Half-life series, Counter Strike Source, Portal, and The Cave, Bastion, Braid, World of Goo
Some of them use old SDL 1.2, some of them SDL 2.0

[cand]

deve:

Tangentially related to this topic, I was reviewing the stk irr commits, and found your alt-tab netwm commit. You should know that it breaks fullscreen for all non-netwm window managers.

Of course the majority will use Unity, KDE or Gnome, so I don't think it needs to be reverted, but just a FYI.

[deve]

That's true. But probably every usable window manager in current version supports it.

Similar situation is with xrandr. You need at least version 1.2 to use XRRSetCrtcConfig. Though it was released in end of 2006. Implement it in STK/irrlicht would be fine. What do you think about it?

[cand]

That is fine. Nobody really games on that old X. It's different to the WM situation, because people use WMs they like, and several have not (and likely will not) implemented netWM.

[deve]

Ok, I added fallback for window managers which don't support netwm in this commit:
https://github.com/supertuxkart/stk-cod ... 457c8e5492