Graphical glitches with most GTK/Qt applications on Intel iGPU

[fbushstone]

Most GTK and Qt applications have graphical issues. I opened MultiMC, Badwolf with JS enabled, KeepassXC, and ScreenGrab in Velox and none of these applications displayed anything correctly. I'm a new Velox user and I am not sure if this is a bug in Velox or in swc itself. I'd really like to use Velox as my main window manager, at least on my non-Nvidia computer, but as long as this bug persists this will be impossible. Note- I am on a laptop with an Intel integrated graphics card.

I have also been testing various terminals. While the Wayland fork of st works pretty well, other terminal emulators have similar graphical errors (kitty, xterm, urxvt). I'm fairly certain that none of these have Wayland backends, so it might be an issue with xorg-xwayland? If I remember correctly swc still has XWayland support.

Maybe this has nothing to do with XWayland and more to do with the fact that Velox forces everything to open in tiled mode. However, on vanilla dwm everything works pretty smoothly.

Picture included for reference:

[michaelforney]

Thanks for providing the picture. Can you confirm whether or not the issue is exclusively with applications running over xwayland, or does it happen with others as well (i.e. gtk with native wayland, GDK_BACKEND=wayland)?

It looks a lot like the applications are rendering with a different tiling mode than is being used to present them. It could have something to do with drm format modifiers, which are used to communicate the tiling mode of buffers, and weren't around when swc and wld were initially written.

Can you try the following things to help me understand what's going on:

1. Launch with WLD_DRM_DUMB=1. This will force the software renderer and wl_shm, which uses linear tiling, so I expect this to work.
2. Rebuild swc with linux-dmabuf disabled by commenting out these lines:
   https://github.com/michaelforney/swc/blob/master/libswc/drm.c#L301-L304
   linux-dmabuf is the newer wayland protocol, replacing the old mesa-internal wl_drm. If it is not available, it might fall back to wl_drm and behave differently.

It would also be useful if you could grab wayland protocol logs from applications that do not render correctly (i.e. run them with WAYLAND_DEBUG=1).

[fbushstone]

I was able to get MultiMC, urxvt, kitty, screengrab (doesn't work because X only I think) to work. feh and other image viewers had been broken before and now they work. Only thing that still has problems is Badwolf, but Badwolf isn't a big project. I haven't tried step 2 but I will report back to see if other things like Minecraft and certain Steam games work once I have patched it back in.

[fbushstone]

It appears my title was misleading, in any case.
urxvt, kitty, and xterm aren't GTK or Qt and they had the same issue.
It appears that GTK applications behave better than pure X or Qt applications.

[fbushstone]

I have recompiled swc without dmabuf support. It doesn't seem to affect anything- export WLD_DRM_DUMB=1 does fix the glitchy graphics, however.

[fbushstone]

After testing Velox on a Nvidia system with Nouveau, it seems to work.
This must be a problem with Intel integrated graphics.

[fbushstone]

WLD_DRM_DUMB causes some pretty terrible performance with games.
I managed to fix QT applications with export QT_QPA_PLATFORM=wayland-egl. If I find any more fixes I'll update this thread.
Launch Chromium/Electron apps (e.g. Element)/Chromium Embedded (e.g. Steam) with chromium --enable-features=UseOzonePlatform --ozone-platform=wayland to solve it not wanting to open a display.

[michaelforney]

WLD_DRM_DUMB causes some pretty terrible performance with games.

Well of course. As I mentioned earlier, this forces wl_shm and disables all hardware acceleration. I didn't suggest this as a solution, but as way to diagnose the problem.

On my system with intel graphics, I run only wld-based applications, which seem to work. I suspect the problem is somehow a drm tiling mode miscommunication, either between mesa and wld, or something to do with Xwayland. I will try to do some testing some time this week to see if I can reproduce the issue. It could also be related to the intel GPU revision you are using.

I managed to fix QT applications with export QT_QPA_PLATFORM=wayland-egl. If I find any more fixes I'll update this thread.

I suspect this forces Qt to connect with wayland natively rather than using Xwayland.

Launch Chromium/Electron apps (e.g. Element)/Chromium Embedded (e.g. Steam) with chromium --enable-features=UseOzonePlatform --ozone-platform=wayland to solve it not wanting to open a display.

It'd be helpful if you could clarify what protocols and rendering methods these applications are using rather than listing the applications themselves. It makes a big difference whether it is using wld or mesa or wl_shm, and whether it is a native wayland application or is an X11 application running via Xwayland. This will help me identify the problem (i.e. is it exclusive to Xwayland, or are native wayland applications using mesa affected as well?)

[fbushstone]

Sorry for not getting back to this sooner- I'm not very familiar with Wayland from a technical level but I do have a vague understanding of it. How would I find out such info (and some Wayland compositor programming resources would also be helpful)?
Also, maybe I should make an issue on your wld repo and close this one instead.

[michaelforney]

I think the issue is that mesa is using the Y tiling mode, and wld currently only supports X tiling. I pushed a temporary fix to the intel-tiling branch of swc. That commit advertises only linear and X tiling modes over linux-dmabuf. Can you check whether this fixes the issue for you?

A proper fix is probably to either add support for Y-tiled buffers to wld's intel driver (I think this involves setting BCS_SWCTRL), or adding a function to wld to get a list of supported format modifiers.

How would I find out such info (and some Wayland compositor programming resources would also be helpful)?

You can get a wayland protocol log by running the application with WAYLAND_DEBUG=1. This will show the method the application is using to create buffers. If it doesn't do anything, it is probably an X11 application running through Xwayland.

[fbushstone]

So I tried the fix, and it didn't have any effect. I think I may have mentioned this earlier, but it is an X applications (xterm, rxvt, MultiMC, Chromium on XWayland) problem.