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

SFML 2.3 fullscreen bug Linux #921

Closed
matus123 opened this Issue Jul 7, 2015 · 19 comments

Comments

Projects
None yet
@matus123

matus123 commented Jul 7, 2015

hello, i have encountered this bug with fullscreen window in SFML 2.3, when i create window with default desktop size it sometimes creates window with correct size and viewSize , but more often it creates fullscreen window with broken size

example:
normale window size 1366 - 768
broken window size 1366 - 714 with same viewSize
1920 - 1080
1920 - 1026

sample code : https://gist.github.com/matus123/967f48ea849fb670cf13

it behaves the same way even with correct VideoMode or with wrong as you can see in example

i have tried this code even with SFML 2.2 and it behaves the same way.

i am using Linux mint KDE

does anyone encountered similar problem with fullscreen window?, can anyone help me fix it?

i will try this code on other linux distros to see if it's global or it is only misbehaving on my machine.

@dabbertorres

This comment has been minimized.

Show comment
Hide comment
@dabbertorres

dabbertorres Jul 7, 2015

Contributor

Based on the size change only in the vertical component, I'm going to
assume it's taking your taskbar size into account sometimes, and sometimes
not.

Can you determine if you have anything running in the background that
causes the difference in behavior?

I can try this later today, but I haven't noticed anything like this.

Though, this will probably be closed and moved to the forums.
On Jul 7, 2015 11:19 AM, "matus123" notifications@github.com wrote:

hello, i have encountered this bug with fullscreen window in SFML 2.3,
when i create window with default desktop size it sometimes creates window
with correct size and viewSize , but more often it creates fullscreen
window with broken size

example:
normale window size 1366 - 768
broken window size 1366 - 714 with same viewSize
1920 - 1080
1920 - 1026

sample code : https://gist.github.com/matus123/967f48ea849fb670cf13

it behaves the same way even with correct VideoMode or with wrong as you
can see in example

i have tried this code even with SFML 2.2 and it behaves the same way.

i am using Linux mint KDE

does anyone encountered similar problem with fullscreen window?, can
anyone help me fix it?

i will try this code on other linux distros to see if it's global or it is
only misbehaving on my machine.


Reply to this email directly or view it on GitHub
#921.

Contributor

dabbertorres commented Jul 7, 2015

Based on the size change only in the vertical component, I'm going to
assume it's taking your taskbar size into account sometimes, and sometimes
not.

Can you determine if you have anything running in the background that
causes the difference in behavior?

I can try this later today, but I haven't noticed anything like this.

Though, this will probably be closed and moved to the forums.
On Jul 7, 2015 11:19 AM, "matus123" notifications@github.com wrote:

hello, i have encountered this bug with fullscreen window in SFML 2.3,
when i create window with default desktop size it sometimes creates window
with correct size and viewSize , but more often it creates fullscreen
window with broken size

example:
normale window size 1366 - 768
broken window size 1366 - 714 with same viewSize
1920 - 1080
1920 - 1026

sample code : https://gist.github.com/matus123/967f48ea849fb670cf13

it behaves the same way even with correct VideoMode or with wrong as you
can see in example

i have tried this code even with SFML 2.2 and it behaves the same way.

i am using Linux mint KDE

does anyone encountered similar problem with fullscreen window?, can
anyone help me fix it?

i will try this code on other linux distros to see if it's global or it is
only misbehaving on my machine.


Reply to this email directly or view it on GitHub
#921.

@matus123

This comment has been minimized.

Show comment
Hide comment
@matus123

matus123 Jul 7, 2015

I tried changing taskbar visibility to auto hide and now it shows 1366 - 746.
So it seems that you had been right about taskbar. But anyway, i don't get why it is sometimes taking taskbar into the account and sometimes not.

I tried to run it from terminal right after boot with hidden taskbar.

I will test it on another linux distro with different window manager to see if the problem occurs.

matus123 commented Jul 7, 2015

I tried changing taskbar visibility to auto hide and now it shows 1366 - 746.
So it seems that you had been right about taskbar. But anyway, i don't get why it is sometimes taking taskbar into the account and sometimes not.

I tried to run it from terminal right after boot with hidden taskbar.

I will test it on another linux distro with different window manager to see if the problem occurs.

@zmertens

This comment has been minimized.

Show comment
Hide comment
@zmertens

zmertens Jul 9, 2015

I have no issues going full-screen with Ubuntu 14.04 (Unity desktop).

zmertens commented Jul 9, 2015

I have no issues going full-screen with Ubuntu 14.04 (Unity desktop).

@dabbertorres

This comment has been minimized.

Show comment
Hide comment
@dabbertorres

