Full screen not really full screen on Linux?

SDL Development
1

Hi everyone,

I’m trying to get my game to work properly in full screen with input
grabbed and relative mouse mode, and it’s being problematic with
non-native resolutions (i.e. my screen can display up to 1920x1200 and
that’s its native resolution; anything smaller is non-native). I’m
simply calling SDL_CreateWindow() with flags of SDL_WINDOW_OPENGL |
SDL_WINDOW_FULLSCREEN. This is happening on up-to-date Debian testing
amd64 with KDE 4.

First of all, the display mode change occurs before the window is even
created, which results in displaying a cropped and rescaled fragment
of the desktop (or all the other active windows) through a kind of a
"crop rectangle" for a few seconds while the game starts. So this is
not really a full-screen, it’s just the crop window matching the
dimensions of an undecorated game window.

Then, the input grab does not take effect until the game has actually
been rendering for a few seconds already. This makes it possible to
move the mouse around while the game is loading, and since the “crop
rectangle” follows the cursor, it’s possible to navigate it somewhere
where the game window isn’t even visible.

I’ve noticed that Valve games on Linux actually create a window that
matches desktop dimensions, render to an offscreen buffer and then
manually upscale it when blitting before swapping buffers. Is that the
only way to achieve “real” full-screen?

Are these known issues? Any suggestions on how to alleviate them?

Regards,

Leszek

2

First of all: beware that proper fullscreen on Linux is broken except
when the resolution is unchanged :confused:

2013/7/7, Leszek Godlewski :

First of all, the display mode change occurs before the window is even
created, which results in displaying a cropped and rescaled fragment
of the desktop (or all the other active windows) through a kind of a
"crop rectangle" for a few seconds while the game starts. So this is
not really a full-screen, it’s just the crop window matching the
dimensions of an undecorated game window.

Actually, I recall Windows doing the same thing (fullscreen OpenGL is
just an undecorated window that covers the entire screen). It’s just
that you saw the window take a while to pop up after the video mode
was changed… That sounds like an issue, but it’s still real
fullscreen.

Then, the input grab does not take effect until the game has actually
been rendering for a few seconds already. This makes it possible to
move the mouse around while the game is loading, and since the “crop
rectangle” follows the cursor, it’s possible to navigate it somewhere
where the game window isn’t even visible.

Yeah, this is what I mean with “fullscreen is broken”.

I’ve noticed that Valve games on Linux actually create a window that
matches desktop dimensions, render to an offscreen buffer and then
manually upscale it when blitting before swapping buffers. Is that the
only way to achieve “real” full-screen?

There’s a “fake fullscreen” mode that does this. The video mode is not
changed (which means you’re stuck to the current resolution no matter
what), but the window is forced to take up the entire screen. It has
some of the other behaviors from windowed mode too.

And yes, I also want proper fullscreen to be fixed (at least for
resolutions lower than the current one which are listed as valid), but
it seems it’s low priority…

3

Hmm. Okay then, I’ll tell the QA department it’s not my fault. :slight_smile: I’ll
try to look into that part of SDL code if I have the time.

At the moment I’ll just make the desktop resolution the default
setting and call it a day.

Thanks for the quick reply!

2013/7/7 Sik the hedgehog <sik.the.hedgehog at gmail.com>:> First of all: beware that proper fullscreen on Linux is broken except

when the resolution is unchanged :confused:

2013/7/7, Leszek Godlewski <@Leszek_Godlewski>:

First of all, the display mode change occurs before the window is even
created, which results in displaying a cropped and rescaled fragment
of the desktop (or all the other active windows) through a kind of a
"crop rectangle" for a few seconds while the game starts. So this is
not really a full-screen, it’s just the crop window matching the
dimensions of an undecorated game window.

Actually, I recall Windows doing the same thing (fullscreen OpenGL is
just an undecorated window that covers the entire screen). It’s just
that you saw the window take a while to pop up after the video mode
was changed… That sounds like an issue, but it’s still real
fullscreen.

Then, the input grab does not take effect until the game has actually
been rendering for a few seconds already. This makes it possible to
move the mouse around while the game is loading, and since the “crop
rectangle” follows the cursor, it’s possible to navigate it somewhere
where the game window isn’t even visible.

