Opening windows on different X displays (Ubuntu 12)

SDL Development
1

I have a fixed setup with two displays not connected with Xinerama (which
is necessary), which my company will use as for a software/hardware package
we’re developing for production.

In my code, I have two windows, each must be full screen on the different
displays. Previously, I had extended my displays, and used SDL’s display
enumeration to get the bounding areas of each display, then opened a
fullscreen window inside each bounding area, which worked fine, but
wouldn’t translate well for trying to detect with display is :0.0 and :0.1
(which is necessary in our fixed setup).

Now that I have to two separate displays, both windows fullscreen in the
same desktop, which isn’t going to work very well for my employers’
purposes.

Is there any sort of work around outside of developing two applications and
connecting them via a socket?

-Alex

2

This reminds me, were the fullscreen issues fixed in the first place?
Whenever I try to go fullscreen in my game everything goes awry…

2013/3/19, Alex Barry <alex.barry at gmail.com>:> I have a fixed setup with two displays not connected with Xinerama (which

is necessary), which my company will use as for a software/hardware package
we’re developing for production.

In my code, I have two windows, each must be full screen on the different
displays. Previously, I had extended my displays, and used SDL’s display
enumeration to get the bounding areas of each display, then opened a
fullscreen window inside each bounding area, which worked fine, but
wouldn’t translate well for trying to detect with display is :0.0 and :0.1
(which is necessary in our fixed setup).

Now that I have to two separate displays, both windows fullscreen in the
same desktop, which isn’t going to work very well for my employers’
purposes.

Is there any sort of work around outside of developing two applications and
connecting them via a socket?

-Alex

3

Full screen works fine for me in Ubuntu 12 with AMD Catalyst drivers.On Tue, Mar 19, 2013 at 4:28 PM, Sik the hedgehog < sik.the.hedgehog at gmail.com> wrote:

This reminds me, were the fullscreen issues fixed in the first place?
Whenever I try to go fullscreen in my game everything goes awry…

2013/3/19, Alex Barry <@Alex_Barry>:

I have a fixed setup with two displays not connected with Xinerama (which
is necessary), which my company will use as for a software/hardware
package
we’re developing for production.

In my code, I have two windows, each must be full screen on the different
displays. Previously, I had extended my displays, and used SDL’s display
enumeration to get the bounding areas of each display, then opened a
fullscreen window inside each bounding area, which worked fine, but
wouldn’t translate well for trying to detect with display is :0.0 and
:0.1
(which is necessary in our fixed setup).

Now that I have to two separate displays, both windows fullscreen in the
same desktop, which isn’t going to work very well for my employers’
purposes.

Is there any sort of work around outside of developing two applications
and
connecting them via a socket?

-Alex

SDL mailing list
SDL at lists.libsdl.org
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org

4

This is irrelevant in your set-up as separete X11 screens behave
independently. The full-screen problem is about xrandr multi-head one big
screen consisting of more monitors.

In my opinion, current SDL-1.2 full-screen handling is still not ideal and it
misbehaves in some cases, but as user can decide which way to go using
environment variable, it’s still better than before. (See
https://bugzilla.redhat.com/show_bug.cgi?id=859907#c2.)

– Petr

-------------- next part --------------
A non-text attachment was scrubbed…
Name: not available
Type: application/pgp-signature
Size: 230 bytes
Desc: not available
URL: http://lists.libsdl.org/pipermail/sdl-libsdl.org/attachments/20130320/71fa70b9/attachment.pgpOn Tue, Mar 19, 2013 at 10:45:20PM -0400, Alex Barry wrote:

Full screen works fine for me in Ubuntu 12 with AMD Catalyst drivers.

5

Separate X11 displays is very relevant, as I want to open one window on the
left screen, and one on the right using the one instance of an application.
There is no fullscreen problem at all.

I can throw in a export DISPLAY=:0.1 in there, but then both windows will
end up on the same X11 display.

Also, I’m use SDL2, not 1.2.On Wed, Mar 20, 2013 at 3:45 AM, Petr Pisar wrote:

On Tue, Mar 19, 2013 at 10:45:20PM -0400, Alex Barry wrote:

Full screen works fine for me in Ubuntu 12 with AMD Catalyst drivers.

This is irrelevant in your set-up as separete X11 screens behave
independently. The full-screen problem is about xrandr multi-head one big
screen consisting of more monitors.

In my opinion, current SDL-1.2 full-screen handling is still not ideal and
it
misbehaves in some cases, but as user can decide which way to go using
environment variable, it’s still better than before. (See
https://bugzilla.redhat.com/show_bug.cgi?id=859907#c2.)

– Petr

SDL mailing list
SDL at lists.libsdl.org
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org

6

Most of this is untested and a lot of it pulled from memory, so excuse me
if you tried this already and it didn’t work…

SDL scans for available screens in the current X11 display, and creates a
new SDL_VideoDisplay for each (yes, the names are confusing).

So, my strategy would be to call SDL_GetNumVideoDisplays to check that
there are actually two displays available, then SDL_GetNumDisplayModes for
each display, and iterate those two using SDL_GetDisplayMode to find a
suitable mode for each screen (or just wing it and
use SDL_GetCurrentDisplayMode)

Then, create two windows, and use SDL_SetWindowDisplayMode on each with the
modes you found in the previous step, and finally go full screen… did you
try this? Does it not work?

Also, full screen on Xinerama systems works fine AFAIK, if you change the
resolution of the desktop you get some hiccups when restoring the
resolution though.

2013/3/20 Alex Barry <alex.barry at gmail.com>> Separate X11 displays is very relevant, as I want to open one window on

the left screen, and one on the right using the one instance of an
application. There is no fullscreen problem at all.

I can throw in a export DISPLAY=:0.1 in there, but then both windows
will end up on the same X11 display.

Also, I’m use SDL2, not 1.2.

On Wed, Mar 20, 2013 at 3:45 AM, Petr Pisar wrote:

On Tue, Mar 19, 2013 at 10:45:20PM -0400, Alex Barry wrote:

Full screen works fine for me in Ubuntu 12 with AMD Catalyst drivers.

This is irrelevant in your set-up as separete X11 screens behave
independently. The full-screen problem is about xrandr multi-head one big
screen consisting of more monitors.

In my opinion, current SDL-1.2 full-screen handling is still not ideal
and it
misbehaves in some cases, but as user can decide which way to go using
environment variable, it’s still better than before. (See
https://bugzilla.redhat.com/show_bug.cgi?id=859907#c2.)

– Petr

SDL mailing list
SDL at lists.libsdl.org
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org

SDL mailing list
SDL at lists.libsdl.org
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org

–
Gabriel.

7

Xinerama isn’t an option because i need hardware acceleration (which I’m
under the impression that it gets disabled with Xinerama enabled) - I am
enumerating with SDL_VideoDisplay, but the problem is that the SDL_Rect
boundary for both screens start at 0, which means they get placed in the
same Display, because SDL isn’t aware that there are multiple X displays
available.

I did notice that using SDL_GetWindowWMInfo() gives me access to a X11
Display*, but I don’t think it gives me the ability to get more information
on the different X11 Displays or how to move a window from one Display* to
another.On Wed, Mar 20, 2013 at 9:17 AM, Gabriel Jacobo wrote:

Most of this is untested and a lot of it pulled from memory, so excuse me
if you tried this already and it didn’t work…

SDL scans for available screens in the current X11 display, and creates a
new SDL_VideoDisplay for each (yes, the names are confusing).

So, my strategy would be to call SDL_GetNumVideoDisplays to check that
there are actually two displays available, then SDL_GetNumDisplayModes for
each display, and iterate those two using SDL_GetDisplayMode to find a
suitable mode for each screen (or just wing it and
use SDL_GetCurrentDisplayMode)

Then, create two windows, and use SDL_SetWindowDisplayMode on each with
the modes you found in the previous step, and finally go full screen… did
you try this? Does it not work?

Also, full screen on Xinerama systems works fine AFAIK, if you change the
resolution of the desktop you get some hiccups when restoring the
resolution though.

2013/3/20 Alex Barry <@Alex_Barry>

Separate X11 displays is very relevant, as I want to open one window on
the left screen, and one on the right using the one instance of an
application. There is no fullscreen problem at all.

I can throw in a export DISPLAY=:0.1 in there, but then both windows
will end up on the same X11 display.

Also, I’m use SDL2, not 1.2.

On Wed, Mar 20, 2013 at 3:45 AM, Petr Pisar wrote:

On Tue, Mar 19, 2013 at 10:45:20PM -0400, Alex Barry wrote:

Full screen works fine for me in Ubuntu 12 with AMD Catalyst drivers.

This is irrelevant in your set-up as separete X11 screens behave
independently. The full-screen problem is about xrandr multi-head one big
screen consisting of more monitors.

In my opinion, current SDL-1.2 full-screen handling is still not ideal
and it
misbehaves in some cases, but as user can decide which way to go using
environment variable, it’s still better than before. (See
https://bugzilla.redhat.com/show_bug.cgi?id=859907#c2.)

– Petr

SDL mailing list
SDL at lists.libsdl.org
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org

SDL mailing list
SDL at lists.libsdl.org
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org

–
Gabriel.

SDL mailing list
SDL at lists.libsdl.org
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org

8

If you’re using NVIDIA binary drivers, hardware acceleration isn’t disabled
with Xinerama.

SDL provides an API to query the displays and get their relative positions,
so you should have all the info you need to do it in a single process.

If you really do need two X servers then you’ll need two processes, or to
radically change the x11 video driver in SDL.On Wed, Mar 20, 2013 at 7:39 AM, Alex Barry <alex.barry at gmail.com> wrote:

Xinerama isn’t an option because i need hardware acceleration (which I’m
under the impression that it gets disabled with Xinerama enabled) - I am
enumerating with SDL_VideoDisplay, but the problem is that the SDL_Rect
boundary for both screens start at 0, which means they get placed in the
same Display, because SDL isn’t aware that there are multiple X displays
available.

I did notice that using SDL_GetWindowWMInfo() gives me access to a X11
Display*, but I don’t think it gives me the ability to get more information
on the different X11 Displays or how to move a window from one Display* to
another.

On Wed, Mar 20, 2013 at 9:17 AM, Gabriel Jacobo wrote:

Most of this is untested and a lot of it pulled from memory, so excuse me
if you tried this already and it didn’t work…

SDL scans for available screens in the current X11 display, and creates a
new SDL_VideoDisplay for each (yes, the names are confusing).

So, my strategy would be to call SDL_GetNumVideoDisplays to check that
there are actually two displays available, then SDL_GetNumDisplayModes for
each display, and iterate those two using SDL_GetDisplayMode to find a
suitable mode for each screen (or just wing it and
use SDL_GetCurrentDisplayMode)

Then, create two windows, and use SDL_SetWindowDisplayMode on each with
the modes you found in the previous step, and finally go full screen… did
you try this? Does it not work?

Also, full screen on Xinerama systems works fine AFAIK, if you change the
resolution of the desktop you get some hiccups when restoring the
resolution though.

2013/3/20 Alex Barry <alex.barry at gmail.com>

Separate X11 displays is very relevant, as I want to open one window on
the left screen, and one on the right using the one instance of an
application. There is no fullscreen problem at all.

I can throw in a export DISPLAY=:0.1 in there, but then both windows
will end up on the same X11 display.

Also, I’m use SDL2, not 1.2.

On Wed, Mar 20, 2013 at 3:45 AM, Petr Pisar wrote:

On Tue, Mar 19, 2013 at 10:45:20PM -0400, Alex Barry wrote:

Full screen works fine for me in Ubuntu 12 with AMD Catalyst drivers.

This is irrelevant in your set-up as separete X11 screens behave
independently. The full-screen problem is about xrandr multi-head one
big
screen consisting of more monitors.

In my opinion, current SDL-1.2 full-screen handling is still not ideal
and it
misbehaves in some cases, but as user can decide which way to go using
environment variable, it’s still better than before. (See
https://bugzilla.redhat.com/show_bug.cgi?id=859907#c2.)

– Petr

SDL mailing list
SDL at lists.libsdl.org
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org

SDL mailing list
SDL at lists.libsdl.org
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org

–
Gabriel.

SDL mailing list
SDL at lists.libsdl.org
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org

SDL mailing list
SDL at lists.libsdl.org
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org

9

Two processes is an option, it just means adding in some extra logic into
my application, which isn’t a huge problem, but I was wondering if there
may have been a different or better solution.

Thanks for the advice, Sam,
-AlexOn Wed, Mar 20, 2013 at 12:51 PM, Sam Lantinga wrote:

If you’re using NVIDIA binary drivers, hardware acceleration isn’t
disabled with Xinerama.

SDL provides an API to query the displays and get their relative
positions, so you should have all the info you need to do it in a single
process.

If you really do need two X servers then you’ll need two processes, or to
radically change the x11 video driver in SDL.

On Wed, Mar 20, 2013 at 7:39 AM, Alex Barry <@Alex_Barry> wrote:

Xinerama isn’t an option because i need hardware acceleration (which I’m
under the impression that it gets disabled with Xinerama enabled) - I am
enumerating with SDL_VideoDisplay, but the problem is that the SDL_Rect
boundary for both screens start at 0, which means they get placed in the
same Display, because SDL isn’t aware that there are multiple X displays
available.

I did notice that using SDL_GetWindowWMInfo() gives me access to a X11
Display*, but I don’t think it gives me the ability to get more information
on the different X11 Displays or how to move a window from one Display* to
another.

On Wed, Mar 20, 2013 at 9:17 AM, Gabriel Jacobo wrote:

Most of this is untested and a lot of it pulled from memory, so excuse
me if you tried this already and it didn’t work…

SDL scans for available screens in the current X11 display, and creates
a new SDL_VideoDisplay for each (yes, the names are confusing).

So, my strategy would be to call SDL_GetNumVideoDisplays to check that
there are actually two displays available, then SDL_GetNumDisplayModes for
each display, and iterate those two using SDL_GetDisplayMode to find a
suitable mode for each screen (or just wing it and
use SDL_GetCurrentDisplayMode)

Then, create two windows, and use SDL_SetWindowDisplayMode on each with
the modes you found in the previous step, and finally go full screen… did
you try this? Does it not work?

Also, full screen on Xinerama systems works fine AFAIK, if you change
the resolution of the desktop you get some hiccups when restoring the
resolution though.

2013/3/20 Alex Barry <@Alex_Barry>

Separate X11 displays is very relevant, as I want to open one window on
the left screen, and one on the right using the one instance of an
application. There is no fullscreen problem at all.

I can throw in a export DISPLAY=:0.1 in there, but then both windows
will end up on the same X11 display.

Also, I’m use SDL2, not 1.2.

On Wed, Mar 20, 2013 at 3:45 AM, Petr Pisar wrote:

On Tue, Mar 19, 2013 at 10:45:20PM -0400, Alex Barry wrote:

Full screen works fine for me in Ubuntu 12 with AMD Catalyst drivers.

This is irrelevant in your set-up as separete X11 screens behave
independently. The full-screen problem is about xrandr multi-head one
big
screen consisting of more monitors.

In my opinion, current SDL-1.2 full-screen handling is still not ideal
and it
misbehaves in some cases, but as user can decide which way to go using
environment variable, it’s still better than before. (See
https://bugzilla.redhat.com/show_bug.cgi?id=859907#c2.)

– Petr

SDL mailing list
SDL at lists.libsdl.org
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org

SDL mailing list
SDL at lists.libsdl.org
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org

–
Gabriel.

SDL mailing list
SDL at lists.libsdl.org
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org

SDL mailing list
SDL at lists.libsdl.org
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org

SDL mailing list
SDL at lists.libsdl.org
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org

10

I think the forum thread “SDL2 and Multiple Screens in Linux” [1] is
relevant.

To me this is a real issue as well. I have a notebook with a triple head
setup. The first display (internal monitor) is driven by the integrated
Intel graphics card. Both external monitors (2nd and 3rd display) are
attached to the Nvidia graphics card.
Unfortunately, AFAIK it is not possible to have both graphics cards
offering GLX which forces me to disable the acceleration of the first
screen.

+++++++++++++++++++++ ++++++++++++++++++++++++ ++++++++++++++++++++++++

  •               + +                      + +                      +
  • internal monitor + + external monitor 1 + + external monitor 2 +
  • :0.0 (no GLX) + + :0.1 (with GLX) + + :0.2 (with GLX) +
  •               + +                      + +                      +

+++++++++++++++++++++ ++++++++++++++++++++++++ ++++++++++++++++++++++++

As SDL always opens up the display on the first screen and given the
fact that there is no GLX available, SDL does not work for applications
which require OpenGL acceleration (passing SDL_WINDOW_OPENGL to
SDL_CreateWindow). I do not have this problem for any SDL 1.2
applications as SDL 1.2 respects the DISPLAY variable.

Am I doing stuff wrong (please have a look at the attached test program)
or is my setup just unsupported by the current SDL2 state?

1: http://forums.libsdl.org/viewtopic.php?t=8812On 03/20/2013 03:39 PM, Alex Barry wrote:

Xinerama isn’t an option because i need hardware acceleration (which I’m
under the impression that it gets disabled with Xinerama enabled) - I am
enumerating with SDL_VideoDisplay, but the problem is that the SDL_Rect
boundary for both screens start at 0, which means they get placed in the
same Display, because SDL isn’t aware that there are multiple X displays
available.

-------------- next part --------------
A non-text attachment was scrubbed…
Name: separatescreenissues.c
Type: text/x-csrc
Size: 977 bytes
Desc: not available
URL: http://lists.libsdl.org/pipermail/sdl-libsdl.org/attachments/20130323/94f209e3/attachment.c

11

SDL 2.0 uses the DISPLAY environment variable as well. I don’t have a
multi-X server configuration here. Can you build a debug version of SDL
and trace through what it’s doing?On Sat, Mar 23, 2013 at 7:54 AM, Reto Schneider < mailinglisten at reto-schneider.ch> wrote:

I think the forum thread “SDL2 and Multiple Screens in Linux” [1] is
relevant.

To me this is a real issue as well. I have a notebook with a triple head
setup. The first display (internal monitor) is driven by the integrated
Intel graphics card. Both external monitors (2nd and 3rd display) are
attached to the Nvidia graphics card.
Unfortunately, AFAIK it is not possible to have both graphics cards
offering GLX which forces me to disable the acceleration of the first
screen.

+++++++++++++++++++++ ++++++++++++++++++++++++ ++++++++++++++++++++++++

  •               + +                      + +                      +
  • internal monitor + + external monitor 1 + + external monitor 2 +
  • :0.0 (no GLX) + + :0.1 (with GLX) + + :0.2 (with GLX) +
  •               + +                      + +                      +

+++++++++++++++++++++ ++++++++++++++++++++++++ ++++++++++++++++++++++++

As SDL always opens up the display on the first screen and given the
fact that there is no GLX available, SDL does not work for applications
which require OpenGL acceleration (passing SDL_WINDOW_OPENGL to
SDL_CreateWindow). I do not have this problem for any SDL 1.2
applications as SDL 1.2 respects the DISPLAY variable.

Am I doing stuff wrong (please have a look at the attached test program)
or is my setup just unsupported by the current SDL2 state?

1: http://forums.libsdl.org/viewtopic.php?t=8812

On 03/20/2013 03:39 PM, Alex Barry wrote:

Xinerama isn’t an option because i need hardware acceleration (which I’m
under the impression that it gets disabled with Xinerama enabled) - I am
enumerating with SDL_VideoDisplay, but the problem is that the SDL_Rect
boundary for both screens start at 0, which means they get placed in the
same Display, because SDL isn’t aware that there are multiple X displays
available.

SDL mailing list
SDL at lists.libsdl.org
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org

12

Yep. It does result in the same observation reported in the forum:

a) In the function SDL_CreateWindow, the x and y variables created with
the SDL_WINDOWPOS_CENTERED_DISPLAY macro do not get propagated to the
window variable. [1]
b) The variable window gets passed to the X11_CreateWindow function [2].
c) Within X11_CreateWindow, the function SDL_GetDisplayForWindow[3] gets
called with the variable window passed (note: the window variable does
not have the magic values set by the SDL_WINDOWPOS_CENTERED_DISPLAY macro)
d) SDL_GetWindowDisplayIndex gets called by SDL_GetDisplayForWindow
e) SDL_GetWindowDisplayIndex always returns 0. Reason for this:
The code tries to figure out, based on the display bounds, on which
screen the window should be placed[4]. As there are three screens and
all of them start at 0/0 (unlike Xinerama, Twinview), this approach does
not work and pretty much always returns the first display index.

I guess we have to fix SDL_GetWindowDisplayIndex.

1: http://hg.libsdl.org/SDL/file/d9f3d2e3bd07/src/video/SDL_video.c#l1229
2: http://hg.libsdl.org/SDL/file/d9f3d2e3bd07/src/video/SDL_video.c#l1252
3:
http://hg.libsdl.org/SDL/file/d9f3d2e3bd07/src/video/x11/SDL_x11window.c#l333
4: http://hg.libsdl.org/SDL/file/d9f3d2e3bd07/src/video/SDL_video.c#l973On 03/24/2013 01:09 AM, Sam Lantinga wrote:

I don’t have a multi-X server configuration here. Can you build
a debug version of SDL and trace through what it’s doing?

13

SDL_GetWindowDisplayIndex is relative to the X/Display instance, so if each
of your monitors runs within it’s own X/Display, then the display index
will always be 0. This isn’t an SDL issue, this is how X11 works.On Sat, Mar 23, 2013 at 10:52 PM, Reto Schneider < mailinglisten at reto-schneider.ch> wrote:

On 03/24/2013 01:09 AM, Sam Lantinga wrote:

I don’t have a multi-X server configuration here. Can you build
a debug version of SDL and trace through what it’s doing?

Yep. It does result in the same observation reported in the forum:

a) In the function SDL_CreateWindow, the x and y variables created with
the SDL_WINDOWPOS_CENTERED_DISPLAY macro do not get propagated to the
window variable. [1]
b) The variable window gets passed to the X11_CreateWindow function [2].
c) Within X11_CreateWindow, the function SDL_GetDisplayForWindow[3] gets
called with the variable window passed (note: the window variable does
not have the magic values set by the SDL_WINDOWPOS_CENTERED_DISPLAY macro)
d) SDL_GetWindowDisplayIndex gets called by SDL_GetDisplayForWindow
e) SDL_GetWindowDisplayIndex always returns 0. Reason for this:
The code tries to figure out, based on the display bounds, on which
screen the window should be placed[4]. As there are three screens and
all of them start at 0/0 (unlike Xinerama, Twinview), this approach does
not work and pretty much always returns the first display index.

