Disabling XRandR by default

SDL Development
1

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.

Because it’s so broken, I’ve disabled XRandR by default in SDL 2.0, so that
people have a good experience with it. You can still enable it via
environment variable or application hint (SDL_HINT_VIDEO_X11_XRANDR)

Ryan is working on a window manager spec proposal that will solve things
for all games that want to change resolution.

See ya!
–Sam

2

2012/10/4 Sam Lantinga

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.

Because it’s so broken, I’ve disabled XRandR by default in SDL 2.0, so
that people have a good experience with it. You can still enable it via
environment variable or application hint (SDL_HINT_VIDEO_X11_XRANDR)

Ryan is working on a window manager spec proposal that will solve things
for all games that want to change resolution.

This last update broke everything on my end, I’m using KDE, Ubuntu
(Kubuntu), latest nVidia binaries.

Starting my test program on monitor 0 on a non desktop resolution, the app
starts on the other monitor, monitor 0 blacks out, the app loses keyboard
focus, I can’t alt-tab nor alt+f4, I need to restart the X server.
Starting it on monitor 1 on a non desktop resolution yields the app at
desktop resolution on monitor 1 (what I would call an almost flawless win
:slight_smile: )
Starting it on monitor 0 on desktop resolution yields a minimized window
that does not appear in the taskbar ??

Anything in particular I should be doing in my code, or is it that KDE is
not really compatible with this way of switching modes?–
Gabriel.

3

Anything in particular I should be doing in my code, or is it that KDE
is not really compatible with this way of switching modes?

A lot of this code has changed in SDL2 recently, so this is likely our
bug. If this currently works in SDL 1.2 and is busted in SDL2, we want
(and need!) to hear about it right away. We have some important
SDL2-based stuff shipping soon and would like to catch these things now
if we can.

Sam and I have been beating the crap out of the X11 fullscreen code over
the last two weeks or so. The current “best” approach we have is what
we’re referring to as the “legacy” approach–that is, what SDL 1.2 did,
which has now been ported to SDL2.

The legacy approach looks something like this:

  • SDL changes the screen resolution with XVidMode.
  • SDL makes a big black window the size of this resolution and moves the
    mouse into it so it’s covering the visible portion of the virtual
    desktop, and then reparents its actual window on top of this.
  • SDL locks the vidmode so you can’t press ctrl-alt-minus to see the
    rest of your desktop.
  • SDL grabs the mouse and keyboard, so you can’t alt-tab out of this window.
  • Basically, we try to prevent you looking behind the curtain to see
    that we’re faking all this stuff in the top-left corner of your actual
    desktop.
  • If the app crashes, SDL (maybe) cleans everything up, but you might be
    left with a frozen mouse cursor or a crappy resolution.

This is the system we’ve used since the 90’s, when Loki needed a way to
do “fullscreen” games. It works well enough, assuming you have an
uncontroversial window manager, X server, and a measure of luck…but
we’ve all been burnt by it at some time or another, whether we’ve wanted
to switch to our email client for a second and couldn’t, wanted to use
the volume keys on our keyboards, had XRandR smoosh all our windows
down, landed on the wrong Xinerama monitor, or had a crash that just
left a big mess on our screens.

This method will be remaining in SDL2, because in terms of catching
every configuration, it generally works on all sorts of X servers and
Unices, but it’s really a technically offensive approach.

If we could change anything, there’s really only one way to do this for
X11 that makes sense: the window manager needs to be responsible for
fullscreen switches. Sam and I are drafting a proposal for a new window
manager protocol that allows a window to request a fullscreen mode from
the WM, which will be able to handle multiple apps competing for the
screen, allow access to your desktop and volume keys safely, and clean
up in case of app crashes.

As a side benefit, apps won’t have to screw around with X11 extensions
like XVidMode and XRandR…that will move into a central place in the
window manager. The app will just have to say to the WM “make me
fullscreen” in the same way that it currently says things like “maximize
me” or “iconify me.”