Yeah, this is what I mean with “fullscreen is broken”.

I’ve noticed that Valve games on Linux actually create a window that
matches desktop dimensions, render to an offscreen buffer and then
manually upscale it when blitting before swapping buffers. Is that the
only way to achieve “real” full-screen?

There’s a “fake fullscreen” mode that does this. The video mode is not
changed (which means you’re stuck to the current resolution no matter
what), but the window is forced to take up the entire screen. It has
some of the other behaviors from windowed mode too.

And yes, I also want proper fullscreen to be fixed (at least for
resolutions lower than the current one which are listed as valid), but
it seems it’s low priority…

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

4

If you ever figure out what SDL is going wrong, can you tell us? :S
It’s like the video mode switch works, but the desktop stays at the
same size (resulting in that “crop window” you were talking about).

May want to only take care of when the resolution goes lower if you
decide to look into it. It’s unlikely the user may want to use
anything higher than the desktop’s resolution, and some drivers seem
to have issue reporting resolutions higher than the current one
anyway.

5

I would recommend using SDL_WINDOW_FULLSCREEN_DESKTOP for all platforms.
Each platform has its own quirks with mode switching, and that’s the
safest way to do fullscreen on all of them.On Sun, Jul 7, 2013 at 4:06 AM, Leszek Godlewski wrote:

Hi everyone,

I’m trying to get my game to work properly in full screen with input
grabbed and relative mouse mode, and it’s being problematic with
non-native resolutions (i.e. my screen can display up to 1920x1200 and
that’s its native resolution; anything smaller is non-native). I’m
simply calling SDL_CreateWindow() with flags of SDL_WINDOW_OPENGL |
SDL_WINDOW_FULLSCREEN. This is happening on up-to-date Debian testing
amd64 with KDE 4.

First of all, the display mode change occurs before the window is even
created, which results in displaying a cropped and rescaled fragment
of the desktop (or all the other active windows) through a kind of a
"crop rectangle" for a few seconds while the game starts. So this is
not really a full-screen, it’s just the crop window matching the
dimensions of an undecorated game window.

Then, the input grab does not take effect until the game has actually
been rendering for a few seconds already. This makes it possible to
move the mouse around while the game is loading, and since the “crop
rectangle” follows the cursor, it’s possible to navigate it somewhere
where the game window isn’t even visible.

I’ve noticed that Valve games on Linux actually create a window that
matches desktop dimensions, render to an offscreen buffer and then
manually upscale it when blitting before swapping buffers. Is that the
only way to achieve “real” full-screen?

Are these known issues? Any suggestions on how to alleviate them?

Regards,

Leszek

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

6

Why not just remove SDL_FULLSCREEN then >_>’

I think the problem is more apparent with games, given they’re usually
very expensive on the hardware. One of the most common things to do to
help improve performance is reduce the rendering resolution, however
not all players like being restricted to a window. In this case proper
fullscreen is going to be needed (other than really ugly workarounds
like the one mentioned before).

Yes, I keep hearing arguments against fullscreen. “It causes windows
to be rearranged” we had this issue back in the Windows 9x days and in
the end it was considered just a minor inconvenience. “Games that
crash don’t restore the original resolution” (outside Windows) we used
to have this before too. Annoying, yes, but a crash usually means
something else went wrong too, and the user can just switch back to
the original resolution. “Games force fullscreen on the user” that’s
the fault of the game, not the feature. “Fullscreen breaks
multimonitor setups” that’s because the whole concept behind
multimonitor is broken (they should be separate workspaces, not behave
like a single giant monitor), and even then most people still have
single monitor setups where this shouldn’t be an issue.

Back on track: does anybody know how to get X to resize the desktop to
the new video mode? Even if it results in rearranged windows, I think
we can agree that’s a much better side-effect than having a cursor
that can move off-screen.

Also can we get SDL to fail to create a fullscreen window if it can’t
be handled properly, please? At least we wouldn’t have confused
programmers because fullscreen isn’t working as expected.

