Jump to content

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


cantfind
 Share

Recommended Posts

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 by cantfind
Link to comment
Share on other sites

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.

 

Link to comment
Share on other sites

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.

Link to comment
Share on other sites

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 by cantfind
Link to comment
Share on other sites

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.)

Link to comment
Share on other sites

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 by cantfind
Trying to compile it again with correct paths
Link to comment
Share on other sites

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...

Link to comment
Share on other sites

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?

Link to comment
Share on other sites

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 by Graham1
Link to comment
Share on other sites

  • 1 month later...
  • 2 months later...
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.

  • Like 1
Link to comment
Share on other sites

  • 1 year later...

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

 Share

×
×
  • Create New...