The "trunk", that is "master", can change from day to day.  Please be more specific and provide a commit id/hash.

Do you observe the same issue with weston 1.4?

Created attachment 98915 [details]
smb configured for 720p running on 1080p monitors

Created attachment 98916 [details]
x11 backend, 800x600 on 720p monitors after screen updates

Created attachment 98917 [details]
x11 backend, 800x600 on 720p monitors before screen updates

Created attachment 98918 [details]
x11 backend, 800x600 on 720p monitors after screen updates

Hopefully this is more helpful:

Linux 3.14
Mesa 10.1.2
libdrm 2.4.54
wayland @ hash 0f23b73a0641461884a9a8d626ce087d76406840
weston @ hash c991513483ec448408be47dbf806c5b300de2b07
sdl2 2.0.2
sdl2 @ changeset 8771:8af7a4af8fe0
SuperMeatBoy (steam, could not find version)

If there is anything else that might impact this I would be happy to provide more information.

I can confirm that the behavior on weston 1.4.0 looks identical from a quick test on the X11 backend.

Taking a screenshot triggered the screen update I was talking about so I took a couple of pictures with my cell phone so you can get a feel for what this looks like.

For the X11 photos/screenshots the game is set to run full screen at 800x600 whereas the two monitors are configured in weston.ini to 1280x720.

For the drm backend screenshot the game is running at 720p with the native resolution at 1080p.