2013/7/8, Sam Lantinga :> I would recommend using SDL_WINDOW_FULLSCREEN_DESKTOP for all platforms.

Each platform has its own quirks with mode switching, and that’s the
safest way to do fullscreen on all of them.

On Sun, Jul 7, 2013 at 4:06 AM, Leszek Godlewski wrote:

Hi everyone,

I’m trying to get my game to work properly in full screen with input
grabbed and relative mouse mode, and it’s being problematic with
non-native resolutions (i.e. my screen can display up to 1920x1200 and
that’s its native resolution; anything smaller is non-native). I’m
simply calling SDL_CreateWindow() with flags of SDL_WINDOW_OPENGL |
SDL_WINDOW_FULLSCREEN. This is happening on up-to-date Debian testing
amd64 with KDE 4.

First of all, the display mode change occurs before the window is even
created, which results in displaying a cropped and rescaled fragment
of the desktop (or all the other active windows) through a kind of a
"crop rectangle" for a few seconds while the game starts. So this is
not really a full-screen, it’s just the crop window matching the
dimensions of an undecorated game window.

Then, the input grab does not take effect until the game has actually
been rendering for a few seconds already. This makes it possible to
move the mouse around while the game is loading, and since the “crop
rectangle” follows the cursor, it’s possible to navigate it somewhere
where the game window isn’t even visible.

I’ve noticed that Valve games on Linux actually create a window that
matches desktop dimensions, render to an offscreen buffer and then
manually upscale it when blitting before swapping buffers. Is that the
only way to achieve “real” full-screen?

Are these known issues? Any suggestions on how to alleviate them?

Regards,

Leszek

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

7

I have banged my head against the X11 fullscreen issues many times with no
success. Ryan has a window manager proposal in that moves this into the
window manager, which is really where mode switches belong, but it’s
gaining traction slowly.

If someone wants to dig in and tackle this issue, I’d appreciate it.

Cheers!On Sun, Jul 7, 2013 at 8:23 PM, Sik the hedgehog <sik.the.hedgehog at gmail.com wrote:

Why not just remove SDL_FULLSCREEN then >_>’

I think the problem is more apparent with games, given they’re usually
very expensive on the hardware. One of the most common things to do to
help improve performance is reduce the rendering resolution, however
not all players like being restricted to a window. In this case proper
fullscreen is going to be needed (other than really ugly workarounds
like the one mentioned before).

Yes, I keep hearing arguments against fullscreen. “It causes windows
to be rearranged” we had this issue back in the Windows 9x days and in
the end it was considered just a minor inconvenience. “Games that
crash don’t restore the original resolution” (outside Windows) we used
to have this before too. Annoying, yes, but a crash usually means
something else went wrong too, and the user can just switch back to
the original resolution. “Games force fullscreen on the user” that’s
the fault of the game, not the feature. “Fullscreen breaks
multimonitor setups” that’s because the whole concept behind
multimonitor is broken (they should be separate workspaces, not behave
like a single giant monitor), and even then most people still have
single monitor setups where this shouldn’t be an issue.

Back on track: does anybody know how to get X to resize the desktop to
the new video mode? Even if it results in rearranged windows, I think
we can agree that’s a much better side-effect than having a cursor
that can move off-screen.

Also can we get SDL to fail to create a fullscreen window if it can’t
be handled properly, please? At least we wouldn’t have confused
programmers because fullscreen isn’t working as expected.

2013/7/8, Sam Lantinga <@slouken>:

I would recommend using SDL_WINDOW_FULLSCREEN_DESKTOP for all platforms.
Each platform has its own quirks with mode switching, and that’s the
safest way to do fullscreen on all of them.

On Sun, Jul 7, 2013 at 4:06 AM, Leszek Godlewski wrote:

Hi everyone,

I’m trying to get my game to work properly in full screen with input
grabbed and relative mouse mode, and it’s being problematic with
non-native resolutions (i.e. my screen can display up to 1920x1200 and
that’s its native resolution; anything smaller is non-native). I’m
simply calling SDL_CreateWindow() with flags of SDL_WINDOW_OPENGL |
SDL_WINDOW_FULLSCREEN. This is happening on up-to-date Debian testing
amd64 with KDE 4.

