linux + fullscreen + dual monitors

[Jabberwocky]

When I run an ogre app in fullscreen on a dual-monitor linux setup, it works, but with a couple serious problems:

1. When running fullscreen, one of the monitors turns black. This isn't a big problem in itself, but after the app exits, this monitor stays black. You need to reboot or mess with your graphics config to get the 2nd monitor back again. This happens on on both NVidia cards and ATI cards. It happens with the ogre SampleBrowser (1.7.x).

2. The resolution of the ogre app seems to affect the desktop, so that after the ogre app exits, the desktop resolution has been altered. This might only be a problem with my app, and not the ogre SampleBrowser - I'll need to look into that more closely.

I've done a lot of googling and fullscreen linux games are known to have a lot of issues. When torchlight linux originally shipped there were fullscreen problems, but it seems like they managed to fix this in a patch. Historically, some versions of SDL also had fullscreen problems, but it looks like they might have fixed this in recent versions too.

Any super-awesome-smart linux guys around here who know about this kind of stuff?

[areay]

Hi Jabberwocky,

Just for you I setup my PC with dual monitors and played my Ogre 1.8 game in full screen and it was all good. The second monitor did not turn black and did not require any 'xrandr' or other tricks to revive it. However, when I chose to run in full screen mode with a res lower than my native res then I saw the same things you did. The 2nd monitor turned black and then did not turn on. When I went into the Gnome display settings the 2nd monitor had been set to off and I just had to click it back on to get it back.

I'll do some more messing around because I'm interested in it too. Playing around with XOrg and dual screens is a messy, ugly business at the best of times

Here's my setup:
Fedora 17
Gnome 3.4.2
Intel HD4000 graphics (builtin to an i7)
2 x 24" Dell @ 1920 x 1200 (standard desktop split across two monitors)

[areay]

Hmm, Steam's 'Big Picture' mode works fine at full-screen at any res on a separate monitor so it doesn't look like it's a constraint placed on me by Gnome or my GPU, must be an Ogre thing. Will try and test with some other 3D games when possible.

[Jabberwocky]

Thanks areay - good find on the "res lower than my native res" angle - I'll check into that.

If I can confirm that behaviour in my own game, I wonder if restoring the desktop resolution on shutdown will fix the problem? A crash would then still leave things in a bad state, but the game is pretty stable.

For sure, I'm definitely interested in the fullscreen behaviour of other games.

[Jabberwocky]

Confirmed -
If I run the game in a resolution matching the monitor resolution, all problems go away.

Hmm, I wonder what other games/engines are doing which allow them to use different resolutions without messing up dual monitors? Maybe it's worth digging through the SDL v2.0 (unstable dev) code to see what they're doing.

[Jabberwocky]

Or alternatively, if there's any linux-specific graphics forums where we could look for help?

[TheSHEEEP]

If you find one, please tell.

[areay]

Jabberwocky, can you test if the same thing happens on Windows? Just to be sure.

[Jabberwocky]

Nope, it does not happen on windows.

[Jabberwocky]

If you find one, please tell.

It was probably wishful thinking.

[dermont]

I ran into similar problems regarding fullscreen + dual monitors on a NVidia card.

Code: Select all

Native resolution 1024x768 
Driver 310.40 GeForce 9800 GTX/9800 GTX+
TwinView(Clone)

There were some discussions related to the Display Frequency/Metamode id on the http://www.ogre3d.org/forums/viewtopic. ... &start=200 which I think may contribute to my particular problem.

For me what I could see was the actual display frequency used for each monitor should be quite close. I would be interested in knowing the setups e.g. matching Video Modes/display frequencies for each monitor.

Unfortunately I can only test this on the only similar Video Modes/display frequency (640x480).

Code: Select all

./nv-control-dpy --add-metamode "CRT-0: 640x480_60 @640x480 +0+0, DFP-1: 640x480 @640x480 +0+0"
>> added MetaMode "CRT-0: 640x480_60 @640x480 +0+0, DFP-1: 640x480 @640x480 +0+0"; pOut: "id=116"

