Fullscreen on Linux?

[josswright]

The main page lists F11 as the key to make protracker fullscreen, but that's written under the MacOS section and it doesn't seem to work in Linux.

Is there a way to fullscreen this on Linux? If I just maximise the window then the mouse doesn't line up with the displayed buttons, so is unusable. (For reference, I'm using i3 under Arch linux.)

I know that Linux isn't as fully supported as Mac, but this would be amazingly helpful! (If there were a way to start the program fullscreen, that would be even better!)

Thank you for such an amazing project.

EDIT: It seems that the F11 problem was a problem with my external keyboard, and F11 does work when I press it on my laptop. The mouse coordinate mismatch issue mentioned in the next post is still a problem, though.

[josswright]

A quick dip into the sourcecode led me to creating a ~/.protracker/protracker.ini file. Unfortunately, even though FULLSCREEN=TRUE works, I still have the problem with the mouse being 'offset' from what's shown on screen, so I can't click on any buttons.

If there's another option in there that might help, I'd love to know about it!

EDIT: FULLSCREENSTRETCH=TRUE also has the same problem. It looks like the mouse clicks are registering for an unscaled window in the top left of the screen, even though the graphics themselves are scaled to fullscreen.

[8bitbubsy]

It works fine on both macOS and Windows, and I don't really support Linux. I don't know why it doesn't work for you...

This sounds like an issue with the backend SDL2 decided to use. It works correctly in fullscreen on Ubuntu Mate on my ThinkPad T430. I am handling the mouse based on "render x,y" coords in fullscreen mode.

[josswright]

Well, I'm having a bit of a play with the code around window scaling and mouse warping. I'll let you know if I find anything. Thanks!

[8bitbubsy]

As said, it already works fine on macOS, Windows and on Ubuntu Mate on my laptop, so if you find anything, it would most likely be a hack for the backend and GPU drivers you use. This is why I don't support Linux: It's just not consistant, there's always something being off for someone in how SDL2 behaves.

EDIT: Make sure you have the latest protracker.ini from the repo, with the new INTEGERSCALING etc settings. Try again with the that config (should be copied to both the app directory and the config directory, just in case).

[josswright]

Ah, the fact that it works in Ubuntu means that I might want to look in a slightly different place. That's a good bit of extra information, thanks!

(And I just found the latest protracker.ini when I started going through the source. There are a few different behaviours around integerscaling/fullscreen/fullscreenstretch, but none that are working at the moment.)

Thanks again.

[8bitbubsy]

(And I just found the latest protracker.ini when I started going through the source. There are a few different behaviours around integerscaling/fullscreen/fullscreenstretch, but none that are working at the moment.)

Sounds like the SDL2 port for your backend is buggy. Those settings also work fine on Ubuntu Mate on my laptop.

[josswright]

Mystery solved or, at least, problem identified. This seems to be the result of using an external monitor connected to my laptop. When I have just one monitor -- either the laptop's internal or just the external -- it works fine.

