Gala: Not able to display an application/video on second monitor in fullscreen.

[andreasfelix]

Since Juno it is not longer possible to display some applications (like chrome/firefox) in fullscreen on a second monitor.

However it is possible to start the application or video in fullscreen on the first monitor and than switch it to the second monitor via the shortcut super+shift+right-arrow.

---

Want to back this issue? Post a bounty on it! We accept bounties via Bountysource.

[jamesdwilson]

I think I am experiencing the same issue.
I have my builtin laptop display marked as a non-primary display (not-starred in Displays), and if I play videos on it, it works, but if I fullscreen on the laptop display, it is very flakey and will most of the time not go fullscreen correctly. It will work like 1/5-1/10 times.

However, if I fullscreen the video on my primary monitor and then escape fullscreen, and then move the window to my laptop display, it can fullscreen repeatedly with no issues.
uname -a:

Linux xps 4.15.0-38-generic #41-Ubuntu SMP Wed Oct 10 10:59:38 UTC 2018 x86_64 x86_64 x86_64 GNU/Linux

elementary OS 5.0 Juno
GTK+ 3.22.30
NVIDIA 390.77 in performance mode

Dell XPS 9570

[Cariffo]

I am also experiencing this issue. I have a Laptop with built-in display as primary monitor and a secondary monitor connected to it.

I can start chrome/ firefox/ epiphany (issue is same on all of these) and fullscreen on the primary monitor without any issues.
But if i have chrome on my secondary monitor and fullscreen a video, it freezes (sound keeps playing, only the video is bad). I cant recover from this, i have to exit chrome on that display completely because only exiting the fullscreen leaves it lagging.

A workaround to this is to start the fullscreen on primary and then move it to the secondary monitor as suggested above... but this is not a fix! this needs attention asap

-- EDIT --
Starting a window on primary, fullscreening it, disabling fullscreen and then moving it to secondary as suggested above doesnt help as soon as i fullscreen any video on secondary in chrome i get the issue

Using:
Elementary os 5.0 Juno
GTK+ 3.22.30
Linux 4.15.0-39-generic
Nvidia 415.13

MSI GP60 2QF

[Cariffo]

Hey there! I have an update... the issue is still very much present but today i figured out it only occurs when you are trying to fullscreen a video from a maximized window on the second monitor... if i fullscreen a video from a non-maximized video it works fine

...still... needs fixin

[Thalhammer]

Experienced this as well:
I have a Notebook with an Intel/Nvidia combo (Optimus).
My Primary display is 1920x1080 internal connected via eDP.
My secondary display is 1920x1200 connected via an HDMI to VGA adapter on HDMI0.
I tried with Chrome-stable and firefox on youtube.
If I open the video on a maximized window on my primary, go to fullscreen it is fine. Once the video is fullscreen I can move the video to my secondary (win + shift + right) it keeps working until I leave fullscreen.
If I open the video in a non maximized window on my secondary and go fullscreen everything is fine.
If I open the video in a maximized window on my secondary video lags as hell (~1fps), audio is fine, once I manage to leave fullscreen chrome/firefox is not responsive and hangs as well. Once its not maximized any more it is back to normal.
I have a fresh install of Juno with all the updates available installed.

[DonCorleone1988]

Can confirm. I also experience this on my Dell Optiplex 9020. Fullscreen videos work fine on my primary monitor, but when I attempt to fullscreen any video on my secondary monitor the screen freezes. Whatever application I am using also freezes too.

Hopefully a solution will come soon?

[ettoreperri]

I can confirm that issue too.
Not only for video playing but in every maximized app on secondary monitor, when I switch to fullscreen mode, the screen frezees.
Es: Maximized Chrome Window -> F11 -> screen freezes

Maybe after row 982 of gala/src/WindowManager.vala in full screen case needs to be declared an explicit call
like

case Meta.SizeChange.FULLSCREEN:
handle_fullscreen_window (actor.get_meta_window (), which_change);
break;

[jamesdwilson]

I have no additional additional information other than what I provided before, and I wish to corroborate I am seeing the same thing as reported in the other comments.

[andreasfelix]

