Repository navigation
Conversation
On H17G the system endpoint announces powerlog-service on channel 1 with only ep-has-desc-mgr and interface-id, so parse_epic_service_init() returned -ENOENT and the service carrying the mNits reports never bound. Match such announces by their name, as props-less announces are (only for the H17G method profile, so H17P is unchanged). H17G publishes no NITS property, so register the backlight device from the first powerlog report instead (140 nits at boot on the J813). H17G firmware ignores the DAC words (bl_unk/bl_value/bl_power at swap+0x32f) and takes the H17P brightness encoding in the same swap bytes (activation at +0x354, binary64 nits at +0x35e, ceiling pair at +0x36e/+0x376), which the unserialized 26.6 request already spans. Factor the H17P encoder to take the swap record and use it from the flush on a brightness update. Tested on the MacBook Air M5 (J813): apple-panel-bl 0..500 nits; writes of 100/300/140 give DCP "send_brightness" at those levels and matching actual_brightness, and the panel follows. Signed-off-by: Thomas Glanzmann <thomas@glanzmann.de>
…pty dict
The M5's DCP (H17G) panicked with "app NMI" one hour after every boot,
taking the display with it. Its crash log shows "OSDictionary
deserialization failed": D114 CoreAnalyticsSendEvent was answered with
trampoline_zero on H17G, so the reply starts with 0 instead of an
OSDictionary. H17P already returns an empty dictionary ('d', 0x1004
bytes); D114's sizes are the same on H17G (0x1044/0x1004), so use that
reply there too.
DJ identified the analytics callback as the one-hour trigger.
Tested on J813 (M5 MacBook Air): two boots run past one hour (3799 s,
4269 s+) without a DCP crash; before, every boot crashed at about 3600 s.
Signed-off-by: Thomas Glanzmann <thomas@glanzmann.de>
On the M5 (H17G) internal panel, DPMS off stopped the DCP pipe:
setPowerState(0) times out and the following setPowerState(1) is never
answered ("wait for power timed out, connector will be broken"), so the
panel stays frozen after a lid close or a compositor's output power off.
Keep the pipe running instead, as H17P soft DPMS does: DPMS off submits
a black, surface-free clear swap that also takes the backlight to 0 nits;
DPMS on only requests a brightness update, and the next frame restores
scanout and level.
Tested on J813: fbdev blank/unblank and sway output power off/on cycles
and a lid close/open; the firmware reports brightness 0 and back to the
previous level, no timeouts.
Signed-off-by: Thomas Glanzmann <thomas@glanzmann.de>
The H17G (M5) DCP firmware blends the fourth byte of an XRGB surface as alpha, and it ignores the opaque-X property as H17P does. A compositor that picks XRGB8888 leaves that byte to whatever its renderer stored: the GPU-rendered sway output on J813 showed blue and cyan text as black and grey while the pixels in memory were right. Offer the overlay formats, which all carry alpha, on the H17G primary plane, so that compositors write the byte. Treat the fbdev console the same way as on H17P: an XRGB console with X = 0 stays black. Signed-off-by: Thomas Glanzmann <thomas@glanzmann.de>
sithglan
changed the title
Contributor
Author
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Four fixes to integration's drm/apple for the MacBook Air M5 (J813, H17G DCP firmware), which otherwise already drives the J813 panel:
Tested on the J813 on integration/aurora 41c4055 with the other J813 branches (#806-#812) merged, booted through aura's trial boot: apple-panel-bl 0-500 nits, writes are applied (actual_brightness follows, the panel changes), the powerlog error is gone. The DPMS and CoreAnalytics changes are as tested on the J813's current kernel (lid close and idle-off recover; no DCP NMI after an hour). With the colour fix sway scans out AR24, and the panel shows blue and cyan text correctly (checked on the J813 panel).
cc @Acelogic @DjDeveloperr @RyanTheTide @LiamRay10