marfrit
cd25d02e01
build and publish packages / distcc-avahi-aarch64 (push) Successful in 31s
build and publish packages / lmcp-any (push) Successful in 6s
build and publish packages / lmcp-debian (push) Successful in 4s
build and publish packages / claude-his-any (push) Successful in 7s
build and publish packages / ffmpeg-v4l2-request-aarch64 (push) Successful in 12m29s
build and publish packages / claude-his-debian (push) Successful in 5s
Source-grep collapsed Phase 1+2 onto a single pass. KWin's own GL paths use GL_R8 correctly (gltexture.cpp:61, shadowitem.cpp:494). The glTexImage2D(GL_ALPHA) calls observed in the journal originate from Qt 6: - qtbase/src/opengl/qopengltextureglyphcache.cpp:111-117 — text glyph cache upload path. The #else branch (active when qtbase is built with QT_CONFIG(opengles2)) unconditionally uses GL_ALPHA, with no runtime check for ES context major version. Correct on ES 2.x; broken on ES 3.x where GL_ALPHA is no longer a valid glTexImage2D internalFormat. - qtbase/src/gui/rhi/qrhigles2.cpp:1373-1378 — Qt-Quick-RHI sibling. Same logic, gated only on caps.coreProfile, missing the ES≥3 case. - qtbase/src/opengl/qopengltextureuploader.cpp:253-257 — QImage→GL upload path; same shape. KWin runs an ES 3.2 context on Mali-G52 panfrost (RK3566), Qt picks GL_ALPHA, mesa returns GL_INVALID_VALUE, every dependent draw errors at level 0, the compositor's frame-callback path stalls. KWin is the visible victim because it's the compositor, but the bug is in Qt. KWIN_PIVOT.md rewritten: the patch series and packaging now target qt6-base-fourier instead of kwin-fourier. Three small hunks (~3 lines each), runtime-safe via existing caps.gles + caps.ctxMajor / surface format majorVersion checks. Upstream landing path: bugreports.qt.io + Gerrit change against qtbase dev branch.