Selecting Rendering Settings 640x480 - 116(metamode id) the second monitor displays properly. Note you have to delete ogre.cfg since the Display Frequency always appears to default to the first Display Frequency associated with the Video Mode.

Since this also occurs on ATI cards it may not be related but I would also be interested in any solutions you come up with.

[Jabberwocky]

Thanks for posting dermont.

The discussion revolving around metamodes and NVidia-specific workarounds is interesting. But I've been testing some SDL2.0 example programs, and they run fine in fullscreen on my dual-monitor linux system. The only small problem is these SDL2.0 programs seem to change the resolution of the 2nd (non-active) monitor while the SDL app is running. But everything is restored properly when the app exits, even if I kill it with control-C. So SDL2's behaviour is acceptable to me, while Ogre's is not.

So obviously it is possible to handle linux fullscreen without the problems Ogre3D encounters. Not that I blame Ogre - you see people bitching about linux fullscreen everywhere on the net, so it's apparently not an easy problem to solve. But as mentioned before, SDL 2.0 has solved it (at least on my machine). So, knowing it can be fixed makes me want to ignore workarounds like the metamodes stuff, which would be hacky and cumbersome to the user.

So, right now I'm thinking I need to either:
1. Learn from what SDL2.0 does, and fix Ogre's GLX renderer. Tricky, because I don't know anything about linux window code.
2. Use SDL directly to create my window (there's some wiki articles about this), but I remember trying this before and it was far from trivial, particularly since I currently use OIS for input.
3. (hack) detect if we're on a dual-monitor system, and if so add a restriction that the resolution must be set to maximum, matching the monitor resolution. As noted above, this is the one case where linux+dual monitors+fullscreen seems to behave properly.

Over the many hours I've been banging my head on this problem, I've began to wonder how much I'd have to pay someone who has worked on SDL to come over and fix the ogre code.

[areay]

I've logged this as a bug https://ogre3d.atlassian.net/browse/OGRE-169

Jabberwocky, can you tell me what Ogre version, OS & desktop_manager you're using please? I'd like to be able to add some more information to the bug about what systems it is affecting.

About SDL; I remember a while ago some SDL dev (the author?) was suggesting changes to X/Xorg to allow better window management for Linux. He seemed to have solved it using some sort of kludge/magic. I believe Valve hired him to help with the Steam Linux port and I'd guess that his/her knowledge of this area would've been one of the reasons for that.

[Jabberwocky]

Ogre version 1.7.4.
(I've looked at more recent ogre code and haven't seen any significant changes to the GLX windows code).

I am running Ubuntu 12.04 x32 with an AMD Radeon HD 7770, dual monitor. I'm using the standard Ubuntu WM (Unity).


Here are some additional system specs from my playtesters who also encountered the multi-monitor black screen bug.

Playtester system 1:
Ubuntu 12.04 x64 with nvidia Geforce GTX 560 with Twin View (dual monitors setup through nvidia drivers).

Playtester system 2:
I am running a Lubuntu 12.10 on a AMD Athlon(tm) II X2 240 (oc to
3.7ghz) with 4gb ddr3 and an HD5770.
I have 2 montiors, well TV's. Both 1080p screens, 1 using the HDMI out
from an HD5770, and the other using an DVI 2 HDMI from the same card.

Playtester system 3:
I am on Ubuntu 12.04 x64 with a AMD HD 6950 and triple monitors.

I guess it's possibly an Ubuntu specific problem, but I'm not sure. The game was tested under some other distros, but I'm not sure whether they were multi-monitor or not.

____

Thanks for posting the bug, Areay. It should be logged. Although unfortunately I don't think anyone on the current Ogre team has the linux expertise to fix this. The GLX windowing code hasn't changed much in a long time, and based on some old forum posts, it looks like any of the most recent changes were mostly done by community.

[Jabberwocky]

About SDL; I remember a while ago some SDL dev (the author?) was suggesting changes to X/Xorg to allow better window management for Linux. He seemed to have solved it using some sort of kludge/magic. I believe Valve hired him to help with the Steam Linux port and I'd guess that his/her knowledge of this area would've been one of the reasons for that.

Yeah, I've been looking at the SDL code. It has a couple different paths to go fullscreen:

Code: Select all

X11_BeginWindowFullscreenLegacy
X11_SetWindowFullscreenViaWM

This behaviour is defined by an environment variable called "SDL_VIDEO_X11_LEGACY_FULLSCREEN".

The SetWindowFullscreenViaWM function has this comment:

/* This asks the Window Manager to handle fullscreen for us. Most don't do it right, though. */

Although on my machine, I don't have the SDL_VIDEO_X11_LEGACY_FULLSCREEN env var set, so it's using the X11_SetWindowFullscreenViaWM path***. Ogre uses somewhat similar looking code (requesting fullscreen via a call to XSendEvent). But Ogre must obviously do something differently (maybe in the original window creation?) since the bug is present in Ogre but not in SDL2.

*** Although actually SDL does a few additional checks to see which fullscreen mode it should run in (legacy or non-legacy). I'll need to run a debugger to see for sure which code path is running on my machine.

[Jabberwocky]

So, here's the route I've decided to go. I'm going to use SDL (2.0) to handle the windowing on linux, which has got a pretty good rep for working on multiple linux distros/windows managers.

I feed the SDL window into ogre using the "currentGLContext" createRenderWindow param, as described here in the wiki.

Unlike in that wiki article, I'm using OIS for input rather than SDL. (I only want SDL for the x11 window code.) This created a problem because SDL wants to grab control of the input too, which doesn't jive with OIS. But I found a way around that by modifying the SDL source code. I posted this solution over on the OIS forums.

SDL 2.0 comes with sample test programs which all use code from a file called SDL_test_common.c. This code, along with the SDL sample programs (e.g. testgl2.c) show how to properly initialize SDL with opengl, and I borrowed heavily from this code to write my own SDL initialization. It's far from a trivial task, but I've got things mostly working, and it solves the linux + fullscreen + dual monitors problem.

Regarding fixing this problem in Ogre, I think either:
1. Someone with a lot of linux x11 experience needs to look closely at the SDL2.0 code, and use it to fix Ogre's code, or
2. We should revive the deprecated ogre code which seems to do exactly what I described above (see RenderSystems/GL/src/SDL/OgreSDLGLSupport.cpp). This may be a better solution, since then ogre can rely on the ongoing development of SDL to handle the poorly standardized windows managers available across the various linux distros.

[areay]

Regarding fixing this problem in Ogre, I think either:
1. Someone with a lot of linux x11 experience needs to look closely at the SDL2.0 code, and use it to fix Ogre's code, or

I'm keen to have a crack at this option. It's hopefully just some check/parameter_setting happening in one of these functions SDL_Init() ,SDL_SetVideoMode(), at the end of the day both SDL and Ogre3D are using XLib. Don't bet your Linux port's release date on it though

Sounds like you could be pretty close to fixing it yourself though, you're in pretty deep man!

[areay]

I guess it's possibly an Ubuntu specific problem, but I'm not sure. The game was tested under some other distros, but I'm not sure whether they were multi-monitor or not.

Yeah, it's happening for me under Fedora 17 with Gnome3 so it's not a distro specific thing.

[Jabberwocky]

Yeah, it's happening for me under Fedora 17 with Gnome3 so it's not a distro specific thing.

Oh yeah, you mentioned that above, thanks for reminding me.

I'm keen to have a crack at this option. It's hopefully just some check/parameter_setting happening in one of these functions SDL_Init() ,SDL_SetVideoMode(), at the end of the day both SDL and Ogre3D are using XLib. Don't bet your Linux port's release date on it though

Cool!

Agreed re: XLib. If you were to just compare the exact calls and parameters made to XLib from both Ogre and SDL, maybe the problem would become apparent. I tried to do that, but it seems there's enough difference between Ogre and SDL's approach to confuse an XLib noob like myself.

Sounds like you could be pretty close to fixing it yourself though, you're in pretty deep man!

I think so!

[Jabberwocky]

Regarding consulting the SDL code to fix ogre -
I would definitely look at SDL2 rather than 1.x, because:
1. I think SDL2 has fixed some issues that were present in 1.x
2. Licensing - SDL2 is zlib, SDL1.x is lgpu, and lgpu is finnicky about being used/consulted for differently licensed projects.

Even with zlib, any code directly taken from SDL and used in ogre would have some licensing implications (I think Ogre's source would have to include a zlib license), but if we're just inspecting the SDL XLib calls to understand what's going on, I don't think that's an issue.

[Jabberwocky]

Alright, I've got the linux build running under SDL2.
One odd thing is that the game will run in a virtualbox using ogre, but not with SDL - not sure why yet.

In case anyone wants to take it for a test run, send me a shout at jabberwocky AT salvationprophecy.com

[areay]

Hey Jabberwocky,

I'm still working on this but unfortunately I've had me second monitor cruelly stolen by the wife. I'm trying to find a 2nd one on the cheap now.

[Jabberwocky]

Understood - hogging all the monitors doesn't make you popular around the house.

[Jabberwocky]

An update to getting Ogre3D working with SDL windowing:

Much of the forum/wiki discussion around using Ogre3D with SDL suggests using the "currentGLContext" and/or "externalGLControl" params to Ogre::Root::createRenderWindow.
I got this approach to work on AMD cards, but when the game ran on an NVidia card, there were all sorts of problems. I struggled with this for a long time, but never found a satisfactory solution.

Then, I changed approaches. I stopped trying to use "currentGLContext" and "externalGLControl". Instead, I switched to using the "parentWindowHandle" param instead. Under this new plan, I created an SDL window WITHOUT an opengl context. Specifically, I no longer called this:

Code: Select all

   SDLTest_CommonState *state;
   // ...
   state->window_flags |= SDL_WINDOW_OPENGL;

or this:

Code: Select all

   SDL_GLContext context;
   // ...
   context = SDL_GL_CreateContext(state->windows[0]);

I now just create the SDL window, then pass this window into ogre to use as follows:

Code: Select all

      Ogre::NameValuePairList misc;
     
      String strWindowHandle = StringConverter::toString( GraphicsUtil::GetWindowHandle() );
      misc["parentWindowHandle"] = strWindowHandle; 

      m_pWindow = m_pOgreRoot->createRenderWindow("MainRenderWindow", state->window_w, state->window_h, false, &misc);
      m_pWindow->setVisible( true );

Here's the helper function used above:

Code: Select all

unsigned long GraphicsUtil::GetWindowHandle()
{
   unsigned long hWnd = 0;

#if OGRE_PLATFORM == OGRE_PLATFORM_LINUX
   if ( GraphicsSys()->HasSDLWindow() )
   {
      SDL_SysWMinfo sysInfo;
      SDL_VERSION( &sysInfo.version );

      if ( SDL_GetWindowWMInfo( GraphicsSys()->GetSDLWindow(), &sysInfo ) <= 0 )
      {
         // TODO
         // printf("%s : %d\n", SDL_GetError(), sysInfo.window);
         assert( false );
      }
      hWnd = sysInfo.info.x11.window;
      return hWnd;
   }      
#endif

   GraphicsSys()->GetRenderWindow()->getCustomAttribute( "WINDOW", &hWnd );
   
   return hWnd;
}

This avoids the headache and problems surrounding trying to get Ogre3D to function properly using the opengl context created by SDL. With this new approach, SDL just handles the windowing (which solves the linux+dual monitors+fullscreen issues), while allowing Ogre3D to run "normally" (creating and handling it's own opengl context as usual).

These code snippets have a few custom classes for my game, but hopefully they'll help out anyone else trying to accomplish the same thing.

[AlexeyKnyshev]

Jabberwocky, thanx a lot for you sdl2 guide. Anything works fine except following thing. In Ubuntu (compiz or unity) at some moment starts to think that my app "Is not responding" and dims window created by sdl (not by Ogre). First of all I thought that it happened because I don't process some system events (through SDL_PollEvent) but it was wrong ... Why compiz / unity / x11 think that my app "is not responding"? Thanks a lot.