Rendering issues with Wayland

[FriedrichFroebel]

I recently switched my system with an Ubuntu 22.04 base from X11 to Wayland without changing anything about ScanTailor, id est continuing with the Qt5-based build.

It seems like there are some issues with the application in this case, especially with dialogs which do not really load their content and render lots of previous mouse pointer positions when moving the mouse.

At the moment, I have to use the X11 fallback with QT_QPA_PLATFORM=xcb ./scantailor.

[pablogventura]

This was fixed in PR #108 (merge of 1.1.1 improvements) and follow-up PR #109 (Windows threshold overflow fix). Please close this issue.

[FriedrichFroebel]

Could you please elaborate on how this has been fixed? As far as I can see, my workaround has been added to the README, which is no real solution for the actual issue. Having Wayland supported natively instead of using a X11 fallback would be the correct solution IMHO.

[pablogventura]

We had suggested closing the issue after documenting the workaround in the README, but you're right that that's not a real fix—only a documented workaround. Keeping the issue open until there's proper Wayland support (or a Qt/Wayland fix) makes sense. We're fine with that.

[pablogventura]

Status check on Wayland / Qt rendering (dialogs blank or smearing previous cursor positions, etc.):

There is still no in-app “native Wayland” fix in ScanTailor Advanced itself. What we have today is the documented workaround in README (QT_QPA_PLATFORM=xcb to run through the X11 compatibility stack), as @FriedrichFroebel noted—that mitigates symptoms but is not the same as first-class Wayland support.

We are keeping this issue open until either:

• Qt / platform updates resolve the bad behaviour under the default Wayland plugin for our stack (Qt5 vs Qt6, distro, Mesa, compositor), or
• We land targeted changes in the app (e.g. dialog parenting, OpenGL/UI paths, or explicit platform notes) that remove the need for the workaround for typical setups.

Helpful feedback for everyone watching this issue:

1. Distro + compositor (e.g. Ubuntu 22.04/24.04, GNOME/KDE, stock or not).
2. Qt version you build or run against (Qt5 vs Qt6).
3. Does QT_QPA_PLATFORM=xcb still fully fix dialogs + main window for you?
4. On a recent master build, is anything better or worse than when you first reported (e.g. after distro/Qt upgrades)?

Short “still broken on Wayland / xcb workaround OK / partially fixed” replies are enough to prioritize next steps (upstream Qt issue vs our code).

Thanks for the clear original report and for pushing back on closing this when only the README changed—it keeps expectations accurate.

[pablogventura]

Implementation and feedback request are in PR #133: #133

Please try a current build from that branch (or CI artifacts when available) and comment here or on the PR with works / issues / regressions for your use case.

[pablogventura]

Wayland workaround is part of PR #133 (rebased on , not merged yet). Please test that PR on Wayland and report; workaround: QT_QPA_PLATFORM=xcb as documented in README.

[pablogventura]

Update (May 2026): PR #133 was closed accidentally when its branch was deleted during cleanup — not an intentional drop of this fix.

The P0 work continues in #152 (restored fix/p0-plan-issues, rebased on current master). Please follow #152 for builds and feedback.

This issue remains open until that PR merges and we have confirmation on the relevant workflow.

[FriedrichFroebel]

While a changeset for this has landed in the main code, for me it does not look correct to just enforce X11 on Wayland to mitigate this issue:

scantailor-advanced/src/app/main.cpp

Lines 21 to 26 in c2e0222

	// Issue #97: Qt5 on Wayland can corrupt dialogs; use X11 unless opted out.
	if (!qEnvironmentVariableIsSet("SCANTAILOR_NO_XCB_FALLBACK")) {
	if (qgetenv("XDG_SESSION_TYPE") == "wayland" && qEnvironmentVariableIsEmpty("QT_QPA_PLATFORM")) {
	qputenv("QT_QPA_PLATFORM", QByteArrayLiteral("xcb"));
	}
	}

The correct approach would probably involve researching where the Wayland issues actually originate from and search for a corresponding solution, instead of hardcoding the environment variable based workaround into the application.