xpra icon
Bug tracker and wiki

Opened 3 weeks ago

Closed 6 days ago

Last modified 6 days ago

#1925 closed defect (fixed)

python3 / gtk3 client crashes under wayland

Reported by: Antoine Martin Owned by: Antoine Martin
Priority: critical Milestone: 2.4
Component: client Version: 2.3.x
Keywords: Cc:

Description

Thread 1 "python3" received signal SIGSEGV, Segmentation fault.
0x00007fffe4c9f936 in XDefaultRootWindow () from /lib64/libX11.so.6
...
(gdb) bt
#0  0x00007fffe4c9f936 in XDefaultRootWindow () at /lib64/libX11.so.6
#1  0x00007fffd2eba691 in __pyx_pf_4xpra_3x11_8bindings_15window_bindings_18_X11WindowBindings_4getDefaultRootWindow (__pyx_v_self=<optimized out>)
    at xpra/x11/bindings/window_bindings.c:3176
#2  0x00007fffd2eba691 in __pyx_pw_4xpra_3x11_8bindings_15window_bindings_18_X11WindowBindings_5getDefaultRootWindow (__pyx_v_self=<optimized out>, unused=<optimized out>) at xpra/x11/bindings/window_bindings.c:3155
..

According to https://bbs.archlinux.org/viewtopic.php?id=219796 this is a well known issues when running Gnome on Wayland. Discussed plenty of times

Change History (3)

comment:1 Changed 7 days ago by Antoine Martin

Status: newassigned

With r20066 + r20067, the GTK3 client no longer crashes under wayland, but this changeset turns off ALL the code which calls the X11 bindings:

  • no keymap probing
  • no system bell
  • no virtual desktops, desktop workarea or vrefresh detection
  • no xresources sync
  • limited clipboard support
  • no xinput2 devices
  • we get the window manager name from XDG_CURRENT_DESKTOP only
  • no dpi or colourspace detection
  • no opengl acceleration..

Some of those things will need to be replaced with native wayland API calls.

And even with these fixes, the forwarded window now lack decorations and rendering is a mess too.
The exact same code used to work fine, so they've broken something else. "stable" they say.. smh

comment:2 Changed 6 days ago by Antoine Martin

The decorations problem is caused by CSD (Client Side Decorations).
Why this is a terrible idea has been documented for a long time, ie: Why you should not use client-side window decorations…
Do a search on CSD and the number one thing people want to do with it is to turn it off.
That's why it is disabled by default on MSYS2: Disable client side decorations (GTK_CSD) by default on Windows (win32)

From Suboptimal window drawing on Windows:

  • the decoration drawing that the WM does will completely screw up alpha-channel in your client area, so no alpha-transparency - well that explains why I couldn't make it work: #1682
  • Firefox uses WS_EX_LAYERED and UpdateLayeredWindow?() for transparent windows (apparently, they have some transparent and some non-transparent windows), and yes, these remain unaccelerated, but have no glitches and working alpha-transparency. - that's exactly what I ended up doing too.
  • Old ATI GPUs wouldn't have worked even if they had well-working drivers and/or extensions, since they don't support OpenGL3 anyway (GTK requires at least OpenGL 3.0, prefers 3.2). and Intel HD don't work, yay GTK3..
  • It was also agreed that GTK3 was bad in terms of cross-platform compatibility - to put it mildly

KWin maintainer not happy about Gtk+ handling of CSD bugs: If you have to change your WM to support a new protocol to make things work, then it's clearly going to break everybody elses WM when you introduce this feature without warning. - exactly what happens here.

GTK3 CSD on gtk_window_resize() also counts client side decorations size - is why we end up painting at the wrong location, painting over the window decorations.

Client-Side Decorations Initiative
: depending on the app, this might still be a lot of work, because it requires redesigning significant portions of the app - not kidding

Introducing the CSD Initiative: The only way to solve this problem long-term is to patch applications upstream to not use title bars. So this is what we’ll have to do - nothing said about if we do want to use the title bars?

Time to drop GTK, at least under wayland?

Last edited 6 days ago by Antoine Martin (previous) (diff)

comment:3 Changed 6 days ago by Antoine Martin

Resolution: fixed
Status: assignedclosed

So, it turns out that what they've changed (in Fedora 28?) is the default GDK backend, now set to "wayland".
r20068 forces it back to "x11", so the GTK3 client works OK again (via X11), at least for now.
We also check for the backend using the native GDK API and disable all X11 calls if the backend is not the "x11" one.

Minimal backport: r20072 + r20073.

Last edited 6 days ago by Antoine Martin (previous) (diff)
Note: See TracTickets for help on using tickets.