#367 Fuse's display fails horribly with GTK+ 3 under Wayland

[Philip Kendall]

Attempting to compile Fuse with GTK+ 3 on my laptop produces something virtually unusable. Starting Fuse produces a number of worrying warnings:

$ ./fuse

The Free Unix Spectrum Emulator (Fuse) version 1.3.2.
(c) 1999-2016 Philip Kendall and others; see the file
'AUTHORS' for more details.

For help, please mail fuse-emulator-devel@lists.sf.net or use
the forums at http://sourceforge.net/p/fuse-emulator/discussion/.

This program is distributed in the hope that it will be useful,
but WITHOUT ANY WARRANTY; without even the implied warranty of
MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
GNU General Public License for more details.

(fuse:9586): Gtk-CRITICAL **: gtk_distribute_natural_allocation: assertion 'extra_space >= 0' failed

(fuse:9586): Gtk-CRITICAL **: gtk_distribute_natural_allocation: assertion 'extra_space >= 0' failed

(fuse:9586): Gtk-CRITICAL **: gtk_distribute_natural_allocation: assertion 'extra_space >= 0' failed

(fuse:9586): Gtk-CRITICAL **: gtk_distribute_natural_allocation: assertion 'extra_space >= 0' failed

and the display is very definitely scaled wrong - see Fuse-startup.png. The (c) message becomes visible only when scaled to 3x3, and is then still wrong - see Fuse-3x3.png. Scaling to 2x3 (wxh) lets you see all the content, but with a big black box below the content.

Potentially relevant bits of lspci:

$ lspci
[...]
00:02.0 VGA compatible controller: Intel Corporation HD Graphics 530 (rev 06)
[...]
01:00.0 3D controller: NVIDIA Corporation GM107M [GeForce GTX 950M] (rev ff)
[...]

NVIDIA Optimus, if that makes any difference. Everything works fine with GTK+ 2.x.

[Sergio Baldoví]

What's the minor version of GTK+3?

[Philip Kendall]

I'm still seeing this with GTK+ 3.22.8 (a fully up to date Debian testing system, for what it's worth).

[Philip Kendall]

Right, after many attempts finally got somewhere working out what's going on here - it's a Wayland issue.

Running GDK_BACKEND=x11 ./fuse works absolutely fine, running GDK_BACKEND=wayland ./fuse (or just ./fuse as Wayland is the default backend on my laptop) produces the very broken display. As far as I can tell, this is a consequence of this issue reported on the GTK+ development list in 2017 where windows get an extra 52 pixels allocated under Wayland. That interacts very badly with our attempts to force the size of the windows.

Unfortunately, this doesn't mean I'm any closer to being able to fix this. Is anyone able to run GTK+ Fuse under Wayland without issues?

[Sergio Baldoví]

I'm glad you have nailed down the cause. As we are forcing the geometry on the window (GTK +3) rather the drawing area (GTK +2), it gets ugly when GTK+ (or the backend) draw the window differently.

A workaround to mitigate this bug is disabling the resize hint when using Wayland (see attachment).

[Philip Kendall]

Thanks Sergio, that's definitely better - but still not quite right; At 1x1 scale, I get a thin transparent area to the right of the screen (see Fuse-1x1.png), and at maximum size, things get clipped again (Fuse-3x3.png). I'll apply the patch anyway as it's an improvement!

[Alberto Garcia]

As Linux distributions continue moving towards Wayland (it's the default display server in Debian 10 "buster") more users will hit this bug. See e.g. https://sourceforge.net/p/fuse-emulator/discussion/314872/thread/3f0ae5443f/ and https://github.com/flathub/net.sf.fuse_emulator/issues/1.

[Sergio Baldoví]

Major efforts in fixing problems on Wayland have been made in [feature-requests:#135]. Any feedback is welcome.

See also:
https://sourceforge.net/p/fuse-emulator/wiki/Arbitrary%20scaling/

[Alberto Garcia]

I'm thinking that since this is a known problem that is already affecting users we could simply default to the X11 backend over the Wayland one until this is fixed.

The attached patch does that. The list of backends is taken from the GTK code [1], I'm simply keeping the order but without Wayland. The user can override it by setting GDK_BACKEND=wayland.

I'll probably apply this to the Debian package.

[1] https://gitlab.gnome.org/GNOME/gtk/blob/3.24.5/gdk/gdkdisplaymanager.c#L266

[Sergio Baldoví]

Thanks. Looks like a good way to mitigate this problem. As long as x11 is also available in the system.

Anyone has tested Fuse on "mir" backend? Just to ensure that there is no need to prefer x11 over mir.

[Alberto Garcia]

If x11 is not available then it will continue with the rest of the backends on the list. The * at the end ensures that Wayland will also be tried.

I suspect that most Wayland users have xwayland installed in case there's an app that only supports X11.

[Alberto Garcia]

I forgot to say: I have never used the Mir backend, I don't know how many users are out there, so I was just being conservative with the patch keeping the same backend order used by GTK.

[Sergio Baldoví]

I'm thinking that since this is a known problem that is already affecting users we could simply default to the X11 backend over the Wayland one until this is fixed.

Thanks. Committed in [9d8538].

[Alberto Garcia]

Sergio, what's this DISPLAY_ASPECT_WIDTH doing here? Shouldn't this be DISPLAY_SCREEN_WIDTH ???

int                                                                                                                                                           
ui_init( int *argc, char ***argv )                                                                                                                            
{
  /* ... */
  gtkui_drawing_area = gtk_drawing_area_new();
  /* ... */

/* Set minimum size for drawing area */
  gtk_widget_set_size_request( gtkui_drawing_area, DISPLAY_ASPECT_WIDTH,
                               DISPLAY_SCREEN_HEIGHT );                                                                                                       

[Sergio Baldoví]

Sergio, what's this DISPLAY_ASPECT_WIDTH doing here? Shouldn't this be DISPLAY_SCREEN_WIDTH ???

DISPLAY_ASPECT_WIDTH looks good to me. DISPLAY_SCREEN_WIDTH is 640 pixels (to allow hires modes) and DISPLAY_ASPECT_WIDTH is 320 pixels, so you would need DISPLAY_SCREEN_WIDTH/2 to get the minimum width, but IMO that's the purpose of DISPLAY_ASPECT_WIDTH.

[Alberto Garcia]

Right, I see. Thanks!