GNOME Bugzilla – Bug 792889
On kwin_wayland, non-CSD GTK3 applications started with GDK_BACKEND=wayland *always* request CSD when they shouldn't
Last modified: 2018-05-02 19:47:44 UTC
With the added support for GTK3 applications to prefer server-side decorations when detecting that they're running on KWin on Wayland, the expected behaviour is that they should be using server-side decorations, as per this commit and related, resolved bug report: https://github.com/GNOME/gtk/commit/1b279e3d4ac33ebd9a3925d1a388c28bd96232d5 https://bugzilla.gnome.org/show_bug.cgi?id=781909 However, the detection doesn't seem to be working. On the KDE side, I've made a bug report here: https://bugs.kde.org/show_bug.cgi?id=389361 According to the feedback from Martin, and my own subsequent testing, GTK3 applications are always asking for CSD, suggesting they're not seeing KWin being used as the Wayland environment.
Created attachment 367411 [details] GTK3 applications using GDK_BACKEND=wayland on kwin_wayland
Created attachment 367417 [details] [review] Fix Wayland decorations for KWin
Telling should_use_csd() to return whether the display_prefers_ssd() seems backwards, no? The problem here is that the SSD aren't getting added; forcing CSD means you have *some* directions, but presumably not the type you want.
Hmmmm... my patch enables the Gnome CSD decorations on KWin, but on Weston, the CSD decorations vanish completely. Was the original patch to implement support for KDE server-side decorations ever tested to see if it ever worked properly in all usecases?
https://github.com/GNOME/gtk/commit/1b279e3d4ac33ebd9a3925d1a388c28bd96232d5 contains a g_debug call that should tell you what the compositor prefers, what does it say when you run a gtk3 app in kwin? Set G_MESSAGES_DEBUG=all to see it.
It tells me that the application prefers server decorations, however the code never requests server decorations. If you read the code, only client decorations are ever requested, no matter what.
Created attachment 367474 [details] [review] Dirty hack to make GTK3 Wayland windows request SSD instead of CSD I created a dirty hack to force GTK3 windows request SSD instead.
Created attachment 367475 [details] GTK3 windows as displayed under kwin_wayland with my patch This is what the windows now look like with force-requested SSDs.
MyPaint with G_MESSAGES_DEBUG=all yields: (mypaint:15359): Gdk-DEBUG: Compositor prefers decoration mode 'server' However, MyPaint with WAYLAND_DEBUG=1 always yields: [1792615.196] -> org_kde_kwin_server_decoration@35.request_mode(1) The codepath at https://github.com/GNOME/gtk/commit/1b279e3d4ac33ebd9a3925d1a388c28bd96232d5 always seems to end up requesting CSD, even though it is set to preferring SSD. Shouldn't there be a codepath requesting SSD, somewhere?
It shouldn't have to explicitly request SSD since that's the compositor's default decoration mode, if I understand the protocol correctly? What's your workflow for debugging this? Are you testing this with stable kwin (5.11.5 for me)? I tested it quickly this morning and I had a hard time running any gtk3 application because of a xdg-shell mismatch.
I've been using the Plasma beta release 5.11.95,, which supports XDG-Shell v6 in full. Maybe I should have been more clear about this, instead of making a presumption I never thought about... As for the workflow, I've been playing around with the code, creating patches through git format-patch, recompiling gtk3 again and again to test different results. I don't know how patch the code reliably, because I don't understand the GTK3 codebase well enough. I did find that if I remove the code requesting client-side decorations, it falls back to the default preferred mode, which are server-side decorations. Requesting none, instead of client or server, just makes GTK3 use client-side decorations again.
The codepath *always* requests client-side decorations, instead of just falling back to the default preferred server settings. Preferring server-side settings does not seem to be sufficient.
I just tested this again on Sway and it worked as expected. I tested gtk-demos, nautilus, and lowriter; all worked correctly. The expected behavior is that gtk-demos use CSD and disable SSD, individual demos in gtk-demos use SSD and disable CSD, nautilus uses CSD and disables SSD, and lowriter uses SSD and disables CSD.
Created attachment 367548 [details] WAYLAND_DEBUG log of lowriter on Sway
Created attachment 367549 [details] WAYLAND_DEBUG log of gtk4-demo on Sway
I see... on kwin_wayland, MyPaint, LibreOffice, DarkTable and RawTherapee do not have SSD, but they seem to be request CSD from kwin_wayland regardless. From said applications, it is always invariably: [3347746.113] org_kde_kwin_server_decoration_manager@15.default_mode(2) ... [3349999.597] -> org_kde_kwin_server_decoration@32.request_mode(1) I noticed that in your LibreOffice log for Sway, that it never makes any requests. Why does this happen on kwin_wayland, then? Broken assumptions?
My understanding of the protocol is that once the client binds to the decoration manager, it will use the server advertised mode by default and will only send an event if it wants to use something else.
Curious... kwin_wayland must be doing something odd, then, if LibreOffice doesn't make CSD requests on Sway, but does on kwin_wayland. It's almost like... on kwin_wayland, your code is, for whatever reason, marking said applications' windows as always being priv->client_decorated, even though they're obviously not, thus always triggering gdk_wayland_window_announce_csd. But... that makes zero sense. WTF? :/
Not your code, specifically, sorry, but rather, GTK3 is, somewhere else.
An examination of the GTK3 code suggests that the application must set priv->client_decorated, but that still doesn't explain why the same GTK3 applications will request this on kwin_wayland, but not Sway. This is... confusing.
(In reply to Kyle De'Vir from comment #7) > Created attachment 367474 [details] [review] [review] > Dirty hack to make GTK3 Wayland windows request SSD instead of CSD > > I created a dirty hack to force GTK3 windows request SSD instead. This is only called from gtk_window_enable_csd(). The path to calling this requires that the client explictly request CSD (e.g. it has a headerbar it draws itself, containing title + widgets), or that the server prefer SSD by default. That is as intended. You might have to find a slightly older app which doesn't have a headerbar; as Drew suggested, gtk-demo would be a good start.
(In reply to Daniel Stone from comment #21) > or that the server prefer SSD by default. Doesn't this seem... backwards? Why should clients that don't provide their own headerbars request CSD on SSD-preferring compositors? Shouldn't they be requesting SSD instead? What's the logic here? > That is as intended. You might have to find a slightly older app which > doesn't have a headerbar; as Drew suggested, gtk-demo would be a good start. gtk3-demo renders its own headerbar, so CSD makes sense. gtk3-demo-application, however, doesn't, so SSD should be preferred, no? When I make clients that provide their own headerbars ask for SSD, kwin_wayland draws SSD as it should, but clients that do not provide such, get nothing. Does this suggest a kwin_wayland bug to you, Daniel? Sorry if I'm repeating myself so often, because I'm intensely frustrated trying to figure out what the solution is supposed to be.
(In reply to Kyle De'Vir from comment #22) > (In reply to Daniel Stone from comment #21) > > or that the server prefer SSD by default. > > Doesn't this seem... backwards? Why should clients that don't provide their > own headerbars request CSD on SSD-preferring compositors? Shouldn't they be > requesting SSD instead? What's the logic here? Yes, I misspoke. In this order: If the client demands CSD (e.g. has a headerbar), CSD will be used regardless of server preference. If the server prefers SSD and the client has not demanded CSD, SSD will be used. Else, CSD will be used. I don't know KWin or GTK+ well enough to answer your other questions, I'm afraid.
All good. I hope that Drew can help nail down whether this is a problem on the GTK3 side, somewhere, or not.
Sorry, what do you expect from me? So far as I can tell Sway and GTK+ are both behaving as expected.
Sorry, was just seeking confirmation, but my request didn't quite come out right. :/ Now to pursue this on this KWin side...
As a normal user of applications like Virt-Manager and LibreOffice I'm now affected by this bug as well. On Plasma 5.12 on Wayland with xdg shell v6 support the window decorations are gone.
(In reply to Drew DeVault from comment #25) > Sorry, what do you expect from me? So far as I can tell Sway and GTK+ are > both behaving as expected. GTK currently violates the decoration management protocol, which leads to the WM assuming that it uses CSD, but GTK assuming that it has SSD -> no decoration at all. The protocol says: 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. Which means that calling default_mode and getting SSD back is not enough, it needs to be followed by a request_mode(SSD) call.
This bug is obsolete anyway - we've proposed an updated protocol for standardization. You can expect a patch for that fairly soon.
Will this be backported to the current GTK3 releases? Is there anywhere we can read about the proposal? Mailing list?
Who knows if it'll be backported. https://lists.freedesktop.org/archives/wayland-devel/2018-February/037119.html
Drew, for the time being, could you create a patch which creates a server-side decoration, so that GTK3 apps run in KWin get their decorations? This should suffice until the new protocol is implemented on by everyone needs it.
Created attachment 368819 [details] [review] SSD fix patch
Here's another patch, for anyone who cares. Would be nice if it could be officially submitted, again, if anyone actually cares about this issue being resolved...
https://gitlab.gnome.org/GNOME/gtk/issues/205 may be a dupe of this Please, that's enough passive aggression about the lack of reviews; sadly, relevant reviewers' time is not infinite. Perhaps ask them on IRC or such, instead of just grumbling here.
Review of attachment 368819 [details] [review]: I can't judge if your changes fulfill the GTK Coding Guidelines. But I can confirm that it solves also my issues about missing window decorations (https://gitlab.gnome.org/GNOME/gtk/issues/205).
I'm using the patch for a while now, it doesn't seem to work reliably. Most windows have a decoration now, but some don't. It seems to be completely random.
(In reply to Fabian Vogt from comment #37) > Most > windows have a decoration now, but some don't. It seems to be completely > random. Are the affected applications change randomly (so, the app A have sometimes decorations and sometimes it misses the decorations) or does it depend on the application itself (and if the decorations are present or missing that behavior itself is the same over the time)?
(In reply to Markus Rathgeb from comment #38) > (In reply to Fabian Vogt from comment #37) > > Most > > windows have a decoration now, but some don't. It seems to be completely > > random. > > Are the affected applications change randomly (so, the app A have sometimes > decorations and sometimes it misses the decorations) or does it depend on > the application itself (and if the decorations are present or missing that > behavior itself is the same over the time)? I have to use virt-manager with GDK_BACKEND=wayland as gtk-vnc is broken on Xwayland (broken keymap, fix doesn't work for me). Without this patch no window has decorations. With this patch, only the first time the window for a virtual machine is opened it has decorations. Opening a VM window again results in missing decorations. 100% reproducible here. I can provide a WAYLAND_DEBUG dump if needed.
You are right, I can reproduce the same.
Using virt-manager the patch review comment of Fabian Vogt can be reproduced easily. After virt-manager has been started (GDK_BACKEND=wayland) you just need to open "something", close it and open it again. Something could be * an existing VM * new virtual machine dialog * file, add connection So, if "existing VM" is opened the first time the decorations exists (using the patch). If it is opened the second time the decorations are missing again. If you after that (using the same virt-manager window) open the new virtual machine dialog the first time, the decoration exists (using the patch). If you close that dialog and open it again it is missing. If you after that open the "file, add connection" dialog the first time (still using the same virt-manager window) the decorations are shown, the second time it is missing. I cannot judge if this identifies that the patch is not fully working or if this is another bug that perhaps exist on the other side (kwin). Kyle De'Vir, as you already created that great (for me) patch, can you try to reproduce?
-- GitLab Migration Automatic Message -- This bug has been migrated to GNOME's GitLab instance and has been closed from further activity. You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.gnome.org/GNOME/gtk/issues/1019.