As a side note, there’s already something like this in the WM specs
("_NET_WM_STATE_FULLSCREEN"), and that’s great for telling OpenOffice
Impress to use the whole projector for your presentation or Firefox to
take up the whole desktop when you press F11, but it doesn’t fit SDL’s
needs, or the needs of video games in a general sense.

We’ll be publishing our proposed spec shortly, and seeing if the
community likes the idea, and we’ll go forward from there.

That being said, there are probably still bugs in SDL2’s legacy
approach…please try the latest from Mercurial and report bugs!

–ryan.

4

2012/10/5 Ryan C. Gordon

Anything in particular I should be doing in my code, or is it that KDE

is not really compatible with this way of switching modes?

A lot of this code has changed in SDL2 recently, so this is likely our
bug. If this currently works in SDL 1.2 and is busted in SDL2, we want (and
need!) to hear about it right away. We have some important SDL2-based stuff
shipping soon and would like to catch these things now if we can.

Sam and I have been beating the crap out of the X11 fullscreen code over
the last two weeks or so. The current “best” approach we have is what we’re
referring to as the “legacy” approach–that is, what SDL 1.2 did, which has
now been ported to SDL2.

The legacy approach looks something like this:

  • SDL changes the screen resolution with XVidMode.
  • SDL makes a big black window the size of this resolution and moves the
    mouse into it so it’s covering the visible portion of the virtual desktop,
    and then reparents its actual window on top of this.
  • SDL locks the vidmode so you can’t press ctrl-alt-minus to see the rest
    of your desktop.
  • SDL grabs the mouse and keyboard, so you can’t alt-tab out of this
    window.
  • Basically, we try to prevent you looking behind the curtain to see that
    we’re faking all this stuff in the top-left corner of your actual desktop.
  • If the app crashes, SDL (maybe) cleans everything up, but you might be
    left with a frozen mouse cursor or a crappy resolution.

This is the system we’ve used since the 90’s, when Loki needed a way to do
"fullscreen" games. It works well enough, assuming you have an
uncontroversial window manager, X server, and a measure of luck…but we’ve
all been burnt by it at some time or another, whether we’ve wanted to
switch to our email client for a second and couldn’t, wanted to use the
volume keys on our keyboards, had XRandR smoosh all our windows down,
landed on the wrong Xinerama monitor, or had a crash that just left a big
mess on our screens.

This method will be remaining in SDL2, because in terms of catching every
configuration, it generally works on all sorts of X servers and Unices, but
it’s really a technically offensive approach.

If we could change anything, there’s really only one way to do this for
X11 that makes sense: the window manager needs to be responsible for
fullscreen switches. Sam and I are drafting a proposal for a new window
manager protocol that allows a window to request a fullscreen mode from the
WM, which will be able to handle multiple apps competing for the screen,
allow access to your desktop and volume keys safely, and clean up in case
of app crashes.

As a side benefit, apps won’t have to screw around with X11 extensions
like XVidMode and XRandR…that will move into a central place in the
window manager. The app will just have to say to the WM “make me
fullscreen” in the same way that it currently says things like “maximize
me” or “iconify me.”

As a side note, there’s already something like this in the WM specs
("_NET_WM_STATE_FULLSCREEN"), and that’s great for telling OpenOffice
Impress to use the whole projector for your presentation or Firefox to take
up the whole desktop when you press F11, but it doesn’t fit SDL’s needs, or
the needs of video games in a general sense.

We’ll be publishing our proposed spec shortly, and seeing if the community
likes the idea, and we’ll go forward from there.

That being said, there are probably still bugs in SDL2’s legacy
approach…please try the latest from Mercurial and report bugs!

–ryan.

