Right Alt (keycode 108) was hard-coded as Mod5/AltGr. On layouts where it
is Mod1, the swallowed-release reconcile accepted Mod1 as held but rebuilt
the state with Mod5, so the guest could see Option and Function together.
Read the per-key masks from XGetModifierMapping (refreshed on
MappingNotify) and use them everywhere; the old table is the fallback for
unmapped keys. The probe now checks Right Alt against whichever mask the
backend reports.
Co-Authored-By: Claude Opus 5.5 <[email protected]>
The handler read a flag the caller wrote without synchronization, and
inferred "called inside the request" from whether the call had returned,
which misfires when the handler runs on another thread first. Compare the
handler's thread with the caller's instead and keep the shared results
atomic.
Co-Authored-By: Claude Opus 5.5 <[email protected]>
The handler read a flag the caller wrote without synchronization, and
inferred "called inside the request" from whether the call had returned,
which misfires when the handler runs on another thread first. Compare the
handler's thread with the caller's instead and keep the shared results
atomic.
Co-Authored-By: Claude Opus 5.5 <[email protected]>
GNOME's overview delivers the Super press to the game window, eats the
release and hands the keyboard back without a FocusOut. The backend kept
Command held, so every later key and click reached the game as a Command
shortcut until a real focus change reconciled it (issue #74).
Each key, button, motion and crossing event carries the server's modifier
state; release any modifier key we track as down whose modifier is missing
from it. Synthetic events from other clients are ignored.
Co-Authored-By: Claude Opus 5.5 <[email protected]>
GNOME's overview delivers the Super press to the game window, eats the
release and hands the keyboard back without a FocusOut. The backend kept
Command held, so every later key and click reached the game as a Command
shortcut until a real focus change reconciled it (issue #74).
Each key, button, motion and crossing event carries the server's modifier
state; release any modifier key we track as down whose modifier is missing
from it. Synthetic events from other clients are ignored.
Co-Authored-By: Claude Opus 5.5 <[email protected]>
Voice chat (Vivox) saw no capture device and Chromium was told mic
access was denied. Fixes for issue #75:
- AVCaptureDevice: audio is Authorized when CoreAudio has a default
input device; requestAccess answers asynchronously. Video stays Denied.
- PulseAudio input device reports 2 channels on input scope, 0 on output
(was copied from the output device).
- PulseAudio input stream: real sample/host timestamps, one device
buffer per IOProc call, holes as silence, IOProc errors no longer cork
the stream, record buffer attrs sized to the device buffer.
- AUHAL: two elements per scope like macOS, non-blocking
AudioUnitRender on bus 1 with planar support, device records in the
bus 1 format, input-only units route CurrentDevice/BufferFrameSize to
the input device, input start errors handled.
- New offline check tools/riot-audio-input-check.cpp.
Co-Authored-By: Claude Opus 5.5 <[email protected]>
Voice chat (Vivox) saw no capture device and Chromium was told mic
access was denied. Fixes for issue #75:
- AVCaptureDevice: audio is Authorized when CoreAudio has a default
input device; requestAccess answers asynchronously. Video stays Denied.
- PulseAudio input device reports 2 channels on input scope, 0 on output
(was copied from the output device).
- PulseAudio input stream: real sample/host timestamps, one device
buffer per IOProc call, holes as silence, IOProc errors no longer cork
the stream, record buffer attrs sized to the device buffer.
- AUHAL: two elements per scope like macOS, non-blocking
AudioUnitRender on bus 1 with planar support, device records in the
bus 1 format, input-only units route CurrentDevice/BufferFrameSize to
the input device, input start errors handled.
- New offline check tools/riot-audio-input-check.cpp.
Co-Authored-By: Claude Opus 5.5 <[email protected]>
A long patch or login can keep the League client closed for more than ten
minutes after launch; the helper then left before the first match.
Co-Authored-By: Claude Opus 5.5 <[email protected]>
A long patch or login can keep the League client closed for more than ten
minutes after launch; the helper then left before the first match.
Co-Authored-By: Claude Opus 5.5 <[email protected]>
Mesa derives its shader disk cache from $HOME. Inside the guest that is
/Users/<user>, which does not exist on the host filesystem, so Mesa could not
create the cache and disabled it, once per process:
Failed to create /Users/<user> for shader cache (Permission denied)---disabling
One launcher log contained 212 of those lines, and no shader compiled by one
process was reused by another process or by the next start: the client and the
game recompiled every shader on every launch, spending CPU at startup for no
gain.
Mesa is host code loaded into the guest and reads MESA_SHADER_CACHE_DIR verbatim,
so point it at a host directory; Mesa creates mesa_shader_cache/ (client and game
shaders) and radv_builtin_shaders/ below it. A non-empty value from the caller is
preserved, and a directory that cannot be created leaves the previous behaviour
instead of ending the launch.
Observed on a Radeon RX 550 with radv: no shader-cache failure after the change,
and 434 files / 5.6 MB written during one client start, still growing while the
client ran. The cache is reused from the second start on, which lowers the
client's CPU use while it starts; the startup-time gain itself has not been
measured separately.
Mesa derives its shader disk cache from $HOME. Inside the guest that is
/Users/<user>, which does not exist on the host filesystem, so Mesa could not
create the cache and disabled it, once per process:
Failed to create /Users/<user> for shader cache (Permission denied)---disabling
One launcher log contained 212 of those lines, and no shader compiled by one
process was reused by another process or by the next start: the client and the
game recompiled every shader on every launch, spending CPU at startup for no
gain.
Mesa is host code loaded into the guest and reads MESA_SHADER_CACHE_DIR verbatim,
so point it at a host directory; Mesa creates mesa_shader_cache/ (client and game
shaders) and radv_builtin_shaders/ below it. A non-empty value from the caller is
preserved, and a directory that cannot be created leaves the previous behaviour
instead of ending the launch.
Observed on a Radeon RX 550 with radv: no shader-cache failure after the change,
and 434 files / 5.6 MB written during one client start, still growing while the
client ran. The cache is reused from the second start on, which lowers the
client's CPU use while it starts; the startup-time gain itself has not been
measured separately.
The client does not come back properly after a match when its own "Close client
during game" option is enabled. The UI (LeagueClientUx and its helpers) is a
Chromium/CEF instance and, under Darling, the pre-match instance keeps running:
the client the backend starts when the match ends is a second CEF instance on the
same --user-data-dir, and its window never paints. Its DOM and audio work and the
window stays black; closing the client by hand during a match leaves the same
state for the same reason.
RCLOL_CLOSE_CLIENT_IN_GAME=1 opts in to closing that UI from the host, and only
while a match runs, so the client that appears afterwards is the only instance.
The UI also competes with the game for CPU: on a four-core host with a Radeon
RX 550 a practice match reported roughly 120 FPS with the UI running and roughly
180 FPS with it closed. This is not the helper-killing memory optimization the
RAM section warns against, and the Riot client, the League backend and the game
are never touched.
The helper fails closed. It attributes the game and the client to the launcher's
prefix through the loader's __mldr_sockpath, since guest processes do not carry
DPREFIX (checked on a live session). It never closes a client younger than 60
seconds (the one the backend starts after a match), preserves a process of
another installation or owner, acts only when the environment and the stat fields
can be read, gives up after three closes in one match, and leaves after ten
minutes without a client or a match. It is off by default.
Tests use fake /proc entries and mock every signal.
The client does not come back properly after a match when its own "Close client
during game" option is enabled. The UI (LeagueClientUx and its helpers) is a
Chromium/CEF instance and, under Darling, the pre-match instance keeps running:
the client the backend starts when the match ends is a second CEF instance on the
same --user-data-dir, and its window never paints. Its DOM and audio work and the
window stays black; closing the client by hand during a match leaves the same
state for the same reason.
RCLOL_CLOSE_CLIENT_IN_GAME=1 opts in to closing that UI from the host, and only
while a match runs, so the client that appears afterwards is the only instance.
The UI also competes with the game for CPU: on a four-core host with a Radeon
RX 550 a practice match reported roughly 120 FPS with the UI running and roughly
180 FPS with it closed. This is not the helper-killing memory optimization the
RAM section warns against, and the Riot client, the League backend and the game
are never touched.
The helper fails closed. It attributes the game and the client to the launcher's
prefix through the loader's __mldr_sockpath, since guest processes do not carry
DPREFIX (checked on a live session). It never closes a client younger than 60
seconds (the one the backend starts after a match), preserves a process of
another installation or owner, acts only when the environment and the stat fields
can be read, gives up after three closes in one match, and leaves after ten
minutes without a client or a match. It is off by default.
Tests use fake /proc entries and mock every signal.
Riot's splash screens draw on a black rectangle: LeagueClient's is a
borderless NSWindow with setOpaque:NO and a pattern-image background, the
Riot Client's an Electron BrowserWindow with transparent: true. X11Window
created every window with a 24-bit visual and -setOpaque: only stored the
flag, so there was no alpha channel.
A non-opaque window whose background can show through (alpha below 1, or a
pattern image) now gets the 32-bit ARGB visual. League's game window is
non-opaque on an opaque background and stays on the opaque visual, which
X11IsLeagueGameWindow also enforces. The X window exists before apps set
opacity and background, so the choice is checked again when the first
subwindow is created (layer subwindows inherit the visual) and before the
first map, and the window recreated while unmapped if it changed. Its
background is transparent instead of None, so no black frame shows before
the first draw. Its surface comes from an alpha EGL config for that visual
(CGLGetWindowWithAlpha) and its compositing context from the surface's
config (CGLCreateContextForWindow): NVIDIA refuses the default config on a
32-bit window, and no driver makes a context from it current on the alpha
surface. Without an alpha config the window falls back to the opaque
visual.
A translucent window above the normal level (Electron's alwaysOnTop
splash) is typed _NET_WM_WINDOW_TYPE_SPLASH with _NET_WM_STATE_ABOVE before
it is mapped: window managers float it and draw no frame around it.
Electron's level never arrived, though: CGWindowLevelForKey returned the
normal level for every key, and the SDK turns NSFloatingWindowLevel into a
call to it. It now returns the levels macOS does; Cocotron only stores
levels, so nothing else changes.
Riot's splash screens draw on a black rectangle: LeagueClient's is a
borderless NSWindow with setOpaque:NO and a pattern-image background, the
Riot Client's an Electron BrowserWindow with transparent: true. X11Window
created every window with a 24-bit visual and -setOpaque: only stored the
flag, so there was no alpha channel.
A non-opaque window whose background can show through (alpha below 1, or a
pattern image) now gets the 32-bit ARGB visual. League's game window is
non-opaque on an opaque background and stays on the opaque visual, which
X11IsLeagueGameWindow also enforces. The X window exists before apps set
opacity and background, so the choice is checked again when the first
subwindow is created (layer subwindows inherit the visual) and before the
first map, and the window recreated while unmapped if it changed. Its
background is transparent instead of None, so no black frame shows before
the first draw. Its surface comes from an alpha EGL config for that visual
(CGLGetWindowWithAlpha) and its compositing context from the surface's
config (CGLCreateContextForWindow): NVIDIA refuses the default config on a
32-bit window, and no driver makes a context from it current on the alpha
surface. Without an alpha config the window falls back to the opaque
visual.
A translucent window above the normal level (Electron's alwaysOnTop
splash) is typed _NET_WM_WINDOW_TYPE_SPLASH with _NET_WM_STATE_ABOVE before
it is mapped: window managers float it and draw no frame around it.
Electron's level never arrived, though: CGWindowLevelForKey returned the
normal level for every key, and the SDK turns NSFloatingWindowLevel into a
call to it. It now returns the levels macOS does; Cocotron only stores
levels, so nothing else changes.
Stage a cross-filesystem copy in a private directory instead of deleting a
pre-existing PATH.partial, reject destinations inside the overlay work
directory, save the new path before deleting the old prefix, and verify that
the target keeps user.* xattrs before and after copying. Add tests.
Co-Authored-By: Claude Sonnet 5.5 <[email protected]>
Stage a cross-filesystem copy in a private directory instead of deleting a
pre-existing PATH.partial, reject destinations inside the overlay work
directory, save the new path before deleting the old prefix, and verify that
the target keeps user.* xattrs before and after copying. Add tests.
Co-Authored-By: Claude Sonnet 5.5 <[email protected]>
The prefix holds the installed clients and game (about 40 GB). The Nix
launcher always exported DPREFIX=${DPREFIX:-~/.darling}, so the prefix saved
in build/config.json was never used and the only way to move it was an
environment variable in every launch context.
- The launcher uses DPREFIX if set, then the saved prefix, then ~/.darling.
- darling-lol --set-prefix PATH runs scripts/nix-prefix.py in the namespace,
whose root owns the prefix files, so cp -a keeps their owners and xattrs.
It renames the prefix when possible; across filesystems it copies to
PATH.partial and removes the old prefix and its overlay work directory
only after the copy completes. A PATH that already holds a Darling prefix
is used as it is. It refuses non-empty directories that are not prefixes,
nested paths and paths with commas or colons (overlayfs separators), then
saves the path with configure.py --prefix.
Co-Authored-By: Claude Opus 5.5 <[email protected]>
The prefix holds the installed clients and game (about 40 GB). The Nix
launcher always exported DPREFIX=${DPREFIX:-~/.darling}, so the prefix saved
in build/config.json was never used and the only way to move it was an
environment variable in every launch context.
- The launcher uses DPREFIX if set, then the saved prefix, then ~/.darling.
- darling-lol --set-prefix PATH runs scripts/nix-prefix.py in the namespace,
whose root owns the prefix files, so cp -a keeps their owners and xattrs.
It renames the prefix when possible; across filesystems it copies to
PATH.partial and removes the old prefix and its overlay work directory
only after the copy completes. A PATH that already holds a Darling prefix
is used as it is. It refuses non-empty directories that are not prefixes,
nested paths and paths with commas or colons (overlayfs separators), then
saves the path with configure.py --prefix.
Co-Authored-By: Claude Opus 5.5 <[email protected]>
The drag loop runs run loop sources and main queue blocks between moves,
and Chromium can tear down a web view or close a window there. Hold both
until the drag ends, after -draggedImage:endedAt:operation:.
The drag loop runs run loop sources and main queue blocks between moves,
and Chromium can tear down a web view or close a window there. Hold both
until the drag ends, after -draggedImage:endedAt:operation:.