dabbertorres Jul 9, 2015

Contributor

Okay, hmm. I guess I haven't tried fullscreen in a while.

I'm getting "Failed to set new screen configuration" in stdout, which comes from here.

Seems to be failing to make the window fullscreen, and is making the window a borderless "fullscreen" window.
I feel like I should be getting "Failed to find matching fullscreen size, switching to window mode" as well, given that it's making a normal window, and not a "normal" fullscreen window, but I do not receive that message, which makes sense, looking at the code there.

Looks like there could be more information given about the error - I should have some time this weekend to add some code to get that information, and recompile SFML and see what I get.

Anyway, system:
Arch Linux x86_64
Kernel: 4.0.7-2-ARCH
DE: Cinnamon 2.6.12

Contributor

dabbertorres commented Jul 9, 2015

Okay, hmm. I guess I haven't tried fullscreen in a while.

I'm getting "Failed to set new screen configuration" in stdout, which comes from here.

Seems to be failing to make the window fullscreen, and is making the window a borderless "fullscreen" window.
I feel like I should be getting "Failed to find matching fullscreen size, switching to window mode" as well, given that it's making a normal window, and not a "normal" fullscreen window, but I do not receive that message, which makes sense, looking at the code there.

Looks like there could be more information given about the error - I should have some time this weekend to add some code to get that information, and recompile SFML and see what I get.

Anyway, system:
Arch Linux x86_64
Kernel: 4.0.7-2-ARCH
DE: Cinnamon 2.6.12

@matus123

This comment has been minimized.

Show comment
Hide comment
@matus123

matus123 Jul 9, 2015

This is really interesting, because i tried it on another machine with newly installed Linux Mint 17.2 MATE, i have also built SFML-2.3 on that machine.

I have encountered very similar results as before on my main PC with Linux Mint 17.1 KDE, which are based on Ubuntu 14.04

Screenshot of results : http://postimg.org/image/jx4x21y5p/

matus123 commented Jul 9, 2015

This is really interesting, because i tried it on another machine with newly installed Linux Mint 17.2 MATE, i have also built SFML-2.3 on that machine.

I have encountered very similar results as before on my main PC with Linux Mint 17.1 KDE, which are based on Ubuntu 14.04

Screenshot of results : http://postimg.org/image/jx4x21y5p/

@dabbertorres

This comment has been minimized.

Show comment
Hide comment
@dabbertorres

dabbertorres Jul 9, 2015

Contributor

Funny, you're getting a different error than I am.

You should try something like this, and see what the output is, and compare to what you VideoMode(s) you're trying.

Contributor

dabbertorres commented Jul 9, 2015

Funny, you're getting a different error than I am.

You should try something like this, and see what the output is, and compare to what you VideoMode(s) you're trying.

@matus123

This comment has been minimized.

Show comment
Hide comment
@matus123

matus123 Jul 9, 2015

I tried to print my supported modes. Also i tried to create window with my DefaultDesktopMode() but the result was the same. Sometimes it was correct size and sometimes modified.

I have also tried creating window with unsupported mode, because if i am correct sfml will firstly check if it's valid VideoMode and if not it will replace it with sf::VideoMode::getFullscreenModes()[0].

matus123 commented Jul 9, 2015

I tried to print my supported modes. Also i tried to create window with my DefaultDesktopMode() but the result was the same. Sometimes it was correct size and sometimes modified.

I have also tried creating window with unsupported mode, because if i am correct sfml will firstly check if it's valid VideoMode and if not it will replace it with sf::VideoMode::getFullscreenModes()[0].

@TankOs

This comment has been minimized.

Show comment
Hide comment
@TankOs

TankOs Aug 11, 2015

Member

Do you guys use multiple monitors? Can you paste the output of xrandr -q?

Member

TankOs commented Aug 11, 2015

Do you guys use multiple monitors? Can you paste the output of xrandr -q?

@matus123

This comment has been minimized.

Show comment
Hide comment
@matus123

matus123 Aug 11, 2015

i am using notebook with connected monitor, but i am only using monitor display.
First image is with my main pc/notebook.
hodnoty1

This image was taken on an old machine which was connected to TV via VGA cable.
screenshot-1

matus123 commented Aug 11, 2015

i am using notebook with connected monitor, but i am only using monitor display.
First image is with my main pc/notebook.
hodnoty1

This image was taken on an old machine which was connected to TV via VGA cable.
screenshot-1

@binary1248

This comment has been minimized.

Show comment
Hide comment
@binary1248

binary1248 Aug 20, 2015

Member

Does this still occur with the current master revision of SFML?

Member

binary1248 commented Aug 20, 2015

Does this still occur with the current master revision of SFML?

