00:12 <steev> powered the thinkpad off

00:13 <bamse> ahh, yeah that should do the trick :)

00:13 <HdkR> Easy enough for it to power off when the battery runs flat :)

00:13 <bamse> much better than the battery running fat

00:13 <steev> forbidden hawaiian punch

00:13 <HdkR> I had a Dell laptop did that one, spooky

00:14 <HdkR> Recall on all the Latitude 9540 batteries or something

00:14 <bamse> my first macbook pro developed a nice buldge

00:15 <steev> bamse: have you tried to compile next? it dies pretty fast at the sa8295p dtsi

00:15 <bamse> plain next?

00:15 <steev> 9.15-30 syntax error but i don't really understand what it doesn't like

00:15 <steev> it's the cpu opp overrides

00:16 <bamse> didn't see anything when i synced yesterday...

00:17 <steev> hm, then let me poke at our patches, and no, has the sc8280xp stuff on top of next, but none of them, afaik, touch the sa8295 but i guess some might

00:17 <steev> it does include sc8280xp, so maybe its something we do

00:18 <bamse> right, if your sc8280xp.dtsi is broken that might show up there

00:18 <bamse> not ruling out the possibility that i did screw something up...

00:40 <steev> i'll check out a vanilla next and then start looking, it's entirely possible i did :D

02:29 <steev> okay, looks like something we apply breaks it :(

04:35 <steev> but it's not the one i thought it would be, that's interesting

16:01 <jhovold> steev: bamse: my x13s appears to run cooler than yours. Cluster idling at 32 degrees and ath11k at 46. ath11k going up to 52 degrees when pushed.

16:12 <jhovold> that's at 22 degrees ambient

16:47 <steev> i'm at 23 ambient here

18:41 <leezu_> robclark: KDE KWin now implements Color Transform Matrix support for Night Light. But even though CTM is set both for an laptop display CRTC and external monitor CRTC, the CTM only takes visible effect for the laptop display. Could this be a driver issue? Or do you have any other guess what may be going wrong? I've verified with drm_info that the CTM is being set for both

18:41 <leezu_> CRTCs

18:43 <robclark> there is only a single CTM block, and it gets assigned to the internal display.. there are patches floating around to fix that but IIRC there was some objection to the policy aspect of it (ie. what if you don't have an internal display, etc).. I don't remember the latest status on that off the top of my head. But tl;dr: it is the currently expected behavior

18:45 <leezu> I see. How does CrOS handle it? Does it use a single CRTC for both displays? If you remember any keywords regarding the patches, please let me know so it will be easier to locate them

18:45 <robclark> abhinav or lumag might know the latest status on that.. CrOS has the same problem

18:46 <robclark> "drm/msm/disp/dpu1: register crtc color management to first crtc in the list" for ex

18:50 <leezu> Thank you for the pointer. So this is a hardware limitation (single CTM block)? Is this common for qcom or only applicable to sc7180?

18:53 <robclark> it's a sw bug that CTM is exposed on more CRTCs than supported, but it is a hw limit.. I think other variants of qc chips have more CTM blocks, and/or more features (like gamma/degamma, etc)

18:55 <leezu> Then sc7180 can never support CTM for the external display? Or can the single block be applied to both CRTCs?

18:56 <robclark> I think it could support CTM on internal and external but not at the same time (but the kms API doesn't support that, so they want to pick the internal display since that is the one connected all the time)

18:57 <robclark> CrOS falls back to gpu for nightlight if the CTM property is not exposed, fwiw

19:23 <robclark> leezu: side-note, doing CTM on the GPU is basically free from power standpoint.. the only reason CrOS tries to use hw CTM is to avoid powering up the GPU if it is doing overlay composition. If kwin isn't doing overlay composition it should probably not bother with hw CTM (or gamma LUT)

21:09 <leezu> robclark: KWin currently only supports GammaLUT (and with the new PR CMT). There's no GPU shader based night light implementation yet, though given the hardware limitations, it will be necessary to add. With overlay composition, are you referring to a case where for example a video is played full-screen?

21:10 <robclark> well that or windowed (which would technically be an underlay) if the gpu rendered layer hadn't changed for the frame

21:11 <robclark> but basically if you are using the gpu for composition, the ctm is a few extra instructions in the frag shader, so lost in the noise

21:12 <robclark> the main motivation for using kms CTM in CrOS compositor is to avoid powering up the GPU in the first place

21:12 <robclark> (and external display scenarios, we are less concerned about the power)

21:29 <leezu> Thank you for the explanation. KWin folks are also working on over/underlay support, so eventually the same power savings should become available

22:03 <robclark> by then hopefully we come to some solution where we don't expose CTM on more displays than the hw supports ;-)

22:51 <leezu> robclark: I noticed CTM breaks after suspending and waking up the laptop. Are you aware of this issue? Looks like KWin is setting the CMT blob correctly before and after suspend (at least it shows as non-0 in drm_info)

22:52 <robclark> if I had to take a guess, in the suspend path something triggers switch back to fbcon overwriting the properties? It would be kwin's responsibility to set them again

22:53 <robclark> oh, but modetest/drm-info shows non-zero?

22:53 <robclark> Hmm, that could be a driver bug..

22:53 <robclark> report it to abhinav/lumag ;-)

22:54 <leezu> Yes, drm_info shown non-zero. Also changing the CMT / night-light intensity no longer works after the laptop is woken up. It remains disabled until the next boot.

22:54 <leezu> Ok, I'll open an issue on the gitlab tracker?

22:56 <robclark> yeah, gitlab issue works

23:15 <leezu> https://gitlab.freedesktop.org/drm/msm/-/issues/23