Another workaround that works for me is to enable _System titlebar and borders_ in Chrome settings as the user @lxmcf wrote in the other issue #442 :

Not sure if this will help but google chrome will only exhibit this behaviour if you aren't using the 'System titlebar and borders' option, if you disable that it adds a clunky titlebar and takes up more screen but it will allow the browser to be fullscreen and eliminate this behaviour.

I have recorded a video showing this off, note that the video is recorded on my second screen as the main screen does not inherit any of this behaviour.

https://youtu.be/29wwInVGB_Y

_Originally posted by @lxmcf in https://github.com/elementary/gala/issues/442#issuecomment-454222492_

[gorghino]

I am also experiencing this issue.
At the moment I'm switching fullscreen window to the second screen with WINKEY+SHIFT+LEFT_ARROW. This way doesn't break the window.

[MuhammedKpln]

Have same issue, i don't understand why elementary do not focus on this problem..

[Thalhammer]

@MuhammedKpln I think what you don't understand is that elementary OS is an open source project. There is no obligation for anyone of those guys to fix anything.

You have a problem with the fix taking to long? FIX IT.
You can't code to fix it yourself? PAY SOMEONE TO FIX IT.
You can't pay someone to fix it? STOP EXPECTING PEOPLE TO FIX YOUR STUFF FOR FREE.

That said the reason why it is not yet fixed is probably that this issue only a small group of people.

[vjr]

@peteruithoven could it be so simple as to just remove this condition? -> https://github.com/elementary/gala/blob/e50b064254431c80f6db60c3e3686241e06c781e/src/WindowManager.vala#L921

i will try hooking up my laptop to my PC monitor and try that code change but i have to install juno on my laptop first.

[vjr]

I couldn't reproduce the issue on my laptop with a monitor connected via HDMI. Tried the built-in browser (epiphany) as well as firefox with a fresh non-updated Juno install as well as fully-updated just now. Tried F11 to fullscreen on both primary laptop screen and secondary monitor as well as youtube video fullscreen button, but no luck.

My laptop has built-in CPU's intel GPU (intel core i5-6500u) so I wonder if others are facing this issue with hardware that has nvidia GPU (non intel CPU-built-in GPU) not sure here?

[andreasfelix]

The bug only occurs on certain applications and only if the window is maximized before entering full screen. Also recently the bug does not occur on Firefox for me anymore. For Chrome and Chromium it only happens if "Use system title bar and borders" is unchecked. For VS Code it only occurs when the "Title Bar Style" is set to "custom".

I also tested this on 4 different machines which had Intel or nvidia GPUs.

I tried to comment out line 921/922 (as suggested by @vjr ,no idea what it does) and started gala with ./build/src/gala --replace (not sure if this is right...) but i did not help.

I also found out that the function handle_fullscreen_window is not called when entering full screen from a maximized window on a second monitor. Not until leaving full screen and unmaximizing/moving the window the function handle_fullscreen_window gets called the amount of times full screen was toggled.

When the window is not maximized the handle_fullscreen_window gets called when entering and when leaving full screen. I think this is the normal behavior.

Example:
Toggling full screen 4 times on a maximized window -> handle_fullscreen_window gets not called
Unmaximizing the same window -> handle_fullscreen_window gets called 4 times

For me it seems something prevents handle_fullscreen_window to be called for maximized windows on a second monitor.

[andreasfelix]

I am complete beginner to gala/vala, but I tried to do some further testing:

I think the problem is that position_changed signal gets not emitted right away for a maximized chrome/chromium window. The position_changed signals stack up and get emitted all together when the chrome/chromium window is unmaximized. There must be something that prevents the position changed signal to be emitted. (see below)

I've tried to bypass the position_changed signal by registering the window_change_complete method to the raised signal (not sure what its purpose is), adding

window.raised.connect (() => window_change_complete (actor, which_change, size_signal_id, position_signal_id));

to the end of the size_change method. This made it actually possible to correctly fullscreen a maximized chromium window on a second screen, but led to other weird behavior when moving windows.

This is probably not that surprising as I was kinda abusing the raised signal, but it showed that the problem does not lie in the window_change_complete or handle_fullscreen_window method and is rather caused by something related to the position_changed signal.

---