(In reply to comment #0)
> I observed this behavior on the trunk version of weston (pre 1.5 release)
> using the game SuperMeatBoy with both libSDL 2.0.2 and libSDL2 trunk.  I was
> able to duplicate this on the r600 driver with the drm backend and the X11
> backend.  I only saw this behavior with two monitors.
> 
> The game goes into fullscreen mode after launching and appears to run at my
> native resolution of 1080p on the first monitor.  I reconfigure the game for
> 720p without exiting and the image shrinks down to the appropriate 1:1 size
> on the first monitor with black borders around it.  It does not appear
> centered.

Ok, so the problem here specifically is that it is not centered, right?
You are not expecting it to cover both monitors?
What scale do you expect?

On Wayland, configuring resolution in the game will not work as you might usually expect. It becomes a hint to the compositor, and depending on the fullscreening style used, it may have various effects, including black borders and/or scaling. Normally the preferred style would be set in the compositor preferences, unless the application asks for a specific thing, but even then it is only a hint.

Therefore it would be good to hear what exactly you expect to happen here.

> When the game is exited with this new settings and re-opened the game again
> goes fullscreen but now the image is scale up with the black borders around
> it again and it spans across to the other monitor.  On the X11 backend after
> I move the weston compositor window the application shrinks down but the
> weston menu bar at the top of the screen is then visible.  The image is
> still off center.  On the drm backend the image continues displayed at the
> wrong scale/position until the game is exited.

The panel becomes visible, when the fullscreen window is no longer active. That is expected. Activating the fullscreen window again should make the panel go away.

The other stuff however is unexpected.

I suspect this might be partly a problem in SDL2. We'd have to see a Wayland protocol dump from the game. It goes to stderr, when you set the environment variable WAYLAND_DEBUG=client (only for the game, not weston).

That dump will probably be quite long, so it will need someone to sit down and look at it for a while.

There is no Xwayland involved, right?

(In reply to comment #8)
> Ok, so the problem here specifically is that it is not centered, right?
The scale also seems off.  The bottom of the image is cut off.

> You are not expecting it to cover both monitors?
No, I am not expecting that.  If it did I would expect it to scale in a way as to not cut off part of the image.

> What scale do you expect?
Assuming the game is using/outputting a 720p buffer when the resolution switch is done I would expect the scale to be 2x2.  A useful default behavior would to be a fixed ratio scale to fit where the image is fit to fill most of one monitor.  Most games seem to be intended to run on a single monitor.  If that's not possible then the best thing to do would probably be to place the image centered on one monitor with no scaling applied.

> The panel becomes visible, when the fullscreen window is no longer active.
> That is expected. Activating the fullscreen window again should make the
> panel go away.
> 
> The other stuff however is unexpected.
Should moving the window containing the representation of the screen cause a fullscreen mode to exit with the X11 backend?  I did nothing to tell the game to exit fullscreen mode.

> 
> I suspect this might be partly a problem in SDL2. We'd have to see a Wayland
> protocol dump from the game. It goes to stderr, when you set the environment
> variable WAYLAND_DEBUG=client (only for the game, not weston).
> 
> That dump will probably be quite long, so it will need someone to sit down
> and look at it for a while.
> 
> There is no Xwayland involved, right?

Just running with SDL_VIDEODRIVER=wayland.  xwayland was not loaded in weston.ini.

It is possible this a bug with libSDL but I wasn't sure who to report it to but I thank you for taking a look at it.

I am attaching the debug logs you requested.

Created attachment 98927 [details]
drm backend with game at 720p, two 1080p monitors

Created attachment 98928 [details]
x11 backend starting fullscreen at 720p configuring for 800x600

In this log I configure the game is already configured to run at 720p which is the same resolution of each of the configured monitors for the x11 backend.  At 720p the game fits the screen.  When I configure the resolution to 800x600 it does not scale and places the image on the first monitor.  There is not bleedover to the second monitor in this case.

I will attach another log where I restart the game at this resolution and scaling is then off.

Created attachment 98929 [details]
x11 backend, gaming starting at 800x600 on two 1080p monitors

When the game starts at 800x600 the image here is scaled up across two monitors and bottom of it is cut off (see screenshot).

I have a naming error on the logs.  Whenever I run the x11 backend I have two monitors configured for 720p.  The description says two 1080p monitors but it should be two 720p monitors.

"drm backend with game at 720p, two 1080p monitors":

[3389714.964]  -> wl_shell_surface@24.set_fullscreen(0, 0, nil)
[3389715.045]  -> wl_shell_surface@24.set_fullscreen(1, 0, nil)
Then:
- uses 1280x720 buffers
- gets configure event for 1920x1080, corresponding to both set_fullscreens
- uses 1280x720 buffers a couple times still
- switches to 1920x1080 buffers, and uses those till the end

The first set_fullscreen asks for method "default", the second asks for "scale". The end result regardless of the buffer size should be, that the image is centered on one output, scaled as large as possible while maintaining aspect ratio and not clipping anything away.


"x11 backend starting fullscreen at 720p configuring for 800x600":

After fullscreening seems to always use 1280x720 buffers, and like drm dump, uses the "scale" method.

If you meant that you configured the game to use 800x600 mode, it does not seem to be effective. In SDL2, it seems the compositor's request to use the output's size gets preference after fullscreening.


"x11 backend, gaming starting at 800x600 on two 1080p monitors":

Yup, I see the outputs are defined to be 1280x720.

Here I see the game first uses 800x600 buffers, then gets configure events for 1280x720 (output size, as a response to fullscreening), uses 800x600 a bit more, and then switches to 1280x720 buffers permanently.



Ok, so maybe one issue is, that while you configure the game to use 800x600 resolution or whatever, SDL2 will still switch to the resolution suggested by the compositor. That is slightly off-topic here, as it is a SDL2 issue, or maybe a game issue.

Apart from strangely using set_fullscreen request twice, I don't see the the game/SDL2 doing anything particularly wrong. So yes, there seem to be Weston bugs related to fullscreen behaviour with the "scale" method in wl_shell_surface. The "scale" method should always show up as I described above.

(If the client chose "fill" method, the buffer should be shown in 1:1 pixel scale, leaving black borders if the buffer is smaller than the one output it is on.)

Ryan, would it be possible for you to try Weston 1.4.0?
That would tell if this is a regression. If it is a regression, bisecting could help get developer interest.

Also, I think one might be able to reproduce the problem by hacking weston-simple-egl from Weston 1.4.0 (when it was still using wl_shell interface) to reproduce the circumstances that trigger the problems. (This would be a perfect task for anyone wanting to become a Wayland developer, btw!)

wl_shell, which SDL2 uses for the time being, is being replaced by xdg_shell, so it is possible something broke in wl_shell if it wasn't broken to begin with. Unfortunately it also means that wl_shell is not too interesting.

I'm closing this on the grounds that it's probably been fixed with the new ('new') xdg_shell protocol which is used in place of wl_shell, and that we haven't had new information in four years.