First of all, the display mode change occurs before the window is even
created, which results in displaying a cropped and rescaled fragment
of the desktop (or all the other active windows) through a kind of a
"crop rectangle" for a few seconds while the game starts. So this is
not really a full-screen, it’s just the crop window matching the
dimensions of an undecorated game window.

Then, the input grab does not take effect until the game has actually
been rendering for a few seconds already. This makes it possible to
move the mouse around while the game is loading, and since the “crop
rectangle” follows the cursor, it’s possible to navigate it somewhere
where the game window isn’t even visible.

I’ve noticed that Valve games on Linux actually create a window that
matches desktop dimensions, render to an offscreen buffer and then
manually upscale it when blitting before swapping buffers. Is that the
only way to achieve “real” full-screen?

Are these known issues? Any suggestions on how to alleviate them?

Regards,

Leszek

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

8

I don’t know how to program X :confused: Tried looking around but didn’t find
much, other than the fact SDL seems to not set the viewport explicitly
(but this only sets the top left corner, rather than the clipping
rectangle) and that it should be flushing X after setting the video
mode (which probably explains the lag mentioned in the initial
message). I doubt that’s going to help much though.

Again what was the reason for making XRandR not the default? The only
issues I had was that it’d reset the gamma, but honestly, that’s
mostly an issue specific to my system and Nvidia’s drivers being dumb
than anything else, changing the video mode from the system settings
does exactly the same thing -_-’

One quick hack I thought was to prevent the mouse from being able to
go outside the window… at least that’d prevent it from scrolling
off-screen. Does SDL already attempt to do something like this
already? (I can see why grabbing the keyboard is an issue but grabbing
the mouse when the program is fullscreen and no other window has focus
shouldn’t be that much of an issue - at least unless multimonitor is
involved, but that already has a lot of other issues with fullscreen)

2013/7/8, Sam Lantinga :> I have banged my head against the X11 fullscreen issues many times with no

success. Ryan has a window manager proposal in that moves this into the
window manager, which is really where mode switches belong, but it’s
gaining traction slowly.

If someone wants to dig in and tackle this issue, I’d appreciate it.

Cheers!

On Sun, Jul 7, 2013 at 8:23 PM, Sik the hedgehog <@Sik_the_hedgehog wrote:

Why not just remove SDL_FULLSCREEN then >_>’

I think the problem is more apparent with games, given they’re usually
very expensive on the hardware. One of the most common things to do to
help improve performance is reduce the rendering resolution, however
not all players like being restricted to a window. In this case proper
fullscreen is going to be needed (other than really ugly workarounds
like the one mentioned before).

Yes, I keep hearing arguments against fullscreen. “It causes windows
to be rearranged” we had this issue back in the Windows 9x days and in
the end it was considered just a minor inconvenience. “Games that
crash don’t restore the original resolution” (outside Windows) we used
to have this before too. Annoying, yes, but a crash usually means
something else went wrong too, and the user can just switch back to
the original resolution. “Games force fullscreen on the user” that’s
the fault of the game, not the feature. “Fullscreen breaks
multimonitor setups” that’s because the whole concept behind
multimonitor is broken (they should be separate workspaces, not behave
like a single giant monitor), and even then most people still have
single monitor setups where this shouldn’t be an issue.

Back on track: does anybody know how to get X to resize the desktop to
the new video mode? Even if it results in rearranged windows, I think
we can agree that’s a much better side-effect than having a cursor
that can move off-screen.

Also can we get SDL to fail to create a fullscreen window if it can’t
be handled properly, please? At least we wouldn’t have confused
programmers because fullscreen isn’t working as expected.

2013/7/8, Sam Lantinga :

I would recommend using SDL_WINDOW_FULLSCREEN_DESKTOP for all
platforms.
Each platform has its own quirks with mode switching, and that’s the
safest way to do fullscreen on all of them.

On Sun, Jul 7, 2013 at 4:06 AM, Leszek Godlewski wrote:

Hi everyone,