I guess we have to fix SDL_GetWindowDisplayIndex.

1: http://hg.libsdl.org/SDL/file/d9f3d2e3bd07/src/video/SDL_video.c#l1229
2: http://hg.libsdl.org/SDL/file/d9f3d2e3bd07/src/video/SDL_video.c#l1252
3:

http://hg.libsdl.org/SDL/file/d9f3d2e3bd07/src/video/x11/SDL_x11window.c#l333
4: http://hg.libsdl.org/SDL/file/d9f3d2e3bd07/src/video/SDL_video.c#l973

SDL mailing list
SDL at lists.libsdl.org
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org

14

That’s true, probably the problem should be fixed somewhere else.

The problem is, that the platform agnostic SDL_* functions depends on
display numbers different from 0 to be encoded in the x/y values. In the
X11_* context, the SDL_Window x/y values are expected to be absolute. So
when passing a SDL_Window struct used in the X11_* context to a SDL_*
function, it simply can no longer extract the display information (in a
non TwinView/Xinerama environment).

Any suggestions for a fix?On 03/24/2013 04:05 AM, Alex Barry wrote:

SDL_GetWindowDisplayIndex is relative to the X/Display instance, so if
each of your monitors runs within it’s own X/Display, then the display
index will always be 0. This isn’t an SDL issue, this is how X11 works.

