Repository navigation
aarch64 Linux build + runtime: XLookupString mismatch, max_color_attachments limit, lib name #55
Description
Three blockers to build and run on this platform:
1. XLookupString type mismatch (build error)
error[E0308]: mismatched types
--> src/lib.rs:397:29
|
397 | buf.as_mut_ptr() as *mut i8,
| ^^^^^^^^^^ expected `*mut u8`, found `*mut i8`
native/linux/src/lib.rs:397 casts buf.as_mut_ptr() (which is *mut u8) to *mut i8, but on aarch64 Linux c_char = u8 (ARM C ABI defines char as unsigned). Rust 1.95+ on Fedora 42 correctly sets c_char per-target. The x11 crate's XLookupString takes *mut c_char = *mut u8 here, so the cast is wrong.
Fix: remove the as *mut i8 cast — just use buf.as_mut_ptr().
2. max_color_attachments: requested 8, allowed: 5 (runtime crash)
thread panicked at src/lib.rs:582 — Failed to create device:
RequestDeviceError { inner: Core(LimitsExceeded(FailedLimit {
name: "max_color_attachments", requested: 8, allowed: 5
}))}
This platform caps at 5 color attachments. wgpu::Limits::default() returns downlevel_defaults() which hardcodes max_color_attachments: 8. The engine uses Limits::default() at native/linux/src/lib.rs:565 as the base for required_limits instead of adapter.limits().
Fix: replace wgpu::Limits::default() with adapter.limits() — capping limits to what the adapter actually supports.
3. Cargo.toml lib name mismatch
native/linux/Cargo.toml names the lib bloom_linux, but perry's package.json expects libbloom_linux_bundled.a, so perry fails with:
Error: Native library libbloom_linux_bundled.a not found after building bloom/core crate
Fix: rename lib in Cargo.toml:3 → name = "bloom_linux_bundled".
Environments tested:
- OS: Fedora Asahi Remix 42 (aarch64)
- GPU: Apple M1 (G13G B1) via Asahi Linux Vulkan driver
- Rust: 1.95.0 (Fedora 1.95.0-1.fc42)
@bloomengine/engine: 0.4.3@perryts/perry: 0.5.x
Activity
proggeramlug commentedon May 23, 2026
Thanks for the report @ElYaiko I'll check this out today and get back to you (same with your other ticket)
proggeramlug commentedon Jul 28, 2026
Status after Linux PR #146 merged: this issue remains open.
#146 materially improved Linux device negotiation, screenshot usage, textured PT capability requests, and X11 window-close handling. It is also integrated into the active rendering PR #147. However, current
mainstill retains each original Asahi-specific condition from this ticket:XLookupStringstill casts the byte buffer to*mut i8instead of targetc_char;wgpu::Limits::default(), leavingmax_color_attachmentsat 8 rather than clamping it to an adapter that reports 5;bloom_linux, not the bundled name reported by the original Perry packaging path.So #146 should not be treated as closing #55. The remaining patch needs an aarch64 Linux/Asahi build and runtime check for all three original failure modes before this ticket can close.
proggeramlug commentedon Jul 28, 2026
Roadmap coordination update: #55 is now explicitly tracked by epic #126 as the aarch64 Linux/Asahi platform follow-up. Capability negotiation and fallback policy coordinate with #138; any Perry/native artifact naming contract coordinates with #145. The ticket remains independently closable only with the reported aarch64 build plus runtime evidence for all three original failure modes.
proggeramlug commentedon Jul 28, 2026
Renderer-limit blocker update from #138 / PR #147:
Commit
21f73d8replaces Linux'swgpu::Limits::default()device request with the shared tier-aware planner. The active desktop renderer actually uses four MRT color attachments, so the reported Asahi adapter shape (allowed: 5) now requestsmax_color_attachments: 4instead of the unrelated WebGPU default of 8. A regression test pins that exact 5-available/4-requested case, and the complete renderer successfully constructs from the bounded request on Apple M1 Max in automatic, forced-baseline, and forced-modern modes. The hosted Ubuntu Linux release build is green in run 30349837571.This issue remains open and is not yet claimed fixed end-to-end:
XLookupStringtarget-c_charmismatch remains a separate blocker;bloom_linuxvsbloom_linux_bundledartifact naming contract remains a separate blocker.So one of the three reported root causes now has an implemented, regression-tested patch; closure still requires all three plus the reported aarch64 runtime evidence.