One can check the stacking behavior of the position_changed signal by logging the signal/function calls:

public override void size_change (Meta.WindowActor actor, Meta.SizeChange which_change, Meta.Rectangle old_frame_rect, Meta.Rectangle old_buffer_rect) {
  debug("size_change");
  ...
  position_signal_id = window.position_changed.connect (() => {
    debug("position_changed");
    window_change_complete (actor, which_change, size_signal_id, position_signal_id);
  });
  ...
}

void window_change_complete (Meta.WindowActor actor, Meta.SizeChange which_change, ulong size_signal_id, ulong position_signal_id) {
  ...
  switch (which_change) {
    case Meta.SizeChange.MAXIMIZE:
      debug("MAXIMIZE");
      maximize (actor, new_rect.x, new_rect.y, new_rect.width, new_rect.height);
      break;
    case Meta.SizeChange.UNMAXIMIZE:
      debug("UNMAXIMIZE");
      unmaximize (actor, new_rect.x, new_rect.y, new_rect.width, new_rect.height);
      break;
    case Meta.SizeChange.FULLSCREEN:
      debug("FULLSCREEN");
      handle_fullscreen_window (window, which_change);
      break;
    case Meta.SizeChange.UNFULLSCREEN:
      debug("UNFULLSCREEN");
      handle_fullscreen_window (window, which_change);
      break;
  }
 ...
}

Unmaximized window (normal behavior)

** (gala:10966): DEBUG: 03:55:04.211: WindowManager.vala:998: UNMAXIMIZE
** (gala:10966): DEBUG: 03:55:06.720: WindowManager.vala:965: size_change
** (gala:10966): DEBUG: 03:55:06.720: WindowManager.vala:979: position_changed
** (gala:10966): DEBUG: 03:55:06.720: WindowManager.vala:1002: FULLSCREEN
** (gala:10966): DEBUG: 03:55:07.840: WindowManager.vala:965: size_change
** (gala:10966): DEBUG: 03:55:07.840: WindowManager.vala:979: position_changed
** (gala:10966): DEBUG: 03:55:07.840: WindowManager.vala:1006: UNFULLSCREEN

Maximized window

** (gala:10966): DEBUG: 03:55:18.994: WindowManager.vala:994: MAXIMIZE
** (gala:10966): DEBUG: 03:55:20.403: WindowManager.vala:965: size_change
** (gala:10966): DEBUG: 03:55:21.915: WindowManager.vala:965: size_change
** (gala:10966): DEBUG: 03:55:23.196: WindowManager.vala:965: size_change
** (gala:10966): DEBUG: 03:55:23.196: WindowManager.vala:979: position_changed
** (gala:10966): DEBUG: 03:55:23.196: WindowManager.vala:1002: FULLSCREEN
** (gala:10966): DEBUG: 03:55:23.196: WindowManager.vala:979: position_changed
** (gala:10966): DEBUG: 03:55:23.196: WindowManager.vala:1006: UNFULLSCREEN
** (gala:10966): DEBUG: 03:55:23.196: WindowManager.vala:979: position_changed
** (gala:10966): DEBUG: 03:55:23.196: WindowManager.vala:998: UNMAXIMIZE

[andreasfelix]

Another possibility to bypass the position_changed signal is to add

if (which_change == Meta.SizeChange.UNFULLSCREEN || which_change == Meta.SizeChange.FULLSCREEN) window_change_complete (actor, which_change, size_signal_id, position_signal_id);

to the end of the size_change method (check https://github.com/andreasfelix/gala/commit/9af7a7f37ca2c1c8a513829496fbb1a76c966721). This makes it also possible to fullscreen maximized chromium windows again and does not lead to any other glitches (as far as I tested it). I am aware that this is not a really clean solution, but I am not familiar with vala/gala/mutter ...

Maybe this could be used as temporary fix till somebody provides a better solution.

[inad9300]

I'm also experiencing this problem, on a Lenovo laptop connected to a Dell monitor.

I hope someone finds and solves this issue, it having the number it has (#404) and having been reported months ago... Best of luck, @andreasfelix! You'll be on my prayers :pray:

[andreasfelix]

It's fixed and already has been merged into master!