Issue with fullscreen mode

SDL Development
#1

Hello,

I’m trying to get in touch with ffplay from ffmpeg, which uses SDL. There I
realized, that the video has a wrong offset of about 100 pixels (in fullscreen
mode only) and as I’m pretty new to both (ffmpeg and sdl) I had to find the
cause.

I added some debugging to ffplay, which showed me the calculations of ffplay
look quite ok. So I tried to find known issues related to sdl and fullscreen
mode.

Digging the ml I read, that testsprite has to be run before asking for help.
So I run testsprite, which showed the same behavior.

I played a bit with the parameters and found out, that the fullscreen mode
does not change/affect the active area (where the smilies jump around).
So I had to use -width and -height to get an active fullscreen (using -
fullscreen only does not cover the whole desktop - only about half of it).

Using this commandline:$ testsprite -width 3600 -height 1870 -hw
results in a window maximized to the visible desktop and the smilies move
towards the windows titlebar.

When I add -fullscreen the titlebar disappears, but the smilies are not able
to move above the invisible border (at about y=100)

How can I fake a negative offset or move the viewport, so that the pictures
will be displayed at the expected locations?

I already tried to play with y-values from rect structure at call of
SDL_DisplayYUVOverlay() - but it looks like the position parameters are
ignored in fullscreen mode.

Any hint is appreciated.

Ah, yes - my system is debian stable with sdl-libs from debian repo.

BR
Gero

#2

Hello,

I fetched the current sdl2 from repository and run the test against it.
The behavior of sdl2 is even worse than the one from sdl1.

calling testsprite2 with --info results in this output:
Built-in video drivers: x11, dummy
Video driver: x11
Number of displays: 2
Display 0:
Current mode: 2400x1920 at 0Hz, 32 bits-per-pixel (SDL_PIXELFORMAT_RGB888)
Red Mask = 0x00ff0000
Green Mask = 0x0000ff00
Blue Mask = 0x000000ff
Xlib: extension “RANDR” missing on display “:0.0”.
Fullscreen video modes:
Mode 0: 3600x1920 at 0Hz, 32 bits-per-pixel (SDL_PIXELFORMAT_RGB888)
Red Mask = 0x00ff0000
Green Mask = 0x0000ff00
Blue Mask = 0x000000ff
Mode 1: 2400x1920 at 0Hz, 32 bits-per-pixel (SDL_PIXELFORMAT_RGB888)
Red Mask = 0x00ff0000
Green Mask = 0x0000ff00
Blue Mask = 0x000000ff
Mode 2: 1920x2400 at 59Hz, 32 bits-per-pixel (SDL_PIXELFORMAT_RGB888)
Red Mask = 0x00ff0000
Green Mask = 0x0000ff00
Blue Mask = 0x000000ff
Display 1:
Current mode: 1200x1920 at 0Hz, 32 bits-per-pixel (SDL_PIXELFORMAT_RGB888)
Red Mask = 0x00ff0000
Green Mask = 0x0000ff00
Blue Mask = 0x000000ff
Xlib: extension “RANDR” missing on display “:0.0”.
Fullscreen video modes:
Mode 0: 3600x1920 at 0Hz, 32 bits-per-pixel (SDL_PIXELFORMAT_RGB888)
Red Mask = 0x00ff0000
Green Mask = 0x0000ff00
Blue Mask = 0x000000ff
Mode 1: 1200x1920 at 0Hz, 32 bits-per-pixel (SDL_PIXELFORMAT_RGB888)
Red Mask = 0x00ff0000
Green Mask = 0x0000ff00
Blue Mask = 0x000000ff
Built-in render drivers:
Renderer opengl:
Flags: 0x0000000E (Accelerated | PresentVSync | 0x00000008)
Texture formats (1): ARGB8888
Renderer software:
Flags: 0x00000009 (0x00000001 | 0x00000008)
Texture formats (8): RGB555, RGB565, RGB888, BGR888, ARGB8888, RGBA8888,
ABGR8888, BGRA8888
Current renderer:
Renderer opengl:
Flags: 0x0000000A (Accelerated | 0x00000008)
Texture formats (3): ARGB8888, YV12, IYUV
Max Texture Size: 16384x16384

