JA: Multimonitor handling is broken on Linux

[Civil]

Mouse stops working (I can see OS's cursor, but ingame one doesn't move) when playing fullscreen with multiple monitors on Linux.

[ensiform]

Please verify your issue as being OpenJK first, as it is SDL problem.

[xycaleth]

How do you know it's an SDL problem?

[ensiform]

Because multi-mon support was known to be broken still on Linux for SDL ._. And literally anything to do with window management cannot be handled by us directly anyway so I see no other option.

[Civil]

I disagree with that, because I never saw this issue with other SDL-based games under Linux. Mostlikely they are doing something differently, like instead of Fullscreen having fake-fullscreen under linux. So it's still can and must be worked around by you.

[ensiform]

We will NOT be making new OS specific workarounds. THAT is the must. There are also 0 developers working with linux actively and your configuration details are missing from the report to reproduce and requires actually having more than 1 which I do not. Either way its not accepting the mouse grab for any number of reasons so without more it still sounds like it is between SDL and your OS/driver.

And I disagree because you're comparing apples to oranges with older SDL1 games etc.

[Civil]

I'm comparing with current Steam games, which ALL are using SDL2, for example Wasteland 2.

If you don't have developers now, maybe you'll just leave this case open until there'll be somebody to work on this particular issue?

As about Configuration details - it's all on my laptop: Gentoo, kernel 4.2.3, KDE 5.5 (kwin as windowmanager), i7-4710HQ, Intel HD4600, xf86-video-intel 2.99.917, xorg-server 1.17.4, SDL 2.0.3. 2 monitors with different resolution - 2560x1440 + 1920x1080.

Is there anything else you need to accept this bug report?

P.S. And in cross-platform apps everybody DO OS-Specific workarounds, otherwise the software or a game will be broken on all except one which is primary for the developers.

[ensiform]

Are you explicitly using both monitors for the game, a specific monitor, is it not primary etc. It is still debatable whether its not at fault. The issue list displays lots of mouse grab and monitor related problems that have yet to be or have been but not in 2.0.3. Source available for wasteland2?

r_fullscreen 0 and r_noborder 1 would be fake fullscreen to try.

[Civil]

Sources for wasteland are not available. But if you know some open-source games that uses SDL2 you can name it and I'll also try how it works there.

Yeah, all r_fullscreen 0 are working ok.

About primary/secondary - it was running on secondary display, but it doesn't matter - cause running on primary causes the same behavior.

[ensiform]

ioquake3 test builds use the same implementation we do. ETLegacy has some changes but mostly same. Don't know how different unvanquished is. Unfortunately the latter two are governed under GPLv3 and we're not 2+ and can't change anyway.

[Civil]

I'll try to test it more in next couple of weeks, when I'll have more time.

[ensiform]

Yes some do, but we won't be doing that because it is intertwined unless its simple enough of a hack. FWIW 2.0.4 was tagged and released, could also try compiling from hg to see if it helps any just in case if the other games have issues or not.

Ultimately its difficult to tell whether its because of multiple monitors, mouse input or a mix of both or just bad SDL handling.

[ensiform]

It is kind of sad that there is no good implementation out there for people to use under various licenses. At least as far as when and where to use certain functions or do this if not multithreaded etc.