riverwm
Border not updated on tag toggle (qt)
Disclaimer
I'm running nvidia with open source drivers, so that might be a factor.
Steps to reproduce
Open a Qt5 app (I tried qutebrowser, Discover, and Dolphin) on tag 1, and another app (doesn't matter what) on tag 2.
- Start with tag 1 activated.
- Toggle tag 2 so that both 1 and 2 are activated.
- Toggle back tag 1 so that only 2 is activated (doesn't matter if you toggle 1 or set focused to 2, works the same either way).
- Set focused tag to 1.
Outcome
I can actually confirm that the same thing is happening on my lemur laptop with intel gpu, so must be something else. Let me know if you have problems reproducing, I'll try to dig in to see what could be the common denominator between the two. Both are fedora 34 installations, for one, but not sure if that could play a role.
I wonder what backend plugin Qt is running here. Did you manually set QT_QPA_PLATFORM to anything?
Qutebrowser and other Qt apps works natively if you pass env variables to enable Wayland support, bugged border isn't river's problem but Qt apps running under X11/xwayland are broken outside KDE and have general problems with decorations provided by compositors and window managers like borders in this case.
There is env variables to remove CSD from all Qt programs and should help with this problem as well as setting wayland as backend.
There is env variables to remove CSD from all Qt programs and should help with this problem as well as setting wayland as backend.
This doesn't seem to be the case, I can reproduce with QT_QPA_PLATFORM=wayland qutebrowser
@ifreund tried setting the variable as well, and also still having the issue.
So after some investigation it looks like this is a QT bug. Here's the relevant WAYLAND_DEBUG=1 snippet from qutebrowser:
[1860693.742] [email protected](1019, 970, array)
[1860693.750] [email protected](82)
[1860693.754] [email protected](230034835)
[1860693.799] -> [email protected](new id wl_callback@32)
[1860693.818] -> [email protected]_region(new id wl_region@34)
[1860693.824] -> [email protected](50, 440, 1019, 970)
[1860693.833] -> [email protected]_opaque_region(wl_region@34)
[1860693.838] -> [email protected]()
[1860693.844] -> [email protected]_min_size(127, 40)
[1860693.851] -> [email protected]_max_size(0, 0)
[1860693.857] -> [email protected]_configure(82)
[1860696.167] -> [email protected]()
[1860696.192] -> [email protected]()
[1860696.224] -> [email protected]_pool(new id wl_shm_pool@33, fd 93, 3953720)
[1860696.234] -> [email protected]_buffer(new id wl_buffer@38, 0, 1019, 970, 4076, 0)
[1860699.328] [email protected]()
[1860699.347] -> [email protected]()
[1860699.352] [email protected](72)
[1860700.273] -> [email protected](new id wl_callback@20)
[1860700.303] -> [email protected]_params(new id zwp_linux_buffer_params_v1@37)
[1860700.325] -> [email protected](fd 94, 0, 0, 4096, 16777215, 4294967295)
[1860700.339] -> [email protected]_immed(new id wl_buffer@39, 1019, 970, 875713089, 0)
[1860700.351] -> [email protected]()
[1860700.355] -> [email protected](wl_buffer@39, 0, 0)
[1860700.363] -> [email protected](0, 0, 2147483647, 2147483647)
[1860700.374] -> [email protected]()
Note that river's configure telling qutebrowser use the size 1019x970 is received and a buffer of that size is attached to the surface and committed in response to it. The bug however is that QT fails to make an xdg_surface.set_window_geometry() request informing river of the new window geometry of the xdg toplevel.
Not sure if there's any reasonable way to work around this in river, I wonder if it is still present in QT 6.
Here's the full WAYLAND_DEBUG=1 log with two empty lines inserted to indicate the snippet above: out.log
@ifreund thanks for investigating. Is this something that should be reported to QT as a bug then?
@ifreund thanks for investigating. Is this something that should be reported to QT as a bug then?
Yes it should be, I intended to do so but wanted to check if it is still present in QT 6 first and haven't yet found the time.
