Most of the compatibility work in this build's KDE packages involves code that compiles fine but never actually runs — dead paths behind a runtime check that always evaluates false. This one is different: two small helper programs that don't compile at all, because the graphics toolkit underneath them was never built with the one feature they need.
What the helpers are for
KDE's "About This System" panel — kinfocenter's own overview of installed hardware and drivers — launches two small, standalone executables out-of-process to gather GPU driver details: an OpenGL helper and a Vulkan helper. Running these as separate processes rather than querying the graphics stack directly from inside the main application is a deliberate isolation choice; a GPU driver that crashes or hangs while being queried takes down a small disposable helper process instead of the whole System Settings window.
Where the build actually stops
The Vulkan helper's source uses real, live Qt6Gui classes — QVulkanInstance, QVulkanFunctions — directly, not behind any feature-detection guard. Those classes exist in Qt6's public API regardless of how any particular build of Qt6 was configured; what doesn't necessarily exist is the actual Vulkan backend implementation behind them, and this build's Qt6 was never configured with Vulkan support turned on in the first place. The result isn't a runtime failure or a silently-disabled feature — it's a straightforward compile error, the helper failing to build at all, discovered the same way any other missing-dependency compile failure is discovered.
Why this doesn't fit the usual pattern in this build
Elsewhere in this project, a missing feature usually shows up as code that compiles cleanly because the checks protecting it (a preprocessor guard, a runtime platform check) report false and skip the actual feature-specific calls entirely — real, working code, just never reached. This is the opposite shape: the code isn't behind any check at all, because from the perspective of whoever wrote it, there was no reason to expect QVulkanInstance not to work — it's part of Qt6's normal public interface, not an optional add-on a caller is expected to check for before using. The unavailability lives one layer down, in how this specific Qt6 build was configured, somewhere the helper's own source code has no way to see or guard against.
The actual fix, and the one not taken
The two helpers — OpenGL and Vulkan — were patched out of the build entirely rather than reconfiguring Qt6 to add Vulkan support. That's not the "fix Qt6 properly" answer, and it isn't meant to be: Qt6 sits at the bottom of this build's entire KDE Frameworks and Plasma dependency chain, so a real Vulkan-enabled Qt6 rebuild would cascade into rebuilding the same roughly 150-package downstream stack that any other change to Qt6's configuration does elsewhere in this project. Losing one small diagnostic panel in "About This System" is a real, accepted loss — but a bounded one, weighed directly against the cost of redoing a foundational package for a feature nothing else in this desktop actually needs.
The distinction worth keeping
Not every gap in a from-scratch build is dead code waiting to be proven unreachable and stripped out. Some gaps are real capabilities that were simply never built, and the honest fix isn't a patch that makes the symptom go away — it's deciding, explicitly, that the thing on the other side of the gap isn't worth building for the one small feature that needs it.