Bug 389495

Created attachment 110142 [details]
Patch to force GTK3 applications to request SSD

The problem isn't fixed on the GTK side, yet, however, this should suffice for solving the problem on this side.

With this patch, WAYLAND_DEBUG=1 now yields:

"[2274367.614]  -> org_kde_kwin_server_decoration@27.request_mode(2)"

Could you please attach a full wayland debug output. That should help me creating a test case. I won't be able to test a patches gtk, so I need to recreate the issue in other ways.

Created attachment 110143 [details]
Debug output for Evince

Created attachment 110144 [details]
Debug output for MyPaint

The output for Evince and MyPaint should suffice, I hope.

It took me longer to understand the issue than I usually would, so I apologize for possibly having caused any confusion and frustration throughout. :)

The debug output shows that the application request SSD. So do they get KWin decos or not?

On Sway, which implements your SSD protocol, no matter whether the decorations requested are none, client or server, server-side decorations are always used.

So, maybe examining how Sway implements and handles the procotol could yield some clues? I don't yet understand enough about programming to be of much use in this regard, sorry.

I'm sure whether or not providing debug output for these applications of Sway would help or not. Probably not, most likely... :/

Created attachment 110145 [details]
Screenshot demonstrating issue on kwin_wayland

I'll post one showing results on Sway in a moment.

Created attachment 110146 [details]
Screenshot demonstrating results on Sway

