Merge remote-tracking branch 'origin/main' into pr-fix-129

docs/PLATFORM_IDENTITY.md

@@ -164,3 +164,12 @@ keeps no identity of its own, so it reports the same values as IOKit, including
 override saved by this tool. A field the guest does not provide is left out.
 `python3 -m unittest tests.test_system_profiler` checks the output with stub
 commands.
+
+`SPDisplaysDataType` reads the host DRM cards. With `DARLING_METAL_MAC_GPU_NAME`
+set (the launcher default), an AMD or NVIDIA host card is reported as the
+`MacBookPro16,1` discrete GPU: `AMD Radeon Pro 5500M`, vendor `0x1002`, device
+`0x7340`, bus PCIe and VRAM from `DARLING_METAL_VRAM_MB` (4096 by default; a
+value that is not a positive decimal keeps the default). An Intel card is
+reported as `Intel UHD Graphics 630` on bus Built-In with shared memory, as
+`MTLDevice.name` does. This keeps the display report consistent with Metal;
+without the variable the host card is reported as-is.

docs/SETUP.md

@@ -196,7 +196,7 @@ The hand-off experiments (`metal-present-dispatch-wait`, `metal-deferred-blit` a
 | `/tmp/metal-skip-cpu-devices` | software Vulkan devices (lavapipe) are skipped while a hardware device exists |
 | `/tmp/metal-gpu` | diagnostic: selects the Vulkan device used for Metal by index or case-insensitive name substring instead of the loader's first device. The OpenGL context that presents does not follow it; see [hybrid laptops](TROUBLESHOOTING.md#hybrid-graphics-laptops-amdintel-igpu--nvidia). `METAL_INDIUM_GPU` is the environment equivalent; the file wins |
 | `/tmp/metal-all-devices` | a `VkDevice` is created for every supported Vulkan device, as before 2026-10-16. Without it only the selected device gets one; on a machine with lavapipe installed this also drops lavapipe's idle rasterizer threads |
-| `/tmp/metal-no-drawable-vram` | drawables of a layer with `framebufferOnly` off (League sets it off) go back to host-visible system RAM, as before 2026-10-16. Without the file they are allocated in GPU memory like `framebufferOnly` drawables; nothing maps drawable memory from the CPU. On the RX 6600 this gave about 20 FPS more in a practice-tool fight and the same FPS when idle, not yet measured in an ARAM. `/tmp/metal-device.log` shows `drawable-vram=on` and `storage=vram` |
+| `/tmp/metal-no-drawable-vram` | drawables of a layer with `framebufferOnly` off (League sets it off) go back to host-visible system RAM, as before 2026-10-16. Without the file they are allocated in GPU memory like `framebufferOnly` drawables; nothing maps drawable memory from the CPU. On the RX 6600 this gave about 20 FPS more in a practice-tool fight and the same FPS when idle, not yet measured in an ARAM. `/tmp/metal-device.log` (with `DARLING_METAL_DEVICE_LOG=1`) shows `drawable-vram=on` and `storage=vram` |
 | `/tmp/metal-no-lazy-wakeup` | every completion registration signals the event loop's wake-up semaphore from the CPU again, as before 2026-10-18. The handshake is per device. Without the file a registration signals only while the poller has announced a blocking wait (a spinning poller re-reads the registrations on its next pass, and its spin ends when one arrives). On the NVIDIA proprietary driver each `vkSignalSemaphore` is an RM control ioctl that waits on a driver-wide lock, about 0.3 ms each and ~25 per League frame, and it was the largest kernel cost of the submit worker. Re-read every 256 registrations; the wait log counts `wakeupSignalled` and `wakeupSkipped` |
 | `/tmp/metal-submit-batch-us` | the submit batch window in microseconds (500–100000, default 500); re-read every 256 checks, so it can be changed during a match. A presenting commit and every CPU wait still flush the batch at once. On the NVIDIA proprietary driver every `vkQueueSubmit2` is an RM control ioctl that waits on a driver-wide lock (about 0.4 ms each in a League match); with the default window a frame took about 8.5 submits, with `5000` about 2.5 (RTX 4090: 89 → 113 FPS, same match) |
 | `/tmp/metal-submit-batch-max` | command buffers per batch (1–256, default 16), re-read like the window; `64` lets one batch hold a whole frame |

docs/TROUBLESHOOTING.md

@@ -558,7 +558,7 @@ The guest file `/tmp/metal-gpu` (a device index or part of its name, for example
 
 ### Check which GPU rendered
 
-Each process that uses Metal appends to guest `/tmp/metal-device.log` (host `~/.darling/private/tmp/metal-device.log`): every Vulkan device the loader reported, the selected one and why, and the renderer of the presenting OpenGL context with both device UUIDs:
+With `DARLING_METAL_DEVICE_LOG=1` in the launcher environment, each process that uses Metal appends to guest `/tmp/metal-device.log` (host `~/.darling/private/tmp/metal-device.log`): every Vulkan device the loader reported, the selected one and why, and the renderer of the presenting OpenGL context with both device UUIDs. The log is off by default because the guest can read it and it names the host GPU:
 
 ```
 [MetalDevice] pid=… physical name="NVIDIA GeForce RTX 3060 Laptop GPU" type=discrete vendorID=0x10de … supported=yes
@@ -767,3 +767,36 @@ install the QuartzCore and OpenGL changes. Until updated, disable in-game
 VSync to use the game's frame cap, as the issue reporter confirmed. Physical
 scanout timing still depends on the driver and desktop compositor; the fix
 has standalone regression coverage but needs an in-game timing retest.
+
+## Installer aborts on `/proc/<pid>/fdinfo`
+
+[Issue #38](https://github.com/lucannez64/darling-lol/issues/38) reports an
+uncaught `ghc::filesystem::filesystem_error` with `Permission denied` on
+`/proc/<pid>/fdinfo`. `ghc::filesystem` is a C++ filesystem library, not evidence
+that the Riot installer is written in Haskell.
+
+An independent guest/native Vulkan probe reproduced this exact exception with
+MangoHud 0.8.4 enabled on 2026-10-18. MangoHud's `GPU_fdinfo::find_fd()` builds
+`/proc/<getpid()>/fdinfo` and uses a throwing directory iterator. Inside Darling,
+the native library's PID is in the guest PID namespace while its native `/proc`
+view can still refer to host processes: the probe's native PID 35 resolved to an
+inaccessible host process. The same probe completed Vulkan instance, device and
+swapchain creation with MangoHud disabled. This does not establish the cause of
+every installer abort; confirmation from the original reporter remains pending.
+
+The normal launcher now unsets `MANGOHUD` and exports `DISABLE_MANGOHUD=1` before
+runtime helpers start, including first-time installation. This disables inherited
+implicit MangoHud activation for the launched session without changing the host
+configuration. Do not wrap the launcher in `mangohud` or explicitly force its
+Vulkan layer. Updating these launcher scripts needs no Darling rebuild. For an
+older checkout, use:
+
+```sh
+env -u MANGOHUD DISABLE_MANGOHUD=1 ./scripts/installer.sh euw
+```
+
+Do not run the installer as root or change `/proc` permissions. If it still
+fails, include the exception and whether a host overlay was enabled; redact
+account tokens from logs.
+
+Upstream source: [MangoHud 0.8.4 fdinfo scan](https://github.com/flightlessmango/MangoHud/blob/v0.8.4/src/gpu_fdinfo.cpp#L9).