mirror of
https://github.com/alexbelgium/hassio-addons.git
synced 2026-08-20 11:57:19 +02:00
The GPU acceleration shipped in 2026.08.03 was not inert — it was what turned the GPU off. `--use-gl=angle --use-angle=gl-egl` forces Mesa's EGL X11 platform, which offers no window-capable EGLConfig under this Xvfb. The GPU process logged `gl_surface_egl.cc:262 No suitable EGL configs found`, abandoned GL, and was relaunched with `--use-gl=disabled` while every renderer got `--disable-gpu-compositing`. Chromium already renders on the GPU here with no flags at all: LSIO's Xvfb runs `-vfbdevice /dev/dri/renderD128`, so its GLX is backed by the real render node. The premise that Xvfb offers only an indirect/software path was wrong for this base image. Measured on a separate display, including at the production 15360x8640 screen — with the flags the GPU process loads libEGL_mesa and holds 1 fd on the render node; without them it loads the Mesa gallium megadriver over DRI3, holds 8, and no renderer carries --disable-gpu-compositing. claude-gpu-probe was not wrong about the hardware, it answered the wrong question: it exercised ANGLE's default GLX path, which works, so it passed while the flags it gated disabled the GPU. Removed with the gpu_acceleration option. Also fixes two other changes from the same release that never did anything: - max_resolution wrote MAX_RES into the s6 container_environment, but svc-xorg starts `#!/usr/bin/env bashio`, not with-contenv, and never reads it. Renaming the option to MAX_RES makes the add-on env layer inject it into every service run script, which is how DRINODE already reaches Xvfb. It ships with no default, so nothing changes until it is set: carrying over the old 1920x1080 default would have silently shrunk every existing desktop, since that value had never taken effect. Schema bounds each axis to 100-9999. - The amd64 driver install has never run in any release: guarded by `if [[ ]]` with no SHELL directive, so it runs under dash, which has no `[[` — condition false, RUN still exit 0. It is deleted rather than repaired, because it had nothing to add. Hardware GL already works without it, Mesa already comes from the LSIO base at a newer backports version, and intel-media-va-driver-non-free was installed live on the running add-on and changed nothing: VA-API failed identically to the free driver on both DRM nodes. That failure is below the add-on, in the host i915 stack. Co-authored-by: Claude Opus 5 <noreply@anthropic.com>