Skip to content

drm/apple: time-stamp T6030 swaps on 14.7 for 120 Hz - #358

Open
cachebag wants to merge 1 commit into
omacom:integration/aurorafrom
cachebag:t6030-swap-timestamps
Open

cachebag wants to merge 1 commit into
omacom:integration/aurorafrom
cachebag:t6030-swap-timestamps

Conversation

@cachebag

@cachebag cachebag commented Nov 4, 2026 •

Copy link
Copy Markdown

The T6030 (M3 Pro) record admits the panel's 120 Hz timing, but its swaps go out with zero timestamps, so the firmware completes at most one per 16.7 ms: the mode reports 120 Hz while a vsync-locked client measures 60 fps. The J516C already sends the constant timestamps for this; this sets swap_timestamps on the T6030 record too and updates the board test.

Tested on a J514S (14" M3 Pro), DCP firmware 14.7, aurora-2026.10.17.20 with the equivalent change: es2gears_wayland goes from 60.0 to 119.9 fps on the built-in panel. Not tested on a J516S, which shares the record. Report: #360

AI Disclosure: I did not use AI for these (#358, #361, asahi-alarm/PKGBUILDs#100) patches, though the commit messages were all generated via Opus 5.5.

The T6030 (M3 Pro) record admits the panel's 120 Hz timing, but its
swaps go out with zero timestamps, so the firmware completes at most one
per 16.7 ms: the mode reports 120 Hz while a vsync-locked client
measures 60 fps. The J516C already sends the constant timestamps for
this; set swap_timestamps on the T6030 record too.

Tested on a J514S (MacBook Pro 14", M3 Pro), DCP firmware 14.7, on
aurora-2026.10.17.20 with the equivalent change: es2gears_wayland goes
from 60.0 to 119.9 fps on the built-in panel. Not tested on a J516S,
which shares the record.

Signed-off-by: cachebag <alhakimiakrmj@gmail.com>
@ryan-stoffel

Copy link
Copy Markdown

Note

🤖 Claude Opus 5.5 responding on behalf of Ryan

Reproduced the 60 fps cap this PR targets on a second J514S (14" M3 Pro, apple,j514s), DCP OS firmware 14.7.

Without this change, using the packaged linux-aurora 7.2.11.aurora14-1 under Hyprland, with the eDP mode at 3024x1964@120:

Test Result
mpv, testsrc2 at 120 fps, --video-sync=display-resample, 10 s estimated-display-fps 59.5 to 59.6, 0 dropped, vsync jitter 1.02

A vsync-locked client gets every second refresh, matching the description here.

I've built appledrm with this patch applied on integration/aurora at 4fdd0fc5 (its module parameters match the packaged module exactly) and installed it as an out-of-tree update. I'll post the post-reboot numbers from the same mpv test here.

@ryan-stoffel

ryan-stoffel commented Nov 5, 2026 •

Copy link
Copy Markdown

Note

🤖 Claude Opus 5.5 responding on behalf of Ryan

With this patch, J514S on 14.7 goes from 60 to about 98 fps, not 120.

Same machine and the same mpv test as my previous comment. The only change is appledrm built with this patch.

Stock This PR
estimated-display-fps (5 s / 10 s) 59.5 / 59.6 99.1 / 97.9
Frames in 10 s 594 977
Dropped 0 0
vsync jitter 1.02 0.36 to 0.39
Boot-time swap 3 complete 16611 us 8311 us

There were no DCP errors, flip failures or GPU faults in the kernel log. The remaining gap fits what #31 reported: the timing words alone reached about 80 fps under Hyprland, and the opt-in early flip there brought it to 120.

Update: I ported the opt-in early flip from #31 (t6030_early_flip, the flip event sent before dcp_v14_present()) onto this patch. On the same J514S with the same mpv test, the panel now runs at a full 120 Hz:

Stock This PR This PR + #31 early flip
estimated-display-fps at 10 s 59.6 98 to 103 119.0 to 119.7 (3 runs)
Dropped 0 0 0
vsync jitter 1.02 0.33 to 0.39 0.19 to 0.30

Early flip can be toggled at runtime through /sys/module/appledrm/parameters/t6030_early_flip. The kernel log stayed clean with it on. I'm now running both from boot as a daily driver until an official fix ships, and will report here if anything regresses.

@techgyani

Copy link
Copy Markdown

The J514M (14-inch M3 Max, T6034, DCP 14.7) has the same 60 fps cap: dcp_v14_board_j514m in iomfb_v14_7.c (at 8eddf5aeb6ac, after #408) sets .promotion = true but not .swap_timestamps. Adding .swap_timestamps = true, to that record, on a test build that also carries #406's driver commits (external displays not enabled or connected), took the built-in panel from 60.0 to about 120 fps:

es2gears_wayland: 60.000 FPS -> 119.233 / 120.128 FPS
wp_presentation:  60.000 Hz (16.667 ms) -> mean 119.461 Hz, median 8.333 ms (1200 frames)

Details and the full method: #333 (comment). Not a separate PR; noting it here since this PR changes the same field for the T6030 record.

@crybo-rybo

Copy link
Copy Markdown

Note

🤖 Claude Opus 5.5 responding on behalf of the account owner. The patch build, tests and this write-up were done by Claude Code on their machine, at their request.

Tested on a J516S (16" M3 Pro): this PR alone brings the panel to 120 Hz. Early flip from #31 made things slightly worse here, not better.

Machine and build

  • MacBook Pro 16" M3 Pro (apple,j516s / apple,t6030), DCP OS firmware 14.7, panel mode 3456x2234@120
  • Omarchy 4.5.0-3, linux-aurora 7.2.11.aurora14-1 (7.2.11-14-1-ARCH), Hyprland 0.56.2
  • appledrm built out of tree from integration/aurora at 4fdd0fc5 (the aurora14 package pin) with clang 18.1.8 / LLVM 18, the package's toolchain. An unpatched build matches the packaged module's .text and .data sizes exactly (395964 / 18144 bytes), and its parameter list is identical. Patched build = this PR's diff plus the opt-in t6030_early_flip from J516S: 120 Hz mode produces approximately60 Hz page-flip completions #31, ported onto 4fdd0fc5, installed under updates/ and in the initramfs.

Results

Stock aurora14 This PR (t6030_early_flip=0) This PR + early flip (=1)
wp_presentation client, shm, 3 buffers, ~720 frames/run 60.0 fps, every gap 16.7 ms 119.4–119.9 fps (5 runs), ≥711 of ~718 gaps at 8.33 ms 111.0–111.8 fps (3 runs), ~7.5% of gaps at 16.7 ms
mpv testsrc2 1080p120, --video-sync=display-resample, estimated-display-fps at 10 s, windowed not measured 118.1 / 119.5 119.4 / 120.1
same, fullscreen not measured 119.7 / 120.6 120.0 / 119.5
mpv dropped frames 0 0
mpv vsync jitter 0.07 (one windowed run 0.23) 0.11–0.14
Boot-time swap 3 complete 16552 / 16527 us (two stock boots) 8202 us
  • The presentation feedback flags were 0x7 (vsync, hardware clock, hardware completion) in every run.
  • Stock was measured with the same client before the module swap. mpv was not run on stock.
  • Kernel log: no flip failed, DCP failure, GPU fault or DEVICE LOST in any configuration. The only DCP firmware syslog lines at boot (LACS_ERROR, Realtime Bandwidth setup failed, create_default_fb_surface ... failed) are identical on the stock boot.

Notes

  • This differs from the J514S result above (~98 fps with this PR alone, 120 only with early flip). On this J516S, swap_timestamps alone is enough under Hyprland with a 3456x2234 mode.
  • With early flip on, the light wp_presentation client misses about one vblank in thirteen (gaps at 16.7 ms). mpv stays at about 120 but with higher jitter. So on J516S the PR as it stands, without early flip, looks like the better default.
  • The J516S shares the T6030 record, so this covers the "Not tested on a J516S" note in the description.

@S41G0N

S41G0N commented Nov 9, 2026

Copy link
Copy Markdown

I just reproduced the bug and confirmed the fix on a J514S (14" M3 Pro, apple,t6030, firmware 14.7), Omarchy 4.5.0-3 with linux-aurora 7.2.11.aurora14-1.

On stock it runs at 60 fps even though the panel reports 120 Hz. After this PR's iomfb_v14_7.c change it runs at a full 120 Hz and the kernel log shows no new errors.

I tested it using Claude Code though so not sure how valid that is, the display feels much smoother though.

@moritzuehling

Copy link
Copy Markdown

Confirmed on a 14-inch M3 Pro MacBook Pro (J514S/T6030), using the equivalent change on linux-aurora 7.2.11.aurora14-1: boots successfully, the internal display runs at 120 Hz, and glxgears now reports 120 fps.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

6 participants