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?

Anything else I can do to help?

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

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

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

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.

Ok, will do.

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.

Sure, here are the logs when running borderless.fullscreen = "false" in user.cfg: system_info.txt userreport_hwdetect.txt mainlog.html interestinglog.html

Thanks, any idea how I can fix the snap? is it even possible to change the library version it uses? How do I check whether it's a permission issue of a difference in libraries?

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

Running Linux 6.0, Gnome 43.1 on wayland, I get the following error when trying to run the snap version: ERROR: SDL library initialization failed: wayland not available terminate called after throwing an instance of 'PSERROR_System_SDLInitFailed' In ~/.config/0ad/logs (where my native install writes to) - I have system_info.txt and userreport_hwdetect.txt along with the html mail log and interestinglog but in the snap location I only have the html files (and they contain nothing related to the problem except for the aforementioned error). Any idea why the SDL in snap won't work with wayland, while the game runs perfectly fine natively?

I've tried adding sleep... It still doesn't work about half of the time... If I run it as a single line from the terminal, when I lose signal, I can rerun the command (arrow up and enter), and the signal comes back. The error I get when the command fails is X Error of failed request: BadMatch (invalid parameter attributes) Major opcode of failed request: 140 (RANDR) Minor opcode of failed request: 21 (RRSetCrtcConfig) Serial number of failed request: 31 Current serial number in output stream: 31 As for the sound, I locked the profile in pavucontrol, but it still doesn't work - it says my HDMI is unplugged when in 1080, only when I return to 4k it sees it as plugged. Interestingly, after recovering from losing the signal by running the same command a second time, I do get sound - but if it doesn't lose signal on the first time, running the command again doesn't restore the sound. Something is very buggy - either in the intel drivers, my HDMI firmware, or xrandr.

I don't know why, but sometimes xrandr fails to change the resolution, sometimes xrandr stops the computer from outputing any signal, and every single time xrandr prevents sound from working... So the workaround with xrandr is not working all that well... I've filed bugs with xrandr. What's wrong with using SDL_SetWindowDisplayMode for changing the fullscreen resolution?

Hmmm... adding the line boderless.fullscreen="false" doesn't seem to have any effect...