I’m trying to get my game to work properly in full screen with input
grabbed and relative mouse mode, and it’s being problematic with
non-native resolutions (i.e. my screen can display up to 1920x1200 and
that’s its native resolution; anything smaller is non-native). I’m
simply calling SDL_CreateWindow() with flags of SDL_WINDOW_OPENGL |
SDL_WINDOW_FULLSCREEN. This is happening on up-to-date Debian testing
amd64 with KDE 4.

First of all, the display mode change occurs before the window is even
created, which results in displaying a cropped and rescaled fragment
of the desktop (or all the other active windows) through a kind of a
"crop rectangle" for a few seconds while the game starts. So this is
not really a full-screen, it’s just the crop window matching the
dimensions of an undecorated game window.

Then, the input grab does not take effect until the game has actually
been rendering for a few seconds already. This makes it possible to
move the mouse around while the game is loading, and since the “crop
rectangle” follows the cursor, it’s possible to navigate it somewhere
where the game window isn’t even visible.

I’ve noticed that Valve games on Linux actually create a window that
matches desktop dimensions, render to an offscreen buffer and then
manually upscale it when blitting before swapping buffers. Is that the
only way to achieve “real” full-screen?

Are these known issues? Any suggestions on how to alleviate them?

Regards,

Leszek

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

2013/7/8 Sik the hedgehog <sik.the.hedgehog at gmail.com>

I don’t know how to program X :confused: Tried looking around but didn’t find

much, other than the fact SDL seems to not set the viewport explicitly

I don’t think anyway here really is an expert in X (which might probably
part of the problem!), for instance I did the multi monitor code “by
example”, just following the xrandr.c source and having lots of patience :slight_smile:

Again what was the reason for making XRandR not the default? The only

It is the default. From SDL_x11modes.c:

/#define X11MODES_DEBUG/

/* I’m becoming more and more convinced that the application should never

  • use XRandR, and it’s the window manager’s responsibility to track and
  • manage display modes for fullscreen windows. Right now XRandR is
    completely
  • broken with respect to window manager behavior on every window manager
    that
  • I can find. For example, on Unity 3D if you show a fullscreen window
    while
  • the resolution is changing (within ~250 ms) your window will retain the
  • fullscreen state hint but be decorated and windowed.*
  • However, many people swear by it, so let them swear at it. :slight_smile:
    /
    /    #define XRANDR_DISABLED_BY_DEFAULT*/

Anyway. As the subject keeps coming up on the list, we may just as well
give it another go…the problem is in my system things seem to work quite
well :slight_smile:
I’m posting my results below (xrandr output with testrendercopyex running).
I had seen the “mouse pans desktop” bug before, but it isn’t present now.

This is on Kubuntu 13.04 64bits, nVidia binary drivers 313.30, latest SDL
from HG. Visually everything looks as it should AFAICT, and it’s backed up
by the xrandr output.
If people with problems in this regard are interested in solving this once
and for all (if it’s a solvable problem, which remains to be seen), I
advise you use the latest SDL, run similar tests, and give a detailed
report of what’s going.

xrandr -q

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 1920x1080+0+0 (normal left inverted right x axis y axis)
531mm x 299mm
1920x1080 60.0*+
1680x1050 60.0
1440x900 75.0 59.9
1280x1024 75.0 60.0
1280x960 60.0
1280x800 59.8
1152x864 75.0
1024x768 75.0 70.1 60.0
800x600 75.0 72.2 60.3 56.2
640x480 75.0 72.8 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)

testrendercopyex --fullscreen --geometry 640x480 --display 1

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 1920x1080+0+0 (normal left inverted right x axis y axis)
531mm x 299mm
1920x1080 60.0*+
1680x1050 60.0
1440x900 75.0 59.9
1280x1024 75.0 60.0
1280x960 60.0
1280x800 59.8
1152x864 75.0
1024x768 75.0 70.1 60.0
800x600 75.0 72.2 60.3 56.2
640x480 75.0 72.8 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)

testrendercopyex --fullscreen --geometry 640x480 --display 1

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 1920x1080+0+0 (normal left inverted right x axis y axis)
531mm x 299mm
1920x1080 60.0*+
1680x1050 60.0
1440x900 75.0 59.9
1280x1024 75.0 60.0
1280x960 60.0
1280x800 59.8
1152x864 75.0
1024x768 75.0 70.1 60.0
800x600 75.0 72.2 60.3 56.2
640x480 75.0 72.8 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)