Hey Ryan, thanks, I’ve been doing some of that work myself (see bug 1571)
and checking in with Sam daily about the impact these changes have in the
system I use to develop. Basically, everything was working like a charm
until he disabled Xrandr by default. I have a Kubuntu system, and I guess
with the current KDE 4.9.2 you do need to use Xrandr, I believe you guys
are experiencing the exact oposite with Unity 3D. Perhaps we can detect
which window manager is active and have a switch that we populate gradually
from people’s experiences? (i.e. if KDE is active, use Xrandr, if Unity is
active, use the legacy method, etc). That may be a good compromise until
the spec you are drafting is eventually implemented.–
Gabriel.

5

Any chance you can debug this? In theory the window manager shouldn’t do
anything to the window because it sets the override redirect hint. Can you
turn on X11 event debugging in SDL_x11events.c and the mode debugging in
SDL_x11modes.c and see what’s going on?On Fri, Oct 5, 2012 at 7:31 AM, Gabriel Jacobo wrote:

2012/10/4 Sam Lantinga <@slouken>

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.

Because it’s so broken, I’ve disabled XRandR by default in SDL 2.0, so
that people have a good experience with it. You can still enable it via
environment variable or application hint (SDL_HINT_VIDEO_X11_XRANDR)

Ryan is working on a window manager spec proposal that will solve things
for all games that want to change resolution.

This last update broke everything on my end, I’m using KDE, Ubuntu
(Kubuntu), latest nVidia binaries.

Starting my test program on monitor 0 on a non desktop resolution, the app
starts on the other monitor, monitor 0 blacks out, the app loses keyboard
focus, I can’t alt-tab nor alt+f4, I need to restart the X server.
Starting it on monitor 1 on a non desktop resolution yields the app at
desktop resolution on monitor 1 (what I would call an almost flawless win
:slight_smile: )
Starting it on monitor 0 on desktop resolution yields a minimized window
that does not appear in the taskbar ??

Anything in particular I should be doing in my code, or is it that KDE is
not really compatible with this way of switching modes?

–
Gabriel.

6

I attached a few tests here: http://bugzilla.libsdl.org/show_bug.cgi?id=1617

Gabriel.

2012/10/6 Sam Lantinga > Any chance you can debug this? In theory the window manager shouldn’t do

anything to the window because it sets the override redirect hint. Can you
turn on X11 event debugging in SDL_x11events.c and the mode debugging in
SDL_x11modes.c and see what’s going on?

On Fri, Oct 5, 2012 at 7:31 AM, Gabriel Jacobo <@Gabriel_Jacobo> wrote:

2012/10/4 Sam Lantinga

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.

Because it’s so broken, I’ve disabled XRandR by default in SDL 2.0, so
that people have a good experience with it. You can still enable it via
environment variable or application hint (SDL_HINT_VIDEO_X11_XRANDR)

Ryan is working on a window manager spec proposal that will solve things
for all games that want to change resolution.

This last update broke everything on my end, I’m using KDE, Ubuntu
(Kubuntu), latest nVidia binaries.

Starting my test program on monitor 0 on a non desktop resolution, the
app starts on the other monitor, monitor 0 blacks out, the app loses
keyboard focus, I can’t alt-tab nor alt+f4, I need to restart the X server.
Starting it on monitor 1 on a non desktop resolution yields the app at
desktop resolution on monitor 1 (what I would call an almost flawless win
:slight_smile: )
Starting it on monitor 0 on desktop resolution yields a minimized window
that does not appear in the taskbar ??

Anything in particular I should be doing in my code, or is it that KDE is
not really compatible with this way of switching modes?

–
Gabriel.

–
Gabriel.

7

Hey Ryan, thanks, I’ve been doing some of that work myself (see bug
1571) and checking in with Sam daily about the impact these changes
have in the system I use to develop. Basically, everything was working
like a charm until he disabled Xrandr by default. I have a Kubuntu
system, and I guess with the current KDE 4.9.2 you do need to use
Xrandr, I believe you guys are experiencing the exact oposite with
Unity 3D. Perhaps we can detect which window manager is active and
have a switch that we populate gradually from people’s experiences?
(i.e. if KDE is active, use Xrandr, if Unity is active, use the legacy
method, etc). That may be a good compromise until the spec you are
drafting is eventually implemented.