(In reply to Martin Flöser from comment #6)
> The debug output shows that the application request SSD. So do they get KWin
> decos or not?

The screenshot I uploaded shows that requesting SSD bring back the same issue that you solved when CSDs were always being requested. It solved that particular bug, but not this one.

For evince the result is as expected. The window requests ssd and gets ssd. Evince should not request SSD as it is CSD.

In the MyPaint case the decoration protocol is not used for the main window. Thus it does not get any decoration. It's the surface with id 22.

I'm sorry, but it looks to me like KWin is working exactly as expected. Sway is different - as it is tiling. The screenshot looks like all windows are maximized and always server decorated. So it might just look working, but in fact isn't.

Is there a solution to make MyPaint and the like have decorations, CSD or SSD, on the KWin side? Or is this a problem with the GTK3 SSD implementation?

(In reply to Kyle Devir from comment #13)
> Is there a solution to make MyPaint and the like have decorations, CSD or
> SSD, on the KWin side? Or is this a problem with the GTK3 SSD implementation?

That's a problem with gtk. From KWin side we cannot do anything. If the app doesn't use the protocol we have no way to know what it wants.

Window rules could help, but are not yet fully implemented.

From the investigation so far it looks like there is no bug in KWin. Setting to INVALID. If you find new data in opposite to the current finding: please reopen.

Thanks Martin,

When GTK3 requests SSD, GTK3 should be dropping the remaining CSD for Evince and others, allowing an SSD provider to do their own decorations. This is a GTK3 bug, I believe. Without said bug, the SSD should work properly, instead of being buggy and weird.

However, for MyPaint and such, because SSDs are being requested, KWin should be providing SSD. When it requests CSD, leaving it undecorated is the right thing to do, however, as you explained. This bug is weirder than the first one, because I'm not so sure it's a GTK3 bug.

Why isn't KWin also providing SSD for MyPaint and such, as it does for Evince and others, in spite of the CSD shown in the latter?

Reopened, because this bug relates to GTK3 apps explicitly requesting SSD, but acting weirdly on KWin.

MyPaint isn't requesting ssd according to the debug output

(In reply to Martin Flöser from comment #18)
> MyPaint isn't requesting ssd according to the debug output

My debug output? Or yours?

GTK3 needs a patch to force SSD, because their implementation prefers SSD, but their codepath always ends up erroneously selecting CSD, when it shouldn't be.

Even when requesting SSD, with my patch, MyPaint never gets any SSD, which confuses me.

The debug output from comment #4 shows that MyPaint does not request ssd.

Relevant part:
[2138199.962]  -> wl_shm@6.create_pool(new id wl_shm_pool@18, fd 6, 2304)
[2138199.979]  -> wl_shm_pool@18.create_buffer(new id wl_buffer@14, 0, 24, 24, 96, 0)
INFO: gui.device: New device 'Wayland Pointer' (GDK_SOURCE_MOUSE, axes:2, class=GdkWaylandDevice, vendor=None, product=None)
INFO: gui.document: Initialized background from u'/usr/share/mypaint/backgrounds/10_soft_yellow.png'
[2138295.671]  -> wl_compositor@4.create_surface(new id wl_surface@22)
WARNING: gui.keyboard: Ignoring keybinding for '<Actions>/BrushModifierActions/BlendModeMenu'

(mypaint:25349): Gtk-WARNING **: Theme parsing error: <data>:5:50: The style property GtkMenuBar:internal-padding is deprecated and shouldn't be used anymore. It will be removed in a future version
[2138394.052]  -> wl_shm@6.create_pool(new id wl_shm_pool@23, fd 16, 1024)
[2138394.068]  -> wl_shm_pool@23.create_buffer(new id wl_buffer@24, 0, 16, 16, 64, 0)
[2138400.007]  -> zxdg_shell_v6@5.get_xdg_surface(new id zxdg_surface_v6@25, wl_surface@22)
[2138400.017]  -> zxdg_surface_v6@25.get_toplevel(new id zxdg_toplevel_v6@26)
[2138400.021]  -> zxdg_toplevel_v6@26.set_parent(nil)
[2138400.024]  -> zxdg_toplevel_v6@26.set_title("MyPaint")
[2138400.027]  -> zxdg_toplevel_v6@26.set_app_id("mypaint")
[2138400.029]  -> wl_surface@22.commit()

You can check the wl_surface@22 - no decoration requested.

*** Bug 390156 has been marked as a duplicate of this bug. ***

Created attachment 110585 [details]
LibreOffice Debug Output

I don't have window decorations anymore with VirtManager and LibreOffice since Plasma 5.12.

I'm now setting this bug back to invalid. Also the debug output from libreoffice shows that no decorations are requested. KWin is correct, the bug is in the toolkit.

*** Bug 390604 has been marked as a duplicate of this bug. ***

Reopening. It looks like my implementation does not match my documentation.

(In reply to Martin Flöser from comment #25)
> Reopening. It looks like my implementation does not match my documentation.

No, I'm wrong. The implementation behaves correctly (just wrote a test case for it). Re-read the debug output: gtk never requests a decoration

Setting back to invalid. Did anyone report this to GTK?

(In reply to Martin Flöser from comment #27)
> Setting back to invalid. Did anyone report this to GTK?

Reopening. WAYLAND_DEBUG says for me:

[1643531,857] org_kde_kwin_server_decoration_manager@15.default_mode(2)
[1643531,884] wl_output@17.geometry(0, 0, 269, 202, 0, "org.kde.kwin", "none", 0)
[1643531,959] wl_output@17.scale(1)
[1643531,980] wl_output@17.mode(1, 1024, 768, 60000)
[1643532,015] wl_output@17.done()
[1643532,038] wl_callback@18.done(101)
[1643657,974]  -> wl_compositor@4.create_surface(new id wl_surface@18)
Gtk-Message: GtkDialog mapped without a transient parent. This is discouraged.
[1643658,216]  -> wl_compositor@4.create_surface(new id wl_surface@14)
[1643658,582]  -> zxdg_shell_v6@5.get_xdg_surface(new id zxdg_surface_v6@22, wl_surface@18)
[1643658,592]  -> zxdg_surface_v6@22.get_toplevel(new id zxdg_toplevel_v6@23)
[1643658,599]  -> zxdg_toplevel_v6@23.set_parent(nil)
[1643658,603]  -> zxdg_toplevel_v6@23.set_title("gtk3_preview")
[1643658,607]  -> zxdg_toplevel_v6@23.set_app_id("gtk3_preview")
[1643658,612]  -> wl_surface@18.commit()

default_mode(2) means SSD, the zxdg_toplevel is created after that.

No, no. That is not how the protocol works. Default mode is sent by KWin. It is the state of a declaration till the declaration requests another mode. But no decoration is created. The request from client to server to create a decoration for the surface is just missing.

(In reply to Martin Flöser from comment #29)
> No, no. That is not how the protocol works. Default mode is sent by KWin. It
> is the state of a declaration till the declaration requests another mode.
> But no decoration is created. The request from client to server to create a
> decoration for the surface is just missing.

I see. The code totally ignores the important part of the protocol:

            If the client does not create a server-side decoration object for
            a surface the server interprets this as lack of support for this
            protocol and considers it as client-side decorated. Nevertheless a
            client-side decorated surface should use this protocol to indicate
            to the server that it does not want a server-side deco.

https://github.com/GNOME/gtk/blob/c2531b7ff2069d34f34025b17247389d7838cbb7/gdk/wayland/gdkdisplay-wayland.c#L341

(In reply to Fabian Vogt from comment #30)
> (In reply to Martin Flöser from comment #29)
> > No, no. That is not how the protocol works. Default mode is sent by KWin. It
> > is the state of a declaration till the declaration requests another mode.
> > But no decoration is created. The request from client to server to create a
> > decoration for the surface is just missing.
> 
> I see. The code totally ignores the important part of the protocol:
> 
>             If the client does not create a server-side decoration object for
>             a surface the server interprets this as lack of support for this
>             protocol and considers it as client-side decorated. Nevertheless
> a
>             client-side decorated surface should use this protocol to
> indicate
>             to the server that it does not want a server-side deco.
> 
> https://github.com/GNOME/gtk/blob/c2531b7ff2069d34f34025b17247389d7838cbb7/
> gdk/wayland/gdkdisplay-wayland.c#L341

I added a comment on the GNOME bugzilla: https://bugzilla.gnome.org/show_bug.cgi?id=792889#c28

From GTK bugzilla:

> This bug is obsolete anyway - we've proposed an updated protocol for standardization. You can expect a patch for that fairly soon.

Urgh... why not just fix the original bug and backport it for the time being...? :(

Thoughts, Martin? Apparently, David Edmundson has had some involvement, so that's nice. :)

https://lists.freedesktop.org/archives/wayland-devel/2018-February/037119.html

David is taking care of it, I'm keeping myself out of the discussion.

Created attachment 110928 [details]
GTK3 SSD fix patch

This patch fixes the issue on the GTK3 end, but they actually have to give a shit about it, to put it bluntly, because this bug isn't obsolete the new protocol under discussion is actually fully and properly implemented by all involved parties.

Created attachment 110929 [details]
Screenshot demonstrating applications with patch

This is what the applications look like with this working fix, which has taken far longer to resolve than I would have liked... :/

Better late than never, I guess...

Created attachment 110930 [details]
Screenshot demonstrating applications with patch

This is what the applications look like with this working fix, which has taken far longer to resolve than I would have liked... :/

Better late than never, I guess...

*** Bug 390989 has been marked as a duplicate of this bug. ***

*** Bug 395271 has been marked as a duplicate of this bug. ***

*** Bug 395104 has been marked as a duplicate of this bug. ***

Fixed in GTK 3.24

(Fixed upstream with https://gitlab.gnome.org/GNOME/gtk/commit/927004178f17ffabac42c75009c5ea0d8c601527)

Thanks David!