(I have a vague memory from years ago that SDL had issues with multiple monitors. I don't know if this is still the same old problem.)

For the moment, though, this at least lets me work around the problem reasonably. If I have time, I'll see whether this is a known issue in Linux that can be solved fairly easily. Thanks again for the help.

[8bitbubsy]

Ah, I have never tested my stuff with a configuration like that, to be honest...

[8bitbubsy]

I see several challenges with having two monitors and calculating some stuff used for fullscreen and mouse scaling. F.ex. what monitor index to pass to SDL_GetDesktopDisplayMode(). I should probably put up a notice about this on the front page and on the git readme.

[josswright]

It does look complex, but I'm sure that there must be code out there that does it. If I find anything that has already solved it, I'll be sure to report it here.

If you are adding this to the README/front page, might you also put a mention about the existence and location of the configuation file? Installing protracker through my package manager, I didn't discover the configuration file until I started digging into the source code.

Thanks again for the responses, and for the software. I'm now off to relive the very best of my Amiga 1200 days!

[josswright]

I see several challenges with having two monitors and calculating some stuff used for fullscreen and mouse scaling. F.ex. what monitor index to pass to SDL_GetDesktopDisplayMode(). I should probably put up a notice about this on the front page and on the git readme.

(Just as I was thinking about this issue...) The 'normal'behaviour in many fullscreen applications, such as games, is that the program will just choose a monitor and fullscreen there. For GetDesktopDisplayMode, I'd just choose the lowest index by default. A configuration option to set the index would probably be ideal.

I'm still poking at the code occasionally to try and fix this issue! (I have verified, though, that my Windows install seems to handle a dual-screen setup with no problems.)

EDIT: Having said that, I just moved pt2-clone to my external monitor and hit F11. It went fullscreen on that monitor, but the mouse clicks were clearly being registered in different positions. It looks like in Windows you can at least use pt2-clone in fullscreen if it's on the right monitor. In Linux I'm fairly sure that it's broken whichever monitor you choose in a multi-monitor setup.

[josswright]

I feel like I'm continually retracting my own issue reports here, but I've just tested this again on Linux. My experience is currently that if I fullscreen pt2-clone on my external monitor (which is now to the left of my laptop screen) then button clicks are correctly registered. If I fullscreen it on my laptop screen, the clicks are not registered in the correct places.

Interestingly enough, this is the exact opposite of the behaviour in Windows (on the same machine).

Just for interest, I tried changing the primary monitor via xrandr. It has no effect on this behaviour.

If I change the monitor layout so that the laptop monitor is (logically) on the left rather than the right then the behaviour is (predictably) reversed -- clicks are registered correctly on the laptop but not the external. It seems that it works on the leftmost screen, which isn't really that surprising.

If the monitor layout is one above the other, clicks are correclty calculated on the top monitor. I haven't yet had a chance to see what happens in Windows with this layout.

[8bitbubsy]

As far as I know, there's no elegant and simple fix to this problem... I wish SDL2 could sense what monitor the window is on before you enter fullscreen. This way I could just get that number when toggling fullscreen, and getting the correct display attributes.

[josswright]

It is annoying. Looking at multi-monitor issues in SDL this kind of problem is at least ten years old!

Would the alternative of manually specifying a screen work? Then, even if you were on screen 2 it would force the fullscreen to occur on screen 1 and you could then be sure of the correct attributes? That seems better than honouring the current screen but not being able to click buttons.

If there were a configuration option to set the screen manually, a user could at least work around the problem.

[josswright]

I'm largely ignorant of SDL, but does this function not do it? https://wiki.libsdl.org/SDL_GetWindowDisplayIndex

EDIT: I just added:

else if (event.window.event == SDL_WINDOWEVENT_MOVED) 
    printf( "%d\n", SDL_GetWindowDisplayIndex( video.window ) );

in the handleInput() function of pt2_main.c (at line 369), and it seems to be reporting the current display ID correctly. (At least in Linux!)

[8bitbubsy]

That might actually be what is needed. I'll try to add this later today.

[8bitbubsy]

Took a look at the code, and it seems like I am already doing a call to SDL_GetWindowDisplayIndex() in updateRenderSizeVars(). In other words, I don't understand why this issue happens. Maybe it's a bug in using SDL2 with Linux.

[8bitbubsy]

Hmm, I get the same issue in Windows. I need to play around with this some more.

[josswright]

I found that call as well! Linux does fullscreen on the current screen, so that's probably fine. The pointer offset problem is in Windows as well, though.

I noticed that when I resize the window (for example maximizing it in i3), I get the Protracker output centered in the window with black bars around the edges. That's exactly the behaviour I'd hope for, but it also doesn't render the mouse location properly in that case.

Could these all be related to the same issue? I'm seeing references to this kind of problem related to SDL_RenderSetLogicalSize():

• https://stackoverflow.com/questions/56510595/get-texture-coordinates-of-mouse-position-in-sdl2
• https://stackoverflow.com/questions/26238701/sdl2-resizing-the-window-mouse-position

I tried putting in a call to updateRenderSizeVars() whenever an SDL_WINDOWEVENT_SIZE_CHANGED event happened, but it seems like some scaling or offset logic must be going wrong somehow.

Thanks so much for taking the time.

[8bitbubsy]

The window isn't supposed to be resizable! There's all sorts of bugs with that because I'm not supporting it (intentionally). EDIT: Only through setting the upscale factor in protracker.ini

[josswright]

Oh, I know! I did it to try and work around the fullscreen issue. (With i3 being a tiling window manager, it automatically resizes if I don't have the protracker window floating.) I was just wondering if the logical error leading to the mouse offset might be from the same source, though.

Didn't mean to complicate things further! :)

[8bitbubsy]

I did some debugging of mouse coordinates in different states, and I have come to the conclusion that SDL_GetMouseState() messes up if you drag the window to another screen and enter fullscreen mode. When the mouse is in the upper left corner of the display (in the border area), x/y is not 0,0 but something much higher. Weird...

[8bitbubsy]

"Mouse raw" is the values directly from SDL_GetMouseState(). The mouse cursor you see on screen is done in hardware, so that is the position it really is at, not what you get from SDL_GetMouseState(). In other words, the problem is that it counts the left screen (this is the right screen) for the absolute mouse coords.