Crashes when $DISPLAY isn't :0.0

[pubby]

When I try to run a SFML program from a different X screen (DISPLAY=:0.1) I get this error:

X Error of failed request:  BadMatch (invalid parameter attributes)
  Major opcode of failed request:  78 (X_CreateColormap)
  Serial number of failed request:  64
  Current serial number in output stream:  66

This means I can only run SFML programs on one monitor of my multi-monitor setup.

Also, when I try to run a SFML program when $DISPLAY is blank (such as from a tmux session not connected to X) I get a segfault. This isn't a huge issue, but I'd much prefer it to exit gracefully with an error rather than crashing.

Backtrace:

0x00007ffff79c50a8 in ?? () from /usr/lib/libsfml-window.so.2
(gdb) backtrace
#0  0x00007ffff79c50a8 in ?? () from /usr/lib/libsfml-window.so.2
#1  0x00007ffff79c120d in ?? () from /usr/lib/libsfml-window.so.2
#2  0x00007ffff79c17f7 in sf::GlResource::GlResource() () from /usr/lib/libsfml-window.so.2
#3  0x00007ffff79c2d5e in sf::Window::Window() () from /usr/lib/libsfml-window.so.2
#4  0x00007ffff77a5299 in sf::RenderWindow::RenderWindow(sf::VideoMode, sf::String const&, unsigned int, sf::ContextSettings const&) () from /usr/lib/libsfml-graphics.so.2

[Bromeon]

When I try to run a SFML program from a different X screen (DISPLAY=:0.1) I get this error [...] This means I can only run SFML programs on one monitor of my multi-monitor setup.

Yes, SFML currently provides no support for multi-monitor setups... This is something we plan to improve in a future version. Concerning this specific X11 error, I'm not sure what the exact reason why it fails is.

Also, when I try to run a SFML program when $DISPLAY is blank (such as from a tmux session not connected to X) I get a segfault.

An error message is output, see #508. Please make sure you use the latest GitHub revision when reporting problems, it doesn't make to investigate things that have been fixed meanwhile :)

[eXpl0it3r]

I've no idea how X11 works, but even if SFML doesn't provide an API to define where to open window, shouldn't it work if you define it directly with the WM settings? I probably misunderstand what DISPLAY does...

[MarioLiebisch]

I don't think any program should crash just because it doesn't handle potential multi-monitor setups. So sounds like X11's fault, unless SFML is indeed doing something wrong somewhere. It doesn't really matter whether SFML respects that setting, it should at least work. :)

[eXpl0it3r]

@pubby Can you please provide more information? Otherwise I'll have to close this issue.

[pubby]

@eXpl0it3r The problem is that even if you define what display to use directly SFML crashes if its not the zero-th display. This is how you do that:

DISPLAY=:0.1
./tutorial_program

[jcowgill]

I managed to reproduce this using Xephyr by running Xephyr :1 -screen 500x500 -screen 500x500 which creates two screens on :1.0 and :1.1

I had a small look at this and I think that GlxContext::selectBestVisual is returning visuals for the wrong screen. Currently the XCB port (#694) fixes this since it only considers visuals from the default screen instead of all screens.

---

@pubby My multi monitor setup using RandR (which seems to be what most WMs are using these days) works fine with SFML. Is there a good reason for using the old multiple xorg screens way which I can't see?

[eXpl0it3r]

The XCB branch has been merged, as such this issue could be reinvestigated.

[TankOs]

@pubby, can you try latest master?

[binary1248]

Bump.

@pubby can you confirm that this is still an issue with the xcb changes? If not, then there is no point in keeping this issue open.

[binary1248]

I couldn't reproduce this on master, even when running multiple TTYs using DISPLAY=:0.0, DISPLAY=:1.0 etc.

If no connection to the X server can be established, an error message is emitted and the application aborts as expected.

I'm closing this issue for now. If you have more information that can help us reproduce the issue, feel free to provide it here.