@bloodsword

This comment has been minimized.

Show comment
Hide comment
@bloodsword

bloodsword Sep 5, 2015

Contributor

Hello,
I got this bug with the current master revision on 3 tested KDE desktop (Debian & Fedora).
I dug into SFML code, it seems that xcb is returning a wrong size with xcb_get_geometry in WindowImplX11::getSize().
I found two solutions to get rid of this bug by modifying WindowImplX11.xpp :

  • force fullscreen at window creation by not testing ewmhSupported.
    OR
  • apply the "OpenBox" workaround for "KWin".

I don't know the possible side effects of the first solution, but the second solution seems to be better because there is already a fix for OpenBox, but according to matus123 it also happens on MATE,
so maybe it would be better to apply the workaround no matter the windows manager since it looks harmless for other managers.

Contributor

bloodsword commented Sep 5, 2015

Hello,
I got this bug with the current master revision on 3 tested KDE desktop (Debian & Fedora).
I dug into SFML code, it seems that xcb is returning a wrong size with xcb_get_geometry in WindowImplX11::getSize().
I found two solutions to get rid of this bug by modifying WindowImplX11.xpp :

  • force fullscreen at window creation by not testing ewmhSupported.
    OR
  • apply the "OpenBox" workaround for "KWin".

I don't know the possible side effects of the first solution, but the second solution seems to be better because there is already a fix for OpenBox, but according to matus123 it also happens on MATE,
so maybe it would be better to apply the workaround no matter the windows manager since it looks harmless for other managers.

@Eremiell

This comment has been minimized.

Show comment
Hide comment
@Eremiell

Eremiell Jan 23, 2016

Tried to mess with this one a bit today as it's still an issue. I'm on MATE btw.

Some screenshots to be referred. The white rectangle is of expected window size.

Some observations:

  • with both 2.3.2 and latest commit all of the screenshots (figures 1-3) happen. It's always the first one most time with some amount of second or third time, depending on video mode.
  • both 2.3.1 and 2.3 do rarely the first screen and go alright fullscreen about 80% of time
  • 2.2 goes completely broken (the rectangle is drawn in the figure 1 position over the current display, mouse pointer can be moved but can't leave the rectangle and the whole X session doesn't react to anything, have to kill the test from second virtual terminal, so no screenshots possible), didn't go any deeper
  • sleeping or recreating the window doesn't help