15

For myself, I convinced my boss that Xinerama was a reasonable solution.
If you’re stuck using multiple x displays, you may want to create native
X11 windows and take over them with
SDL_CreateWindowfromhttp://wiki.libsdl.org/moin.fcg/SDL_CreateWindowFrom?highlight=(\bCategoryVideo\b)|(CategoryEnum)|(CategoryStruct)|(SGFunctions).
I believe it’s possible in native code to specify which X11 display you
want your window to target - once SDL takes it over, it shouldn’t matter
which display it’s running on, however, I don’t know how it will handle
input if you are using separate devices for each display.On Sun, Mar 24, 2013 at 8:21 AM, Reto Schneider < mailinglisten at reto-schneider.ch> wrote:

On 03/24/2013 04:05 AM, Alex Barry wrote:

SDL_GetWindowDisplayIndex is relative to the X/Display instance, so if
each of your monitors runs within it’s own X/Display, then the display
index will always be 0. This isn’t an SDL issue, this is how X11 works.

That’s true, probably the problem should be fixed somewhere else.

The problem is, that the platform agnostic SDL_* functions depends on
display numbers different from 0 to be encoded in the x/y values. In the
X11_* context, the SDL_Window x/y values are expected to be absolute. So
when passing a SDL_Window struct used in the X11_* context to a SDL_*
function, it simply can no longer extract the display information (in a
non TwinView/Xinerama environment).

