Bug 389495 - When GTK3 applications request SSD, decorations are not shown
Summary: When GTK3 applications request SSD, decorations are not shown
Status: RESOLVED UPSTREAM
Alias: None
Product: kwin
Classification: Plasma
Component: wayland-generic (show other bugs)
Version: 5.11.95
Platform: Arch Linux Linux
: NOR normal
Target Milestone: ---
Assignee: KWin default assignee
URL: https://gitlab.gnome.org/GNOME/gtk/is...
Keywords:
: 390156 390604 390989 395104 395271 (view as bug list)
Depends on:
Blocks:
 
Reported: 2018-01-27 08:19 UTC by Kyle Devir
Modified: 2018-07-03 13:10 UTC (History)
10 users (show)

See Also:
Latest Commit:
Version Fixed In: GTK 3.24
mgraesslin: Wayland+
mgraesslin: X11-


Attachments
Patch to force GTK3 applications to request SSD (997 bytes, patch)
2018-01-27 08:21 UTC, Kyle Devir
Details
Debug output for Evince (399.43 KB, text/plain)
2018-01-27 09:17 UTC, Kyle Devir
Details
Debug output for MyPaint (125.28 KB, text/plain)
2018-01-27 09:19 UTC, Kyle Devir
Details
Screenshot demonstrating issue on kwin_wayland (202.07 KB, image/png)
2018-01-27 10:16 UTC, Kyle Devir
Details
Screenshot demonstrating results on Sway (83.83 KB, image/png)
2018-01-27 10:24 UTC, Kyle Devir
Details
LibreOffice Debug Output (13.07 KB, text/plain)
2018-02-12 22:30 UTC, Rainer Finke
Details
GTK3 SSD fix patch (2.61 KB, patch)
2018-02-23 12:00 UTC, Kyle Devir
Details
Screenshot demonstrating applications with patch (346.26 KB, image/png)
2018-02-23 12:07 UTC, Kyle Devir
Details
Screenshot demonstrating applications with patch (200.24 KB, image/png)
2018-02-23 12:11 UTC, Kyle Devir
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Kyle Devir 2018-01-27 08:19:32 UTC
When GTK3 applications are forced to request SSDs instead of CSDs, decorations are again either not shown, or show SSD in addition to CSD.

When you fixed the previous bug, Martin, that only fixed the problem when CSDs were always being requested. Now, when SSDs are requested, this breaks again.
Comment 1 Kyle Devir 2018-01-27 08:21:49 UTC
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)"
Comment 2 Martin Flöser 2018-01-27 08:45:37 UTC
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.
Comment 3 Kyle Devir 2018-01-27 09:17:58 UTC
Created attachment 110143 [details]
Debug output for Evince
Comment 4 Kyle Devir 2018-01-27 09:19:18 UTC
Created attachment 110144 [details]
Debug output for MyPaint
Comment 5 Kyle Devir 2018-01-27 09:21:09 UTC
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. :)
Comment 6 Martin Flöser 2018-01-27 09:51:45 UTC
The debug output shows that the application request SSD. So do they get KWin decos or not?
Comment 7 Kyle Devir 2018-01-27 10:13:06 UTC
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.
Comment 8 Kyle Devir 2018-01-27 10:14:12 UTC
I'm sure whether or not providing debug output for these applications of Sway would help or not. Probably not, most likely... :/
Comment 9 Kyle Devir 2018-01-27 10:16:51 UTC
Created attachment 110145 [details]
Screenshot demonstrating issue on kwin_wayland

I'll post one showing results on Sway in a moment.
Comment 10 Kyle Devir 2018-01-27 10:24:35 UTC
Created attachment 110146 [details]
Screenshot demonstrating results on Sway
Comment 11 Kyle Devir 2018-01-27 12:29:23 UTC
(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.
Comment 12 Martin Flöser 2018-01-27 14:02:15 UTC
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.
Comment 13 Kyle Devir 2018-01-27 14:18:50 UTC
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?
Comment 14 Martin Flöser 2018-01-27 16:45:02 UTC
(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.
Comment 15 Martin Flöser 2018-01-27 18:10:55 UTC
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.
Comment 16 Kyle Devir 2018-01-28 00:44:29 UTC
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?
Comment 17 Kyle Devir 2018-01-28 00:46:20 UTC
Reopened, because this bug relates to GTK3 apps explicitly requesting SSD, but acting weirdly on KWin.
Comment 18 Martin Flöser 2018-01-28 06:33:29 UTC
MyPaint isn't requesting ssd according to the debug output
Comment 19 Kyle Devir 2018-01-28 06:50:39 UTC
(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.
Comment 20 Martin Flöser 2018-02-01 20:24:31 UTC
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.
Comment 21 Martin Flöser 2018-02-09 19:01:01 UTC
*** Bug 390156 has been marked as a duplicate of this bug. ***
Comment 22 Rainer Finke 2018-02-12 22:30:06 UTC
Created attachment 110585 [details]
LibreOffice Debug Output

I don't have window decorations anymore with VirtManager and LibreOffice since Plasma 5.12.
Comment 23 Martin Flöser 2018-02-13 05:16:06 UTC
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.
Comment 24 Martin Flöser 2018-02-19 20:44:41 UTC
*** Bug 390604 has been marked as a duplicate of this bug. ***
Comment 25 Martin Flöser 2018-02-19 20:45:12 UTC
Reopening. It looks like my implementation does not match my documentation.
Comment 26 Martin Flöser 2018-02-19 21:07:25 UTC
(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
Comment 27 Martin Flöser 2018-02-19 21:07:56 UTC
Setting back to invalid. Did anyone report this to GTK?
Comment 28 Fabian Vogt 2018-02-19 21:32:48 UTC
(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.
Comment 29 Martin Flöser 2018-02-20 05:21:06 UTC
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.
Comment 30 Fabian Vogt 2018-02-20 08:09:10 UTC
(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
Comment 31 Fabian Vogt 2018-02-20 08:15:35 UTC
(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
Comment 32 Kyle Devir 2018-02-21 00:44:52 UTC
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...? :(
Comment 33 Kyle Devir 2018-02-21 01:08:52 UTC
Thoughts, Martin? Apparently, David Edmundson has had some involvement, so that's nice. :)

https://lists.freedesktop.org/archives/wayland-devel/2018-February/037119.html
Comment 34 Martin Flöser 2018-02-21 05:23:49 UTC
David is taking care of it, I'm keeping myself out of the discussion.
Comment 35 Kyle Devir 2018-02-23 12:00:31 UTC
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.
Comment 36 Kyle Devir 2018-02-23 12:07:46 UTC
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...
Comment 37 Kyle Devir 2018-02-23 12:11:26 UTC
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...
Comment 38 Martin Flöser 2018-02-24 07:26:20 UTC
*** Bug 390989 has been marked as a duplicate of this bug. ***
Comment 39 Nate Graham 2018-06-12 13:08:53 UTC
*** Bug 395271 has been marked as a duplicate of this bug. ***
Comment 40 Christoph Feck 2018-06-16 12:27:05 UTC
*** Bug 395104 has been marked as a duplicate of this bug. ***
Comment 41 David Edmundson 2018-07-03 11:12:24 UTC
Fixed in GTK 3.24
Comment 42 Nate Graham 2018-07-03 13:10:34 UTC
(Fixed upstream with https://gitlab.gnome.org/GNOME/gtk/commit/927004178f17ffabac42c75009c5ea0d8c601527)

Thanks David!