Using SDL_GetDisplayMode() on the display at (0,0) on Linux (X11) with
Xinerama enabled returns an extra mode covering the entire desktop. (For
instance, the mode 2880x900 would be returned for a system with two
1440x900 monitors arranged horizontally). The code causing this is here:
http://hg.libsdl.org/SDL/file/tip/src/video/x11/SDL_x11modes.c#l692
This is a bit of a pain, as the X11 backend (at least when XRandR is
enabled), does not support creating a fullscreen window of this size,
leaving users with a non-functional mode in the list. I concede that it
may be useful with the legacy fullscreen code, but that is broken anyhow.
Does anyone use this “feature” and should it be removed?
I’ve got a bug report (+ patch) at
http://bugzilla.libsdl.org/show_bug.cgi?id=1927 which I think has the
best of both worlds: the mode appears only when XVidMode is in use, and
the Xinerama backend otherwise will include the current modes for all
monitors.
Thoughts?
– David
2013/6/25 David Gow
Using SDL_GetDisplayMode() on the display at (0,0) on Linux (X11) with
Xinerama enabled returns an extra mode covering the entire desktop. (For
instance, the mode 2880x900 would be returned for a system with two
1440x900 monitors arranged horizontally). The code causing this is here:
http://hg.libsdl.org/SDL/file/**tip/src/video/x11/SDL_**x11modes.c#l692http://hg.libsdl.org/SDL/file/tip/src/video/x11/SDL_x11modes.c#l692
This is a bit of a pain, as the X11 backend (at least when XRandR is
enabled), does not support creating a fullscreen window of this size,
leaving users with a non-functional mode in the list. I concede that it may
be useful with the legacy fullscreen code, but that is broken anyhow.
Does anyone use this “feature” and should it be removed?
I’ve got a bug report (+ patch) at http://bugzilla.libsdl.org/**
show_bug.cgi?id=1927 http://bugzilla.libsdl.org/show_bug.cgi?id=1927which I think has the best of both worlds: the mode appears only when
XVidMode is in use, and the Xinerama backend otherwise will include the
current modes for all monitors.
Thoughts?
– David
I had made a patch ( http://bugzilla.libsdl.org/show_bug.cgi?id=1527 ) that
enabled that mode properly, the problem is…I never got it to work, not
sure why or if it’s supposed to work at all or if it doesn’t due to driver
issues. I do think having a mode that spans both monitors (if it were to
work), is useful.–
Gabriel.
Yeah: that’s the problem even with this combined mode. It’s because the
NET_WM_STATE_FULLSCREEN hint doesn’t support having fullscreen windows
span monitors by default, and will resize them to fit a single monitor.
There is an extension to this: NET_WM_FULLSCREEN_MONITORS, which takes
(IIRC) the monitor IDs to span the window over, but I’m not sure if it’s
well supported by WMs.
I agree that it’d be nice to have a mode that spans both monitors, but
it’d definitely need to be easily identified as such so that
applications can choose to ignore it. Having the mode on a separate
"metamodes" monitor is certainly an improvement, particularly if there
were a simple way to identify this monitor so that it could be ignored
or treated specially by an application.
Do you think it’d be okay to remove the combined mode for now, given it
doesn’t work, and add it back if we can implement
NET_WM_FULLSCREEN_MONITORS and friends?
Cheers,
– DavidOn 25/06/13 22:11, Gabriel Jacobo wrote:
2013/6/25 David Gow <@David_Gow
mailto:David_Gow>
Using SDL_GetDisplayMode() on the display at (0,0) on Linux (X11)
with Xinerama enabled returns an extra mode covering the entire
desktop. (For instance, the mode 2880x900 would be returned for a
system with two 1440x900 monitors arranged horizontally). The code
causing this is here:
http://hg.libsdl.org/SDL/file/tip/src/video/x11/SDL_x11modes.c#l692
This is a bit of a pain, as the X11 backend (at least when XRandR
is enabled), does not support creating a fullscreen window of this
size, leaving users with a non-functional mode in the list. I
concede that it may be useful with the legacy fullscreen code, but
that is broken anyhow.
Does anyone use this "feature" and should it be removed?
I've got a bug report (+ patch) at
http://bugzilla.libsdl.org/show_bug.cgi?id=1927 which I think has
the best of both worlds: the mode appears only when XVidMode is in
use, and the Xinerama backend otherwise will include the current
modes for all monitors.
Thoughts?
-- David
I had made a patch (
http://bugzilla.libsdl.org/show_bug.cgi?id=1527 ) that enabled that
mode properly, the problem is…I never got it to work, not sure why
or if it’s supposed to work at all or if it doesn’t due to driver
issues. I do think having a mode that spans both monitors (if it were
to work), is useful.
–
Gabriel.
2013/6/25 David Gow > On 25/06/13 22:11, Gabriel Jacobo wrote:
2013/6/25 David Gow
Using SDL_GetDisplayMode() on the display at (0,0) on Linux (X11) with
Xinerama enabled returns an extra mode covering the entire desktop. (For
instance, the mode 2880x900 would be returned for a system with two
1440x900 monitors arranged horizontally). The code causing this is here:
http://hg.libsdl.org/SDL/file/tip/src/video/x11/SDL_x11modes.c#l692
This is a bit of a pain, as the X11 backend (at least when XRandR is
enabled), does not support creating a fullscreen window of this size,
leaving users with a non-functional mode in the list. I concede that it may
be useful with the legacy fullscreen code, but that is broken anyhow.
Does anyone use this “feature” and should it be removed?
I’ve got a bug report (+ patch) at
http://bugzilla.libsdl.org/show_bug.cgi?id=1927 which I think has the
best of both worlds: the mode appears only when XVidMode is in use, and the
Xinerama backend otherwise will include the current modes for all monitors.
Thoughts?
– David
I had made a patch ( http://bugzilla.libsdl.org/show_bug.cgi?id=1527 ) that
enabled that mode properly, the problem is…I never got it to work, not
sure why or if it’s supposed to work at all or if it doesn’t due to driver
issues. I do think having a mode that spans both monitors (if it were to
work), is useful.
–
Gabriel.
Yeah: that’s the problem even with this combined mode. It’s because the
NET_WM_STATE_FULLSCREEN hint doesn’t support having fullscreen windows span
monitors by default, and will resize them to fit a single monitor. There is
an extension to this: NET_WM_FULLSCREEN_MONITORS, which takes (IIRC) the
monitor IDs to span the window over, but I’m not sure if it’s well
supported by WMs.
I agree that it’d be nice to have a mode that spans both monitors, but
it’d definitely need to be easily identified as such so that applications
can choose to ignore it. Having the mode on a separate “metamodes” monitor
is certainly an improvement, particularly if there were a simple way to
identify this monitor so that it could be ignored or treated specially by
an application.
Do you think it’d be okay to remove the combined mode for now, given it
doesn’t work, and add it back if we can implement
NET_WM_FULLSCREEN_MONITORS and friends?
Cheers,
– David
Yes, it’s probably best to remove it, specially if no one uses it
specifically, because we are providing a mode as an option which really
isn’t so.
–
Gabriel.
I agree that it’d be nice to have a mode that spans both monitors, but
it’d definitely need to be easily identified as such so that applications
can choose to ignore it. Having the mode on a separate “metamodes” monitor
is certainly an improvement, particularly if there were a simple way to
identify this monitor so that it could be ignored or treated specially by
an application.
Do you think it’d be okay to remove the combined mode for now, given it
doesn’t work, and add it back if we can implement
NET_WM_FULLSCREEN_MONITORS and friends?
I’m quite sure one of the latest GTK 3.x stable iterations added the
support to that extension to handle a single fullscreen window that spawn
over multiple monitors, so it should be fairly supported among window
managers…–
Bye,
Gabry