Any suggestions for a fix?

SDL mailing list
SDL at lists.libsdl.org
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org

16

Most likely that would work for my case.

But I think SDL needs a SDL_CreateWindow function which works for any
setup. Otherwise people with a setup like yours and mine will never be
able to use the applications built on top of SDL2.On 03/24/2013 05:04 PM, Alex Barry wrote:

For myself, I convinced my boss that Xinerama was a reasonable solution.
If you’re stuck using multiple x displays, you may want to create
native X11 windows and take over them with SDL_CreateWindowfrom

17

Well, SDL needs an API that works in a cross-platform manner. Outside of
X11, not many platforms have the ability to have separate displays, so
having that as part of the main api would be unnecesary. It would be cool
to make something (perhaps called SDL_X11) that would abstract some basic
X11 windowing and UI functions into some sane and straight forward (like
SDL_Window *SDLX11_CreateWindow( display, width, height, depth, flags ) for
instance). I’d be more than willing to help but I don’t have much
experience with X11.On Sun, Mar 24, 2013 at 4:12 PM, Reto Schneider < mailinglisten at reto-schneider.ch> wrote:

On 03/24/2013 05:04 PM, Alex Barry wrote:

For myself, I convinced my boss that Xinerama was a reasonable solution.
If you’re stuck using multiple x displays, you may want to create
native X11 windows and take over them with SDL_CreateWindowfrom

Most likely that would work for my case.

But I think SDL needs a SDL_CreateWindow function which works for any
setup. Otherwise people with a setup like yours and mine will never be
able to use the applications built on top of SDL2.

SDL mailing list
SDL at lists.libsdl.org
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org