–
Gabriel.

10

I think the problem is more apparent with games, given they’re usually
very expensive on the hardware. One of the most common things to do to
help improve performance is reduce the rendering resolution, however
not all players like being restricted to a window. In this case proper
fullscreen is going to be needed (other than really ugly workarounds
like the one mentioned before).

Not that I disagree with you, but the theory with
SDL_WINDOW_FULLSCREEN_DESKTOP is that you render to a framebuffer object
that’s at whatever lower resolution you want, then use
GL_EXT_framebuffer_blit (or draw a single textured quad) to the higher
resolution. Some argue that the GL scales up the smaller framebuffer
better than your LCD would in any case, and you can spend less on pixel
shaders and fillrate by rendering at the lower resolution.

Extra credit for doing it like Valve: draw the game at the lower
resolution in an FBO, blast it to the screen, then draw the UI at native
resolution on top of it, so text doesn’t get blurry, etc.

Yes, I keep hearing arguments against fullscreen. “It causes windows
to be rearranged” we had this issue back in the Windows 9x days and in
the end it was considered just a minor inconvenience. “Games that
crash don’t restore the original resolution” (outside Windows) we used
to have this before too. Annoying, yes, but a crash usually means
something else went wrong too, and the user can just switch back to
the original resolution.

This is an X11-specific issue, and we have a proposal pending to fix
this, by adding a protocol to make the window manager handle resolution
changes, so a crashed fullscreen game goes away and the window manager
cleans up properly.

Also can we get SDL to fail to create a fullscreen window if it can’t
be handled properly, please?

That’s the stickier point, I suppose. As far as I know, it does work
on some X11 configurations (without FULLSCREEN_DESKTOP). If it’s not
working, and it’s an SDL bug, we should strive to fix it.

Part of me thinks we’re going to have to abandon X11 for Wayland and/or
Mir before we can completely fix this on Linux machines, though.

–ryan.

11

Going to test this again later today, if I forget to do it make sure
to nag me, OK?

2013/7/8, Ryan C. Gordon :>

I think the problem is more apparent with games, given they’re usually
very expensive on the hardware. One of the most common things to do to
help improve performance is reduce the rendering resolution, however
not all players like being restricted to a window. In this case proper
fullscreen is going to be needed (other than really ugly workarounds
like the one mentioned before).

Not that I disagree with you, but the theory with
SDL_WINDOW_FULLSCREEN_DESKTOP is that you render to a framebuffer object
that’s at whatever lower resolution you want, then use
GL_EXT_framebuffer_blit (or draw a single textured quad) to the higher
resolution. Some argue that the GL scales up the smaller framebuffer
better than your LCD would in any case, and you can spend less on pixel
shaders and fillrate by rendering at the lower resolution.

Extra credit for doing it like Valve: draw the game at the lower
resolution in an FBO, blast it to the screen, then draw the UI at native
resolution on top of it, so text doesn’t get blurry, etc.

Yes, I keep hearing arguments against fullscreen. “It causes windows
to be rearranged” we had this issue back in the Windows 9x days and in
the end it was considered just a minor inconvenience. “Games that
crash don’t restore the original resolution” (outside Windows) we used
to have this before too. Annoying, yes, but a crash usually means
something else went wrong too, and the user can just switch back to
the original resolution.

This is an X11-specific issue, and we have a proposal pending to fix
this, by adding a protocol to make the window manager handle resolution
changes, so a crashed fullscreen game goes away and the window manager
cleans up properly.

Also can we get SDL to fail to create a fullscreen window if it can’t
be handled properly, please?

That’s the stickier point, I suppose. As far as I know, it does work
on some X11 configurations (without FULLSCREEN_DESKTOP). If it’s not
working, and it’s an SDL bug, we should strive to fix it.

Part of me thinks we’re going to have to abandon X11 for Wayland and/or
Mir before we can completely fix this on Linux machines, though.