So I wonder, why sdl does not use the first fullscreen mode, which is exactly
what I want.
As I found no call to set the desktop mode, I tried to change the window mode,
but that did not change anything.

added some output around the setting of the window mode:
SDL: before patch - window-mode: 1x4199684 at 0Hz, 0 bits-per-pixel
(SDL_PIXELFORMAT_UNKNOWN)
SDL: after patch - window-mode: 3600x1920 at 0Hz, 32 bits-per-pixel
(SDL_PIXELFORMAT_RGB888)

Apparently the window-mode is not initialized (used?).

Any idea, how I could get a maximized window (no matter whether it has
decoration or not)?
With sdl1 the creation of a window with dimension 3600x1900 results in a
window of desired size, but wrong location - it only needs to get positioned
to 0/0

With sdl2 the creation of a window of size 3600x1900 results in a window of
size 2400x1900, no difference using -fullscreen or not.

I think, it may be related to the fact, that the desktop is a combination of
twinview and xinerama and the window-manager is not able to maximize a window
to entire desktop size too. Maximizing a window with windowmanager results in
2400x1920 or 1200x1920 - depending of the window-offset at maximization
request.
Sizing the window manually works fine - but the active area does not get
resized at manually resize requests.

Any hint is appreciated.

BR

Gero

#3

2012/6/24 Geronimo Ma. Hernandez

Apparently the window-mode is not initialized (used?).

Any idea, how I could get a maximized window (no matter whether it has
decoration or not)?
With sdl1 the creation of a window with dimension 3600x1900 results in a
window of desired size, but wrong location - it only needs to get
positioned
to 0/0

With sdl2 the creation of a window of size 3600x1900 results in a window of
size 2400x1900, no difference using -fullscreen or not.

I think, it may be related to the fact, that the desktop is a combination
of
twinview and xinerama and the window-manager is not able to maximize a
window
to entire desktop size too. Maximizing a window with windowmanager results
in
2400x1920 or 1200x1920 - depending of the window-offset at maximization
request.
Sizing the window manually works fine - but the active area does not get
resized at manually resize requests.

Any hint is appreciated.

I made a few changes last week to better support Xinerama/Twinview in SDL2,
the thing is you need the nVidia binary drivers v302.17 or newer for
Twinview to behave properly as a Xinerama device. Assuming you have that,
SDL will create two SDL_VideoDisplay devices for you, one for each screen,
and fill the video modes available for each individual monitor. It’ll also
add an additional “metamode”, only on the device that’s got a 0,0 offset
which you can use to get a fullscreen display that spans both monitors. If
that doesn’t work let me know, there may be a bug in there still.–
Gabriel.

#4

2012/6/24 Geronimo Ma. Hernandez

Hello,

I fetched the current sdl2 from repository and run the test against it.
The behavior of sdl2 is even worse than the one from sdl1.

I filled a patch here: http://bugzilla.libsdl.org/show_bug.cgi?id=1527

Spoiler alert: It doesn’t work in my system :slight_smile: But I think it’s due to the
window manager meddling…you are welcome to try it and see if your window
manager lets you have a fullscreen window across two monitors.–
Gabriel.

#5

Hi Gabriel,

thanks a lot for your attention!On Sunday 24 June 2012 - 16:13:37, Gabriel Jacobo wrote:

I made a few changes last week to better support Xinerama/Twinview in SDL2,
the thing is you need the nVidia binary drivers v302.17 or newer for
Twinview to behave properly as a Xinerama device.

I tried to switch to 302.17 - but it looks like the driver does not support
the options from before. Currently I’m running 295.33 and the attached
xorg.conf works fine.

Using 302.17 no monitor respects the option “Rotate” “Left”. Additionally the
"Virtual" option is not supported any more. For so the resulting desktop is
unusable for me and it makes no sense to start any sdl tests.

Can you shine me a light - is there another option to get the content rotated
for each monitor, or do I have to wait until next debian release (with a
possibly new x-server)? Changing the x-server is not an option for me. I’m
tied to the reliability of debian stable

Development with sdl is part of my spare-time, so I won’t risk to loose system
reliability for possibly working sdl.

