Packaged applications with strange behavior on dual monitors in Linux

My right monitor is my primary monitor, because it’s the nicer screen, and it’s how I like my monitors arranged, but my left monitor is 16:10 1920x1200 and my right monitor is 16:9 1920x1080. If I launch it on the right monitor, which it does by default because it’s set as the primary, it doesn’t take mouse click input on my main menu. If I alt+tab out of it but alt+tab back in, there’s a black bar of nothingness on the bottom, and the screen is shifted up; mousing over where the buttons should be, lights them up like it’s supposed to. If I restart the game but drag it over to the left monitor using GNOME’s window spread feature, I can see why there’s that black bar of nothingness: it’s the difference of 120 pixels of vertical resolution that my left monitor has over my right monitor. Now my UI buttons accept input like they’re supposed to. I can also drag the window back to my right monitor, and the UI buttons will be clickable like they’re supposed to be.

Also, if the game is on the right monitor, I’ll left click to fire my gun, and it will rotate the camera, and therefore my character’s aim, by nearly 180 degrees as well as firing the gun, every time I fire. On the left monitor, this problem doesn’t exist.

Both of these issues are reproducible 100% of the time when I run the executable. I first saw this issue when upgrading to 4.16, and it hasn’t disappeared when upgrading to 4.17. I also spoke to a developer of Helium Rain, a UE4 game primarily developed on Linux that of course ships a Linux binary, and he said that someone using GNOME on Arch did report that bug to him as well, though he couldn’t reproduce it on Ubuntu. This is odd to me, because I also run Ubuntu. Any help would be much appreciated.

Hey -

Are you referring to running the editor and seeing this behavior or are you running a specific game? If possible, can you try launching ith the -nohighdpi argument to see if that helps. If you have the setup steps or if you’re able to repro the behavior in a new project, please let me know to help me investigate the issue locally.

Thanks for the quick response. These issues do not occur in the editor or when running the packaged executable in windowed mode. The problem persists with -nohighdpi. I’m unsure if it will reproduce reliably on another machine, but I know it happens in my project 100% of the time when fullscreen is enabled. As stated above, a Helium Rain developer said that one of his customers ran into the issue and the developer was unable to reproduce it himself, so it might be tricky to track down. I’m on Ubuntu 17.04 with the ubuntu-gnome-desktop package installed on top of it, which may or may not result in different behavior than if you were using the Ubuntu GNOME distro. I expect that the problem is related to the fact that the desktop is drawn from the top left to the bottom right, but the left monitor is not the primary. I was able to reproduce it in a new project using the below steps:

  1. Create a new Third Person template blueprint project.
  2. Package the project for Linux. No other modifications should be necessary.
  3. With the right monitor set as the primary using the monitor setup listed in my initial post, run from the packaged directory. WASD input will move the character, but it won’t take mouse input.
  4. Hit the Super key to enable GNOME Window Spread. Drag the game over to the left monitor. Initially, it won’t take mouse input here either.
  5. Alt+tab out of the game to another application, like a web browser. Alt+tab back to the game. It should now be a 16:9 game running with a black bar at the bottom of the 16:10 screen.
  6. Hit the Super key to enable GNOME Window Spread again, and drag the game back to the right monitor. You can now use the mouse to rotate the camera view. Left clicking will now, for some reason, rotate the camera around the player by some angle that appears to be slightly less than 180 degrees.

I tried setting the game to 720p windowed and then back to 1080p fullscreen in C++ code, and the problem persists through that as well.

Seems to be related to this, which links to UE-19996, marked as fixed, but clearly it is not.

This is very interesting.

A kind fellow in the Unreal Discord server said the following:

what I could say about it is that the problem comes from SDL which unreal engine uses on linux

SDL creates a big square that takes the left monitor as a height and both monitors as width

to avoid any issues you need to set the smaller screen on the left and the biggest on the right

I adjusted my settings in GNOME such that the smaller 16x9 monitor was interpreted as being on the left (still set as the primary monitor) and the larger 16x10 monitor was interpreted as being on the right, and the game played just fine. Of course, this isn’t a great permanent solution.

Hi ,

I have replicated the resizing issue in 4.18 when swapping monitors on GNOME Shell and have added the bug to our tracking system as UE-53135. This should hopefully be available via our public bug tracker at in the future.

I was unable to replicated the mouse issue exactly as you specified but by placing the cursor into the black area outside of the game screen and then closing GNOME Activities (with the super key) rather than clicking the issue occurred for me.