Output of the first program: (modified the 1366 to 1360 as that's what my screen supports)

window-view-size 1360 768
window-size 1920 768

Output of the second program

Tried to "apply the OpenBox workaround" (not sure if properly), mostly messed with this line, playing with the conditions, it either didn't change anything from "normal" state, or forced right size, but remained windowed.

To add some more confusion, on 2.3.1, the first tool sometimes returns the same as on 2.3.2 and sometimes this:

window-view-size 1920 1080
window-size 1920 1080

which looks like, it's not really going into 1360x768 as expected, but stays 1920x1080, but that actually seems to be the error state, as it's happening very rare compared to the former one and when running my test code, I get working behaviour most of the time and broken rarely.

Btw, here's my test code and the test image is the last one in the imgur album. (The screenshots were made with borderless version, I only added border once I got to 2.3.1 and the borders became relevant.)

So it seems, something got more wrong since 2.3.1, but even there, it's not 100% success. Seems to me only event and input stuff got changed there, but maybe someone can see something I can't.

Eremiell commented Jan 23, 2016

Tried to mess with this one a bit today as it's still an issue. I'm on MATE btw.

Some screenshots to be referred. The white rectangle is of expected window size.

Some observations:

  • with both 2.3.2 and latest commit all of the screenshots (figures 1-3) happen. It's always the first one most time with some amount of second or third time, depending on video mode.
  • both 2.3.1 and 2.3 do rarely the first screen and go alright fullscreen about 80% of time
  • 2.2 goes completely broken (the rectangle is drawn in the figure 1 position over the current display, mouse pointer can be moved but can't leave the rectangle and the whole X session doesn't react to anything, have to kill the test from second virtual terminal, so no screenshots possible), didn't go any deeper
  • sleeping or recreating the window doesn't help

Output of the first program: (modified the 1366 to 1360 as that's what my screen supports)

window-view-size 1360 768
window-size 1920 768

Output of the second program

Tried to "apply the OpenBox workaround" (not sure if properly), mostly messed with this line, playing with the conditions, it either didn't change anything from "normal" state, or forced right size, but remained windowed.

To add some more confusion, on 2.3.1, the first tool sometimes returns the same as on 2.3.2 and sometimes this:

window-view-size 1920 1080
window-size 1920 1080

which looks like, it's not really going into 1360x768 as expected, but stays 1920x1080, but that actually seems to be the error state, as it's happening very rare compared to the former one and when running my test code, I get working behaviour most of the time and broken rarely.

Btw, here's my test code and the test image is the last one in the imgur album. (The screenshots were made with borderless version, I only added border once I got to 2.3.1 and the borders became relevant.)

So it seems, something got more wrong since 2.3.1, but even there, it's not 100% success. Seems to me only event and input stuff got changed there, but maybe someone can see something I can't.

@dubmosphere

This comment has been minimized.

Show comment
Hide comment
@dubmosphere

dubmosphere Feb 17, 2016

Hello,
I have a similar problem on Linux Mint 17 Cinnamon. It only occurs with my tilemap drawables taking sf::Drawable and sf::Transformable as base class. The code works on windows, so this is really confusing. If I go to 800x600 the view gets scaled but not the drawables, they are drawed at the bottom left of the view.

dubmosphere commented Feb 17, 2016

Hello,
I have a similar problem on Linux Mint 17 Cinnamon. It only occurs with my tilemap drawables taking sf::Drawable and sf::Transformable as base class. The code works on windows, so this is really confusing. If I go to 800x600 the view gets scaled but not the drawables, they are drawed at the bottom left of the view.

@achpile

This comment has been minimized.

Show comment
Hide comment
@achpile

achpile Jun 16, 2016

Does this still occur with the current master revision of SFML?

Yes, still occur =(

achpile commented Jun 16, 2016

Does this still occur with the current master revision of SFML?

Yes, still occur =(

@texus

This comment has been minimized.

Show comment
Hide comment
@texus

texus Jun 28, 2016

Contributor

I'm having this issue as well on Arch Linux with Cinnamon and the latest SFML version. Sometimes it works fine and the size is 1366x768 as expected but sometimes it incorrectly prints 1364x716.

In the cases where the size reported by window.getSize() and window.getView().getSize() is incorrect, the contents of the window is shifted, but the mouse coordinates in the sf::Event::MouseMoved event are still as if the window was 1366x768.

Applying the "OpenBox workaround" seems to work for me, changing that line in WindowImplX11.cpp to if (!(style & Style::Resize)) solved the problem here.

Contributor

texus commented Jun 28, 2016

I'm having this issue as well on Arch Linux with Cinnamon and the latest SFML version. Sometimes it works fine and the size is 1366x768 as expected but sometimes it incorrectly prints 1364x716.

In the cases where the size reported by window.getSize() and window.getView().getSize() is incorrect, the contents of the window is shifted, but the mouse coordinates in the sf::Event::MouseMoved event are still as if the window was 1366x768.

Applying the "OpenBox workaround" seems to work for me, changing that line in WindowImplX11.cpp to if (!(style & Style::Resize)) solved the problem here.

@izz-j

This comment has been minimized.

Show comment
Hide comment
@izz-j

izz-j Jul 6, 2016

I can confirm
OS: Arch Linux
DE: KDE Plasma

SFML spits out:
The requested video mode is not available, switching to a valid mode
I'll checkout the code in the fullscreen function

izz-j commented Jul 6, 2016

I can confirm
OS: Arch Linux
DE: KDE Plasma

SFML spits out:
The requested video mode is not available, switching to a valid mode
I'll checkout the code in the fullscreen function

@eXpl0it3r

This comment has been minimized.

Show comment
Hide comment
@eXpl0it3r

eXpl0it3r Sep 13, 2016

Member

Make sure to check out the bugfix/xlib branch (see PR #1138 and builds for the lazy) and see if this solves the issue!

Member

eXpl0it3r commented Sep 13, 2016

Make sure to check out the bugfix/xlib branch (see PR #1138 and builds for the lazy) and see if this solves the issue!

@texus

This comment has been minimized.

Show comment
Hide comment
@texus

texus Sep 13, 2016

Contributor

With the bugfix/xlib branch merged the view size and window size are correct (1366x768) while SFML 2.4.0 reported 1364x714 and 1366x714 so it does seem to fix the issue.

Contributor

texus commented Sep 13, 2016

With the bugfix/xlib branch merged the view size and window size are correct (1366x768) while SFML 2.4.0 reported 1364x714 and 1366x714 so it does seem to fix the issue.

@eXpl0it3r

This comment has been minimized.

Show comment
Hide comment
@eXpl0it3r

eXpl0it3r Sep 29, 2016

Member

Should be fixed through #1138 in 1dc3db0.

Member

eXpl0it3r commented Sep 29, 2016

Should be fixed through #1138 in 1dc3db0.

@eXpl0it3r eXpl0it3r closed this Sep 29, 2016

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment