Linux Fullscreen fails with "Could not find a suitable graphics mode"

[Gankra]

This shows up when using piston_window's default window provider, pistoncore-glutin_window, using glutin 0.3.5 (latest release as of now).

A simple reproduction is just adding .fullscreen(true) to line 13 of this example: https://github.com/PistonDevelopers/piston-examples/blob/master/src/paint.rs

(only the window initialization code matters, I link this example only to simplify getting the dependencies and everything set up)

[Gankra]

Oh sorry: tested on x64 Ubuntu 14.10. Not sure what details exactly are relevant.

[tomaka]

The error is OsError("Could not find a suitable graphics mode")?

[Gankra]

Yep!

Happy to do any debugging that might help.

[tomaka]

So the exact problem is just the crappy way glutin handle this.

When you specify dimensions (300, 300), glutin tries to find a fullscreen mode with these dimensions. Since it doesn't find any, it returns an error. If you pass something like (1280, 1024) (or something that is supported), it should work.

It would be better to make the user choose from all possible fullscreen modes.

[Gankra]

Aha -- so if there was a way to tell piston_window to not try to set dimensions, this would work?

Alternatively, what's the correct way to query glutin for available full-screen modes?

Alternatively, alternatively, it sounds like fixing this shouldn't be too bad (just have glutin ignore the input dimensions?)

[elinorbgr]

The default (and recommended) way to handle this on wayland (and this is what is currently done in the wayland backend), is to create a buffer with the requested size, and let the wayland server and video driver scale it to the appropriate resolution if needed.

Isn't there some similar behaviour possible on X11 ?

Still it could indeed be good to provide an interface to query the supported output dimensions of a given monitor.

[Aatch]

I tried using with_fullscreen() and didn't explicitly set any dimensions because the documentation said it would just use the dimensions of the monitor you give it. I got the same error.

[Aatch]

Ok, I found the main issue. There's a "workaround" for this issue: AltF02/x11-rs#19. as pointed out in that issue, the hskew is supposed to be there, it's just not in any online documentation, for some reason (yay XServer...). The actual vdisplay values are the correct ones, for my machine anyway.

Another issue is that glutin doesn't seem to be XRandR aware, as it is trying to find a mode that is 5760 wide on my machine, which is the total width of my triple-screen setup.

[ryndinol]

Changing vsyncstart back to vdisplay (b4346f3) also fixed this for me.

I'm using Arch x64 with libx11 1.6.3-1

[anka-213]

For some reason glutin::get_available_monitors() only returns a single monitor with the combined size of both monitors. If I explicitly set the width to half of the returned value from mon.get_dimensions(), the code runs, but instead of displaying a full screen app, the contents of my first screen is duplicated to the second. :-S

(I needed to change my layout with XRandR to get back my two displays again.)

[anka-213]

But that is not entirely true. Because the mouse is still on just one monitor and if I move the mouse over to that screen, the focus is on the (now invisible) stuff that was on the second screen.

[francesca64]

This is no longer relevant after rust-windowing/winit#270 and various other improvements.