Any hint, what can I do with my system?

… or would it be possible to add support to set the viewport-offset in
fullscreen mode for sdl1.2 - as - from my point of view - that behavior is the
best bet to my expectations.

The layer libraries already have viewport-support for sdl1.2, may be its
possible to add offset-support to yuv-overlay too?

BR

Gero
-------------- next part --------------

nvidia-settings: X configuration working with 295.33 (not working with 302.17)

Section "ServerLayout"
Identifier "Three screens"
Screen 0 “Screen0” 0 0
Screen 1 “Screen1” RightOf "Screen0"
Option “Xinerama” "On"
EndSection

Section "InputDevice"
Identifier "Mouse0"
Driver "mouse"
Option “Protocol” "auto"
Option “Device” "/dev/psaux"
Option “Emulate3Buttons” "no"
Option “ZAxisMapping” "4 5"
EndSection

Section "InputDevice"
Identifier "Keyboard0"
Driver "kbd"
EndSection

Section "Module"
Load "extmod"
EndSection

Section "ServerFlags"
Option “Xinerama” "1"
EndSection

Section "Monitor"
Identifier "Monitor-left"
ModelName "Samsung SyncMaster"
HorizSync 30.0 - 81.0
VertRefresh 56.0 - 75.0
Option “Rotate” "left"
Option "DPMS"
EndSection

Section "Monitor"
Identifier "Monitor-center"
ModelName "Samsung SyncMaster"
HorizSync 30.0 - 81.0
VertRefresh 56.0 - 75.0
Option “Rotate” "left"
Option "DPMS"
EndSection

Section "Monitor"
Identifier "Monitor-right"
ModelName "Samsung SyncMaster"
HorizSync 30.0 - 81.0
VertRefresh 56.0 - 75.0
Option “Rotate” "left"
Option "DPMS"
EndSection

Section "Device"
Identifier "Device0"
Driver "nvidia"
VendorName "NVIDIA Corporation"
BoardName "Quadro 600"
BusID "PCI:1:0:0"
EndSection

Section "Device"
Identifier "Device1"
Driver "nvidia"
VendorName "NVIDIA Corporation"
BoardName "Quadro 600"
BusID "PCI:2:0:0"
EndSection

Section "Screen"
Identifier "Screen0"
Device "Device1"
Monitor "Monitor-center"
Monitor "Monitor-left"
DefaultDepth 24
Virtual 2400 1920
Option “TwinView” "1"
Option “TwinViewOrientation” "Above"
Option “TwinViewXineramaInfoOrder” "DFP-0"
Option “metamodes” "DFP-0: nvidia-auto-select +0+1200, DFP-1: nvidia-auto-select +0+0"
SubSection "Display"
Depth 24
EndSubSection
EndSection

Section "Screen"
Identifier "Screen1"
Device "Device0"
Monitor "Monitor-right"
DefaultDepth 24
Option “TwinView” "0"
Option “metamodes” "nvidia-auto-select +0+0"
SubSection "Display"
Depth 24
EndSubSection
EndSection

#6

Can you shine me a light - is there another option to get the content
rotated
for each monitor, or do I have to wait until next debian release (with a
possibly new x-server)? Changing the x-server is not an option for me. I’m
tied to the reliability of debian stable

I don’t have rotation enable in my monitors and I use Ubuntu 12.04, not
Debian, so I don’t know.

Development with sdl is part of my spare-time, so I won’t risk to loose
system
reliability for possibly working sdl.

Any hint, what can I do with my system?

… or would it be possible to add support to set the viewport-offset in
fullscreen mode for sdl1.2 - as - from my point of view - that behavior is
the
best bet to my expectations.

The layer libraries already have viewport-support for sdl1.2, may be its
possible to add offset-support to yuv-overlay too?

About SDL1.2, I can’t say much either. I can tell you, from an end user
point of view, that for games that use SDL 1.2, you can use the environment
variable SDL_VIDEO_FULLSCREEN_HEAD=0|1 to select which monitor is used to
go full screen and this works with the nVidia binary drivers with Twinview
enabled (using the older or the newer drivers).–
Gabriel.