Repository navigation
j615 (MacBook Air 15" M3): Chrome trackpad scrolling stutters with no GPU faults logged, even at cap 5 #385
Description
Drafted by Claude Code from this machine's logs and posted at the owner's request. The stutter itself is the owner's observation. No frame times have been measured.
Mac and installed build
- Model / board / SoC: MacBook Air 15-inch, M3, 2024 /
apple,j615/apple,t8122, 10 GPU cores (10 active / 10 slots) uname -r:7.2.11-14-1-ARCH- Packages:
linux-aurora 7.2.11.aurora14-1,mesa-aurora 1:26.3.0_devel.20261031.231483.a1969111475-1,vulkan-aurora(same),m1n1-aurora 1.6.1.aurora22-1,uboot-aurora 2026.07.aurora6-1,asahi-scripts 20261023-1,omarchy-aurora-firmware 20261014-7,omarchy 4.5.0-3 - These are the newest packages in the repo. Apple Silicon boot check: installed boot files match.
- Local changes:
asahi.t8122_pstate_cap=5on the kernel command line. This is above the default of 2, so the driver warns that states up to 5 run with no temperature feedback.- A locally built
appledrm.kofor J615 brightness control, the same change as drm/apple: enable J615 panel brightness control #354. The kernel is tainted for that out-of-tree module.
Both firmware versions and provisioning
asahi,os-fw-version: 14.7asahi,system-fw-version: 27.0- GPU firmware: T8122 C0, firmware-compat 14.8.3
Reproduction, expected result, and actual result
- Open YouTube in Google Chrome on the internal panel.
- Scroll with the trackpad.
Expected: smooth scrolling at 60 Hz.
Actual: scrolling is visibly not fully smooth. It happens during normal use, but the rate hasn't been counted.
Raising the GPU cap helped only partly:
| Cap | Owner's report |
|---|---|
| 2 / 618 MHz (default) | Not fully smooth |
| 4 / 928 MHz | Better, "could be a little better" |
| 5 / 1056 MHz (highest accepted) | Minor choppiness remains |
No known-good build. This has only been seen on the builds above.
Graphics or session details
- Active renderer:
Apple M3 (G15G C0), Mesa. Internal panel 2880x1864@60, scale 2, VRR off, no direct scanout. - Hyprland 0.56.2 with no file capabilities (
getcapis empty). It logsGot a high priority context. - Google Chrome 157.0.8103.38, Wayland, GPU process on
renderD128. - Video decodes in software: Omarchy sets
--disable-features=AcceleratedVideoDecoderon Apple Silicon./dev/video0(avd) is present.
Relevant error lines
No GPU fault appears this boot. Counts from 3h17m of uptime: page fault 0, timed out 0, flip_done timed out 0, vblank 0, underrun 0, and 0 asahi fault/timeout/halt/recover lines.
The only related signal is in hyprland.log. libinput rate-limits these lines, so the count is a lower bound:
[libinput] event0 - Apple MTP multi-touch: client bug: event processing lagging behind by 32ms, your system is too slow
[libinput] event0 - Apple MTP multi-touch: kernel bug: Touch jump detected and discarded.
[libinput] event0 - Apple MTP multi-touch: client bug: event processing lagging behind by 318ms, your system is too slow
[libinput] client bug: timer event0 hold: scheduled expiry is in the past (-54ms), your system is too slow
[libinput] event0 - Apple MTP multi-touch: WARNING: log rate limit exceeded (5 msgs per 60min). Discarding future messages.
The log has no timestamps, so these lines can't be tied to specific stutters.
/sys/kernel/debug/asahi-m3, cumulative since boot:
timing: render retirements=971430 active_ns=1673273838304 gpu_span_ns=876454964807 fragment_ns=750729049435
completion_wait: version=1 wait_us=100 notifications=1880721 sleeps=7590910 timer_wakes=6794474
- Mean GPU span is about 0.90 ms per render, and mean active time about 1.72 ms. That is well inside a 16.7 ms frame, although means can hide slow outliers.
- About 90% of completion-wait sleeps ended on the timer.
- The firmware peak state reached the cap in 101 of 109 thermal summaries.
- CPU temperatures stayed at or below 61°C in a short logged sample of about 4.5 minutes at cap 5. That sample wasn't a sustained scrolling load, and this board has no GPU die sensor.
Related issues, pull requests, or code examples
Main question: is this the desktop lag that #346 and #347 target, and should J615 test them?
- drm/asahi: admit authorized HIGH queues on Extended T8122 #346 says the extended T8122 profile rejects the compositor's HIGH request and Mesa silently falls back to MEDIUM. It reports no material HIGH advantage so far. I haven't confirmed that this fallback happens on this kernel.
- drm/asahi: back off interrupt-assisted M3 completion waits #347 changes the M3 completion-wait path. The
completion_waitcounters above may be relevant to it. - Browser AVD integration: enable hardware decode with the media sandbox retained #44 covers browser hardware decode. That might matter for YouTube because decode runs on the CPU here, though the Chrome flag was added because of green frames.
- M3 Air: qualify each shipped J613/J615 firmware profile separately #26 notes that J615 physical acceptance is pending. J613: qualify GPU states 6–8 with active thermal protection #164 covers higher GPU states on J613 and says J615 is not qualified by its results.
- drm/apple: enable J615 panel brightness control #354 is the brightness change this machine carries.
Workaround tried: raising the cap to 5, as in the table above. An attempt at cap 7 was refused as expected (accepts 1 to 5, GPU startup disabled).
What was not tested
- Frame timing or presentation gaps, in Chrome or Hyprland. The root cause is unknown, so this may not be a driver bug.
- Whether the libinput lag lines line up with the visible stutter.
- Firefox, or any other browser.
- Other pages, or Chrome with GPU rasterization or compositing changed.
- Chrome with the video decoder enabled.
- A stock
appledrmat the same cap. - drm/asahi: admit authorized HIGH queues on Extended T8122 #346, drm/asahi: back off interrupt-assisted M3 completion waits #347, Linux v7.2.15 (Merge Linux v7.2.15 into integration/aurora (with perf mmap accounting test) #362), or a newer Hyprland.
- Battery compared with AC, and power profiles.
- External displays.
Activity
contursofran commentedon Nov 8, 2026
Drafted by Claude Code from this machine's logs and posted at the owner's request. The lag is the owner's observation; no frame times were measured.
Second j615 with the same symptom, on the same packages, plus a desktop hang when Chromium's GPU rasterization was forced on.
Mac and build
apple,j615/apple,t8122,10 active / 10 slotsuname -r:7.2.11-14-1-ARCHlinux-aurora 7.2.11.aurora14-1,mesa-aurora 1:26.3.0_devel.20261031.231483.a1969111475-1,vulkan-aurora(same),m1n1-aurora 1.6.1.aurora22-1,uboot-aurora 2026.07.aurora6-1,asahi-scripts 20261023-1,omarchy-aurora-firmware 20261014-7,omarchy 4.5.0-3,hyprland 0.56.2-7asahi,os-fw-version14.7,asahi,system-fw-version26.6.2 (yours is 27.0)asahi.*options on the kernel command line, so the default cap:runtime cap 2 (618 MHz) of 2..=2, logged withno SoC die temperature (no SoC die temperature zone)every 30 s.Lag
renderD128with system Mesa (libgallium-26.3.0-devel,libEGL_mesa), not SwiftShader.Plane 35 has type 1, no cursor plane), so the cursor is composited and waits for Hyprland's frames.balancedprofile, schedutil, P-cores reach 4056 MHz).Hang with forced GPU rasterization
To check whether CPU rasterization was the bottleneck, Helium was started with:
The flags took effect: raster work moved from the renderer to the GPU process (~27 % CPU). The lag didn't improve, and about 4 minutes later the desktop froze:
at-spi2-registryd: Disabling unresponsive appmacsmc-input: Triggering forced shutdown!The kernel log for that boot has no asahi fault, timeout, firmware-error or recovery line before the hang, so I can't tell whether it's the firmware halt from #174 / #90 or something else. The only asahi lines are the 30 s thermal summaries. The runtime switches were
asahi.m3_unlocked_wait=1 asahi.m3_timeout_nohang=1 resume-after-fault=0. Since removing the flags (Chromium's default GPU path, CPU raster), there has been no hang.freber commentedon Nov 13, 2026
Same symptom on a second J615. Scrolling in Chromium still isn't fully smooth at cap 5. Going from cap 2 to 5 helped here too, but it didn't fix it.
apple,j615/apple,t8122, 10 GPU coreslinux-aurora 7.2.11.aurora16-1,mesa-aurora 26.3.0_devel.20261107,m1n1-aurora 1.6.1.aurora23-2, Hyprland 0.57.2One difference from your setup is that my cap 5 runs with temperature feedback. #464 gives the J615 the J613's SMC die keys. Until it lands I'm running with them through
macsmc_hwmon soc_die_keys=. This is what the governor logs during normal desktop use.That log isn't from a scrolling run. The cap can't move anyway, since the range is 5..=5. The die read 58.3 C, so I don't think the stutter left at cap 5 is thermal.
On an earlier boot (still at cap 2), a GPU client lost its device twice within three minutes during a Google Meet call in Chromium where I screen shared some basic 3D content. The machine has 23 GB of RAM.
free -hshowed 14 GB available a few minutes after the call.The call was slow from then on, which fits Chromium being that client and falling back to software rendering. I haven't checked
chrome://gputo confirm it.No libinput "your system is too slow" lines in
hyprland.logthis session (34 minutes of uptime). I haven't measured frame times. Tell me which tool you want for that and I'll run it on this J615.