I wonder why Unity (game engine) hasn’t gone after Canonical for sniping
their trademark. It is always rather confusing knowing WHICH unity
someone is talking about… Especially in the context of games.
Personally I prefer calling the Ubuntu mess what it is… It’s Compiz…
and Compiz is just a pain in the posterior when dealing with full-screen
mode… (see my patch on bug 1153, and the Torchlight linux port in the
last Humble Bundle)On 10/05/2012 05:43 PM, Gabriel Jacobo wrote:

–
Edward Rudd
OutOfOrder.cc
317-674-3296

8

(finally joined the mailing list)

Probably because Unity (the shell) is not a game engine so maybe
trademark defense doesn’t apply. Besides now we can say we can run
Unity on Unity :stuck_out_tongue:

Anyway, the problem here isn’t Compiz, it’s X. To put it simply, X was
never designed for any sort of fullscreen at all, and all the
fullscreen methods currently available are hacks on top of X, which of
course each has its own set of problems because the window manager has
no idea about it. XRandR is, curiously, the safest one here.

Is Wayland support planned for SDL2 eventually, considering distros
may eventually shift to that? Wayland seems to have proper fullscreen
support, so that’s something important to take into account:
http://www.phoronix.com/scan.php?page=news_item&px=MTAzNTU

Also wow, the fullscreen shenanigans sure broke up miserably, looking
at how many bugs reports it spread…

2012/10/6 Edward Rudd :>

On 10/05/2012 05:43 PM, Gabriel Jacobo wrote:

Hey Ryan, thanks, I’ve been doing some of that work myself (see bug 1571)
and checking in with Sam daily about the impact these changes have in the
system I use to develop. Basically, everything was working like a charm
until he disabled Xrandr by default. I have a Kubuntu system, and I guess
with the current KDE 4.9.2 you do need to use Xrandr, I believe you guys are
experiencing the exact oposite with Unity 3D. Perhaps we can detect which
window manager is active and have a switch that we populate gradually from
people’s experiences? (i.e. if KDE is active, use Xrandr, if Unity is
active, use the legacy method, etc). That may be a good compromise until the
spec you are drafting is eventually implemented.

I wonder why Unity (game engine) hasn’t gone after Canonical for sniping
their trademark. It is always rather confusing knowing WHICH unity someone
is talking about… Especially in the context of games. Personally I
prefer calling the Ubuntu mess what it is… It’s Compiz… and Compiz is just
a pain in the posterior when dealing with full-screen mode… (see my patch
on bug 1153, and the Torchlight linux port in the last Humble Bundle)

–
Edward Rudd
OutOfOrder.cc
317-674-3296

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

9

Hello !

I wonder why Unity (game engine) hasn’t gone after Canonical for sniping
their trademark.

I do not think that the canonical people are a bunch of …holes and they
know that it would mean a big shitstorm when they attack something that
existed long before their Unity.

CU

10

Anyway, the problem here isn’t Compiz, it’s X.

Specifically, the problem is that there are a handful of standards, most
of which are fine, and none of which completely fit our needs. As a
secondary problem, the window manager needs to be involved in this to
make it work well, and it isn’t involved much (or at all) in any of the
current approaches.

There isn’t anything about X that can’t be made to work in this
situation, it’s just not there right now…and it’s been like this so
long that it’s easy to assume that it can’t get it right.

Is Wayland support planned for SDL2 eventually, considering distros
may eventually shift to that?

Wayland has only recently gotten to the point where it’s reasonable to
be thinking about it. We’ll definitely support it in SDL2, eventually.

–ryan.