Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Issues derived from disabling Xrandr by default #678

Closed
SDLBugzilla opened this issue Feb 10, 2021 · 0 comments
Closed

Issues derived from disabling Xrandr by default #678

SDLBugzilla opened this issue Feb 10, 2021 · 0 comments

Comments

@SDLBugzilla
Copy link
Collaborator

@SDLBugzilla SDLBugzilla commented Feb 10, 2021

This bug report was migrated from our old Bugzilla tracker.

These attachments are available in the static archive:

Reported in version: 2.0.0
Reported for operating system, platform: Linux, x86_64

Comments on the original bug report:

On 2012-10-06 07:35:09 +0000, Gabriel Jacobo wrote:

Created attachment 967
Xrandr tests

As discussed on the list, I'm attaching a log of what I'm seeing on my system when requesting full screen windows with Xrandr enabled by default and disabled by default.

On 2012-10-06 11:09:15 +0000, Ryan C. Gordon wrote:

So this doesn't look like it's using the legacy fullscreen code (it's setting _NET_WM_STATE_FULLSCREEN), so it's definitely going to fail in various ways without XRandR.

Are these tests forcing something with an environment variable, or is this just what it's doing by default?

--ryan.

On 2012-10-06 15:49:42 +0000, Gabriel Jacobo wrote:

This is a standard run with no environment variables set that I know of. Later today I was talking with Sam and running tests with vanilla testsprite2 instead of my own code, and it was pretty much the same thing.

He made some improvements but that thing it does on one of my monitors where it creates a non existent window still happens (on the other monitor it works fine). What's strange is that, aside of me using KDE, we have practically similar systems (two different monitors running different desktop resolutions, nVidia binaries with Twinview enabled, Ubuntu 12.04).

Sidenote: I wonder why I'm not getting emails with notifications from the tracker.

On 2012-10-07 00:41:01 +0000, Sam Lantinga wrote:

This is just what it's doing by default. It's supposed to be seeing XVidMode support and forcing legacy fullscreen.

I sat and debugged with Gabriel today and got XVidMode working. He had the second display at 0,0, and XVidMode only works on the display at 0,0.

Gabriel, can you describe what's happening now that vidmode is enabled?

On 2012-10-07 07:27:25 +0000, Gabriel Jacobo wrote:

Created attachment 968
Several testsprite2 runs with http://hg.libsdl.org/SDL/rev/dd7e57847ea9

Attaching testsprite2 tests

On 2012-10-07 07:28:37 +0000, Gabriel Jacobo wrote:

Created attachment 969
System information

Adding a few useful logs from my system

On 2012-10-07 07:31:03 +0000, Gabriel Jacobo wrote:

As a baseline comparison, running Sword and Sworcery from the Humble Bundle works like a charm on either monitor using:

SDL_VIDEO_FULLSCREEN_HEAD=0 /opt/swordandsworcery/run.sh
SDL_VIDEO_FULLSCREEN_HEAD=1 /opt/swordandsworcery/run.sh

The other monitor stays active and in the case of the bigger monitor the game adds a letterbox as it probably can't support that high resolution.

On 2012-10-09 09:19:04 +0000, Gabriel Jacobo wrote:

I've been tracing this issue, a few comments:

Running: testsprite2 --display 1 --fullscreen --geometry 1920x1200

(I'm using the native resolution on testsprite2 because it provides me the best chance to be able to see something after things go bad, but the problem is the same on all resolutions.

When entering X11_BeginWindowFullscreenLegacy the window is already created at 1920x1200, it has a title bar and buttons.

When X11_BeginWindowFullscreenLegacy calls X11_GetDisplayBounds on line 1026, something funny happens, X11_GetDisplayBounds calls XineramaQueryScreens and in that precise moment, the video mode changes (every time).

xrandr -q (before X11_BeginWindowFullscreenLegacy -> X11_GetDisplayBounds -> XineramaQueryScreens)

creen 0: minimum 8 x 8, current 4480 x 1440, maximum 16384 x 16384
DVI-I-0 disconnected (normal left inverted right x axis y axis)
DVI-I-1 disconnected (normal left inverted right x axis y axis)
DVI-I-2 connected 1920x1200+0+0 (normal left inverted right x axis y axis) 519mm x 324mm
1920x1200 60.0*+
1600x1200 60.0
1280x1024 75.0 60.0
1152x864 75.0
1024x768 75.0 60.0
800x600 75.0 60.3
640x480 75.0 59.9
HDMI-0 disconnected (normal left inverted right x axis y axis)
DP-0 disconnected (normal left inverted right x axis y axis)
DVI-I-3 connected 2560x1440+1920+0 (normal left inverted right x axis y axis) 597mm x 336mm
2560x1440 60.0*+
DP-1 disconnected (normal left inverted right x axis y axis)

xrandr -q (after X11_BeginWindowFullscreenLegacy -> X11_GetDisplayBounds -> XineramaQueryScreens)

Screen 0: minimum 8 x 8, current 4480 x 1440, maximum 16384 x 16384
DVI-I-0 disconnected (normal left inverted right x axis y axis)
DVI-I-1 disconnected (normal left inverted right x axis y axis)
DVI-I-2 connected 1920x1200+0+0 (normal left inverted right x axis y axis) 519mm x 324mm
1920x1200 60.0*+
1600x1200 60.0
1280x1024 75.0 60.0
1152x864 75.0
1024x768 75.0 60.0
800x600 75.0 60.3
640x480 75.0 59.9
HDMI-0 disconnected (normal left inverted right x axis y axis)
DP-0 disconnected (normal left inverted right x axis y axis)
DVI-I-3 connected (normal left inverted right x axis y axis)
2560x1440 60.0 +
DP-1 disconnected (normal left inverted right x axis y axis)
gabo@Homero:~/download$

So, one monitor is active, but its displaying a metamode of 4480 x 1440, so I have to pan around the screen for the content.

Then the process continues, and at line 1054 of SDL_x11window.c (when calling XIfEvent(display, &ev, &isMapNotify, (XPointer)&data->fswindow) ) it really goes fullscreen and I can't see what happens anymore.

On 2012-10-09 12:10:00 +0000, Ryan C. Gordon wrote:

(In reply to comment # 7)

When X11_BeginWindowFullscreenLegacy calls X11_GetDisplayBounds on line 1026,
something funny happens, X11_GetDisplayBounds calls XineramaQueryScreens and in
that precise moment, the video mode changes (every time).

That's because it has to flush at that point, so the previous command to change the resolution is finally sent to the server at that moment.

--ryan.

On 2012-10-09 14:09:05 +0000, Gabriel Jacobo wrote:

I've finally figured out why this works on one monitor and not the other, it seems Sam added a restriction in X11_InitModes where use_vidmode will always be zero for screens not at the origin (0,0).
What this means, is that for monitor 0 in my system, which starts at 1920x0, SDL won't use Xrandr (disabled by default) nor XVidMode (not at the origin), thus, it'll remain at desktop resolution (which always worked with Xrandr anyway).

For monitor 1, XVidMode is enabled, and this shows the typical issues derived from the fact that it can't handle two monitors (the same that happened with the Xrandr code before it was made multimonitor "aware"), namely it changes the screen resolution thinking there's only one display, the combined metamode stays active, etc.

Thinking back, I believe I now understand why the SDL 1.2 games I tried seem to work, the trick is that they don't change the resolution at all, they just use whatever is available as the desktop resolution.

So, my personal conclusion is that XVidMode is not the way out of this mess, basically because it's not capable of handling multi monitors as it's not aware of their existence. Whatever issues Xrandr has (of which I personally have seen none), should be tried to work around, because there doesn't seem to exist a viable alternative.

The only flaw in my conclusion is of course that this seems to be working fine for you (I assume you use Twinview/Xinerama and non desktop resolutions for testsprite2).

On 2012-10-13 08:05:07 +0000, David Gow wrote:

Created attachment 971
Log of testsprite2 failing to show a window.

Just pointing out that I've had some issues with the Legacy fullscreen implementation on KDE4 too. In particular, any window that is made fullscreen is unmapped by KWin and has the 'hidden' flag in WM_STATE set. This makes SDL hide the fullscreen window as well. This happens even if no resolution changes occur (via use of SDL_VIDEO_X11_XVIDMODE=0 and SDL_VIDEO_X11_LEGACY_FULLSCREEN=1).

I'm not sure what causes this (I've spent about a week looking into it with very little luck), but it makes it impossible to fullscreen anything without forcing SDL to use the WM fullscreen path: otherwise the window is completely invisible. I've attached a log from testsprite2 with a lot of debug enabled (and a bunch of extra printfs scattered around). Hopefully someone with a better knowledge of X can help rat it out.

I've tried this on several machines running different distros (and therefore versions of KDE), as well as different monitor setups, and can reproduce this every time. Has anyone else experienced this?

-- David

On 2012-10-13 10:12:39 +0000, Gabriel Jacobo wrote:

David, I've seen that dissapearing window behaviour, it's either that or I get stuck with a 640x480 resolution on one monitor, a metamode equal to the original metamode I configured, the other monitor off, and the app hangs or I can't close it properly.

Did you see the same thing when using just one monitor? That's something I haven't tried.

On 2012-10-14 03:27:58 +0000, David Gow wrote:

Yeah: this appears on every KDE setup I've tried: with one monitor or two.
It also happens on laptop panels with the intel driver, and occurs whether compositing is enabled or not. Things like focus-stealing prevention don't seem to affect it either.

-- David

On 2012-10-22 21:50:38 +0000, Sam Lantinga wrote:

For reference:
ftp://download.nvidia.com/__XFree86/Linux-x86/310.14/__README/xconfigoptions.html#__IncludeImplicitMetaModes

On 2012-10-30 06:00:53 +0000, David Gow wrote:

I had a bit more of a look at this today. I'm still not entirely sure what the issue preventing legacy fullscreen windows from displaying at all on KDE is, but I suspect that KWin doesn't like the main window changing from being reparented into a WM-managed window to being reparented by the unmanaged fullscreen window.

As I see it, there are a couple of ways to fix this:

  1. Rewrite the legacy fullscreen code to work. In reality, this would involve reverting to the SDL1.2 style 3-window approach: the main window is a child of either a managed 'WM' window or a fullscreen 'FS' window. Unfortunately, this increases complexity of the X11 window management backend quite a bit, and adds a lot of bloat when using a more modern technique.

or:

  1. Setup a system of whitelists or blacklists for different WMs. The way XRandR is disabled at the moment is pretty simple. We could quite easily have list of WMs which support XRandR, and only use it there. The questions that this raises are largely implementation detail ones: do we blacklist or whitelist APIs (XRandR, Xinerama, XVidMode), fullscreen techniques (WM, Legacy, the new _NET_WM_STATE_FULLSCREEN_EXCLUSIVE) or both? I'm leaning towards just implementing the former (APIs) at the moment, and might whip up a patch later.

From my perspective, the problems with the XRandR method are fewer than those with the legacy method overall, so we could just re-enable it globally, I guess. The legacy implementation here certainly doesn't have the same level of flexibility that SDL1.2 had, especially with multimonitor setups.

Any thoughts?

-- David

On 2012-10-30 06:06:58 +0000, Gabriel Jacobo wrote:

I agree with you David, I think that until the fullscreen spec that Ryan and Sam made gets processed and eventually implemented, we can't escape some sort of "quirks" implementation, where we default to different modes for different window managers (Xrandr under KDE works great for me every time).
As a sidenote, last time I chatted with Sam his Ubuntu Unity system exploded when trying to use testsprite2, so even that certainty is gone now :)

On 2012-10-30 08:19:03 +0000, David Gow wrote:

Created attachment 983
Patch to re-enable XRandR for KWin and disable XVidMode

Here's a pretty basic patch to allow WM quirks for modesetting. I'm still not 100% convinced that this is the right way of doing things, but I can't think of anything better at the moment. Quite a bit of stuff needed shuffling around, so it could do with a bit of review, but it does at least get things displaying at all.

-- David

On 2012-11-05 04:48:14 +0000, Gabriel Jacobo wrote:

+1 for the patch, it may not be ideal, but it's something!

On 2013-02-22 02:32:01 +0000, David Gow wrote:

This is still present in KDE 4.10 and hg SDL, and it'd be great to get it resolved before 2.0 is released. I and other devs are including SDL_VIDEO_X11_XRANDR=1 in launch scripts and/or using the hint.

I've encountered a bit of instability with some other WMs as well (particularly on dual-screen setups), so I suspect the right answer is to simply re-enable xrandr by default. If you're set on keeping it disabled, it might be worth whitelisting WMs, too many of them don't work properly with legacy fullscreen.

Unless, of course, someone has worked out what the root cause is. Clearly one (or more) of the ways it deviates from SDL1.2 is causing problems.

-- David

On 2013-02-22 05:02:44 +0000, Gabriel Jacobo wrote:

Sam re enabled Xrandr by default here: http://hg.libsdl.org/SDL/diff/424a12862805/src/video/x11/SDL_x11modes.c

On 2013-02-22 07:12:24 +0000, David Gow wrote:

Gah: silly me!

Sure enough, everything's working fine when I'm using the right version.

Sorry,
-- David

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant