When starting the game in Gnome on wayland, the mouse can't reach part of the screen in full screen.

[cantfind]

Once in the main menu, the mouse can not reach a strip at the top of the screen, and at the left of the screen.

When launching from dash, the strips are narrower than when launching from Gnome Console (can't reach the menu at all when launched from console).

Tried

borderless.fullscreen = false

or/and

borderless.window = true

It made no difference.

I've attached the logs.

 

interestinglog.html mainlog.html system_info.txt userreport_hwdetect.txt

Edited November 28, 2022 by cantfind

[vladislavbelov]

Could you attach logs when running with borderless.fullscreen = false?

[cantfind]

Sure, here are the logs when running borderless.fullscreen = "false" in user.cfg:

 

 

system_info.txt userreport_hwdetect.txt mainlog.html interestinglog.html

[vladislavbelov]

Which was the last version was working for you? Does window mode work for you?

[cantfind]

I haven't used any previous version on this system...

Window mode works, it produces a small window.

I have a lead - the region the mouse is constrained to when in full screen, is up to the top left of the window.

I've observed it by starting at window mode, and pressing alt+enter to get to full screen while the mouse cursor is inside the window.

If I press alt + enter when the mouse is outside the window region - the constraint gets smaller. If I leave the mouse cursor at any of the four corners of the screen and get to full screen with alt + enter, I have access to the whole screen.

It also works in full screen mode - if I start the game from console when my mouse is in a screen corner, I have access to the whole screen.

This is why when I launch the game from the menu, I'm constrained to different area then when I launch from console - the position of the mouse and the position of the window would determine that constraint.

So - I have a workaround - but I hope that this is enough information to find that bug and fix it? Looks like a coordinate transform issue when going full screen.

 

[Stan`]

You're using a much more recent version of the SDL than the one we currently use (2.0.12) Also it seems you compiled the game with 2.24, and you are running it with 2.26 dunno if there are breaking changes.

We don't change anything depending on cursor position, so it seems it's an SDL bug, they had a lot of problems with wayland.

Maybe it would be nice to open a ticket on their bug tracker instead, see what they have to say.

[cantfind]

Ok, will do.

 

[Stan`]

Thanks. Really sorry we cannot help more 

[cantfind]

Hmmm... I've tried making a toy example to make it easier to pin down the bug - but I can't reproduce it with my simple code.

I'm simply logging the mouse coordinates I get with SDL_PollEvent, while toggling between windowed and full screen mode.

This toy example seems to be working fine as long as I get the new window surface after changing to full screen.

I've also let SDL render the cursor, and there's no limit on it's range.

I'm looking around in VideoMode.cpp, looking where I'm doing things differently, it seems to be pretty close from what I can gather - but the part of drawing the GUI is not there (I guess it's in GUIManager?).

If you could help me make a minimal toy example that pin points this bug, I would submit it to SDL - or alternatively, we might discover it's specific to 0ad.

I can upload my toy example to github, if that's any help.

Edited December 1, 2022 by cantfind

[vladislavbelov]

7 hours ago, cantfind said:

This toy example seems to be working fine as long as I get the new window surface after changing to full screen.

That's interesting. Could you add cursorbackend = "system" to your user.cfg (it should switch a cursor to the system one, "sdl" will bring it back)?

You might just attach your example code here as an archive.

Also are you able to compile the SVN version of the game? (I can provide patches to test.)

[cantfind]

cursrbackend="system" just made the cursor keep it's Gnome looks, it's still restricted in movement.

I attach my rudimentary SDL example, which works fine.

And I can compile the 0ad (got it from github, I assume it's the same as the SVN version?)
By the way, I've noticed you have the lines

// For some reason, when switching from fullscreen to windowed mode,
// we have to set the window size and position before and after switching
SDL_SetWindowSize(m_Window, w, h);

SDL_SetWindowPosition(m_Window, m_WindowedX, m_WindowedY);

I've tried my example with and without these lines, and could not discern any difference - maybe it's a remnant of a fix of an SDL bug that was since fixed?

It doesn't have anything to do with the issue at hand, but I thing you could delete some lines in VideoMode.cpp with no adverse effects...

 

main.cpp

Edited December 3, 2022 by cantfind
Trying to compile it again with correct paths

[cantfind]

Any patch you would like me to compile? Any changes to that cpp code I wrote you want me to make?

I'll happily help in hunting this bug down

[Stan`]

What if you set highdpi = true in the options ?

https://trac.wildfiregames.com/ticket/6649#comment:5

[vladislavbelov]

Did I get you correctly: if you don't call screenSurface = SDL_GetWindowSurface(window); after each event then you reproduce the problem?

BTW what's the system you're on?

[cantfind]

I don't see any difference with highdpi = true

And with regards to what happens when I don't call screenSurface = SDL_GetWindowSurface(window); after switching window mode from windowed to full screen - The window doesn't really display as full screen, and the mouse cursor isn't restricted to the part of the window that's rendered. When the mouse is over the part of the window that's rendered, the cursor changes to the SDL one, and mouse events are handled by the window - when the mouse if outside that region, mouse events aren't handled by the window and the mouse cursor is the system's (even though SDL supposedly is in full screen mode) - regardless of if it is SDL_WINDOW_FULLSCREEN_DESKTOP or SDL_WINDOW_FULLSCREEN. 

Interestingly, If I use SDL_SetWindowDisplayMode to set custom resolution, and then call switch to fullscreen it'd fill the whole screen, but the coordinates reported by the mouse even would still be in the original window resolution, and not the one set in the above mentioned function.

It's not exactly what happens with 0ad, where the mouse cursor is restricted in movement.

Anyway, once I use SDL_GetWindowSurface, everything behaves as expected...

[cantfind]

Anything else I can do to help?

[Stan`]

1 hour ago, cantfind said:

Anything else I can do to help?

On 08/12/2022 at 1:51 PM, vladislavbelov said:

BTW what's the system you're on?

@vladislavbelov is a bit busy these days, but I think you didn't answer the question. Do you have a 4K screen or zoom enabled ?
 

[cantfind]

I have several computers on which I run 0ad - this particular one is an Asus Zenbook UX303UA, sporting Core i7-6500U and running off of Intel UHD 520 (SKL GT2).

The monitor has the resolution 1920x1080, and I don't have zoom enabled.

Gnome version 43.2, Windowing system Wayland.

I though all the required information was provided by the logs I've attached to my first post in system_info and hw_detect?

Any additional information I have neglected to provide?

[Stan`]

In general it's enough but sometimes we need the exact distributions because it is not available to us. I don't think screen zoom is either. Thanks for the extra info, sorry things go slow around here 

[Stan`]

@cantfind just realised you didn't give the distribution name

[Graham1]

This is the same issue I have on Fedora 37 (also posted on this forum). Apologies if this has already been mentioned (quite a bit to take in above). I have noticed that the area accessible via the mouse is more, if Fedora's default driver is used (in my case NV138). Nvidia's driver restricted the area quite a bit in that I couldn't get to some parts of the menu.

For me, this is only an issue with Wayland, Xorg is fine. When in Wayland, pressing Alt+Tab makes the full screen accessible again, so at least there is a workaround.

Edited December 19, 2022 by Graham1

[vladislavbelov]

@cantfind @Graham1 I've came up with another random idea: https://trac.wildfiregames.com/ticket/6649#comment:7, but it needs to compile the game.

[Graham1]

On 05/02/2023 at 8:43 AM, vladislavbelov said:

@cantfind @Graham1 I've came up with another random idea: https://trac.wildfiregames.com/ticket/6649#comment:7, but it needs to compile the game.

Hi vladislavbelov. Thanks for the suggestion above. I am now using Fedora's default driver with Xorg so this isn't an issue for me anymore.

 

[vladislavbelov]

5 minutes ago, Graham1 said:

Hi vladislavbelov. Thanks for the suggestion above.

You're welcome!

5 minutes ago, Graham1 said:

I am now using Fedora's default driver with Xorg so this isn't an issue for me anymore.

I've figure out the issue already, it's a problem inside GNOME (mutter): https://gitlab.gnome.org/GNOME/mutter/-/issues/2740

And now in SVN we have options to control that behavior.

[Graham1]

Issue seems to be resolved now when using Wayland in Fedora 40.