fix(iokitd): name the :0 fallback in the display probe and the log

iokitd opens DISPLAY and falls back to :0, but the env-check probe only asked
xdpyinfo for DISPLAY. It could warn on a host where iokitd still had a display,
or pass on :0 while DISPLAY was broken. The probe now tries :0 when DISPLAY is
unset or cannot be opened, and the one-line log names the fallback, so the
probe and the guest agree.

prepare.py --check-only validates all 31 patch entries with the new hunk;
iokitd rebuilds and carries the new message.

Signed-off-by: zero <zero@localhost>
This commit is contained in:
zero committed 2026-10-25 14:28:58 -06:00
1 parent 9a1a38b568
commit 33a5c48656
3 files changed
+18 -15

No files matched your search

+3 -3
View File
@@ -436,9 +436,9 @@ The installer adds a CarbonCore framework override and the matching absolute Cor
## `iokitd` restarts when the X display is not accessible
`DISPLAY` can name an X server that rejects the connection, which is what an unset or stale `XAUTHORITY` does on a server, over SSH, or in a `sudo` session that dropped the cookie. `iokitd` then has no Xlib display and previously still called into EGL with a null display, so the process faulted and launchd restarted it in a loop while `/tmp/lolsig.log` filled with frames ([#140](https://github.com/lucannez64/darling-lol/issues/140)).
`DISPLAY` can name an X server that rejects the connection, which is what an unset or stale `XAUTHORITY` does on a server, over SSH, or in a `sudo` session that dropped the cookie. `iokitd` opens `DISPLAY` and then falls back to `:0`, so the display is missing only when both fail. Previously it still called into EGL with a null display, so the process faulted and launchd restarted it in a loop while `/tmp/lolsig.log` filled with frames ([#140](https://github.com/lucannez64/darling-lol/issues/140)).
`iokitd` now checks the display before EGL. Without a usable display it prints one line (`iokitd: cannot open X display …; X11 surface acceleration disabled`) and keeps running, so `darling shell` starts instead of crash-looping. Surfaces then fail with `KERN_FAILURE`, which means the guest has no GPU rendering: export a cookie the user running Darling can read and start again, for example:
`iokitd` now checks the display before EGL. When neither `DISPLAY` nor the `:0` fallback can be opened it prints one line (`iokitd: cannot open X display … or its :0 fallback; X11 surface acceleration disabled`) and keeps running, so `darling shell` starts instead of crash-looping. Surfaces then fail with `KERN_FAILURE`, which means the guest has no GPU rendering: export a cookie the user running Darling can read and start again, for example:
```sh
export XAUTHORITY=/run/user/$(id -u)/xauth
@@ -446,7 +446,7 @@ export XAUTHORITY=/run/user/$(id -u)/xauth
XAUTHORITY=$(ls /var/run/sddm/* | head -1) DISPLAY=:0 EGL_PLATFORM=x11 darling shell echo hola
```
`bash tools/env-check.sh` now probes the display with `xdpyinfo` in the environment Darling inherits and warns when it cannot open it. That check is advisory: without X11/EGL the runtime still boots, but the game cannot render.
`bash tools/env-check.sh` now probes the display with `xdpyinfo` in the environment Darling inherits, tries the `:0` fallback that `iokitd` uses, and warns only when both fail. That check is advisory: without X11/EGL the runtime still boots, but the game cannot render.
## Blocky video or flickering startup logo