–ryan.

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

12

Er should have removed the quote there. Oh well.

13

OK, tested this with a lower resolution and so far the error seems to
be the same as before: the video mode changes, but the desktop size
does not. Also it seems to take quite a while before it finally
settles. Basically I have all the issues mentioned in the initial
message. At least Alt+Tab works fine, even video mode switching.

Trying to figure out a workaround. Was thinking on restricting where
the cursor can go to prevent panning, but apparently that isn’t doable
with SDL’s current API (and I can imagine why). Another option is to
use relative mouse events so it’s possible to mess with the cursor
(and force it in a specific position constantly - no harm, given you
shouldn’t be able to get to other windows anyway!). Does anybody think
this may work?

14

2013/7/10 Sik the hedgehog <sik.the.hedgehog at gmail.com>

OK, tested this with a lower resolution and so far the error seems to
be the same as before: the video mode changes, but the desktop size
does not. Also it seems to take quite a while before it finally
settles. Basically I have all the issues mentioned in the initial
message. At least Alt+Tab works fine, even video mode switching.

Trying to figure out a workaround. Was thinking on restricting where
the cursor can go to prevent panning, but apparently that isn’t doable
with SDL’s current API (and I can imagine why). Another option is to
use relative mouse events so it’s possible to mess with the cursor
(and force it in a specific position constantly - no harm, given you
shouldn’t be able to get to other windows anyway!). Does anybody think
this may work?

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

Ubuntu? KDE / Unity? nVidia / AMD / Intel? Is it using XRandr?–
Gabriel.

15

2013/7/10, Gabriel Jacobo :

Ubuntu?

Ubuntu 12.04

KDE / Unity?

Gnome Classic

nVidia / AMD / Intel?

Nvidia (proprietary drivers)
Hardware: Nvidia 7300 GS (yeah…)

Is it using XRandr?

Whatever one is the default (so I guess it’s XRandR?)

Also gave a try to relative mouse events, and um, while they work…
well, let’s say that first I need to find out a way to handle them
while the cursor is outside the window. I guess that merely getting
them to work as I want is going to take more effort than even trying
the hack workaround for fullscreen >_<

16

Oh wow my idea worked O_O

Here’s what I’m doing:

  1. If the program goes fullscreen, enable relative mouse mode. After
    this we’ll use SDL_GetRelativeMouseMode to tell whether it’s enabled
    or not.

  2. If relative mouse mode is on, every so often (in my case I went for
    once per frame) cause the cursor to wrap to the bottom-right of the
    screen, then the top-left, then the center (all three in a row) using
    SDL_WrapMouseInWindow. This forces the visible desktop area to stay on
    the window.

  3. Use events to keep track of the mouse position (not
    SDL_GetMouseState). When relative mode is disabled, just store the
    coordinates as-is. When relative mode is enabled, just add them to the
    previous position (add clamping here to prevent the mouse from going
    off-screen). Use the coordinates you store here as the actual cursor
    coordinates.

OK, a proper fix in SDL would be better, but for those who want to
support proper fullscreen on Linux, consider trying that. There’s
still the ugly delay when going fullscreen, but eh, I think we can
live with it (we already had to in the early days of fullscreen on
Windows after all and nobody complained).

17

After some more testing:

2013/7/10, Sik the hedgehog <@Sik_the_hedgehog>:

  1. If relative mouse mode is on, every so often (in my case I went for
    once per frame) cause the cursor to wrap to the bottom-right of the
    screen, then the top-left, then the center (all three in a row) using
    SDL_WrapMouseInWindow. This forces the visible desktop area to stay on
    the window.

Just warp the mouse to the top-left corner. Don’t bother with the
other two warps. This seems to be the safest in fact.

Note that all this I described is for handling the case where the
resolution is lower than the desktop one (SDL fails in a different way
when going for a higher one, but users would rarely want to try it
anyway). Also this probably doesn’t cope well with multimonitor
setups, but you know what’s the deal, fullscreen never worked nicely
with multimonitor for starters so you probably will want to suggest
going windowed or do the fake fullscreen thing (at least now you can
use SDL to detect when there are multiple monitors).