00:00 <leio> I haven't done s2idle on the box for months, so I take it it wouldn't fix anything I'm experiencing in that case?

00:39 <chadmed_> hmmm amd's display controller also does not have a real cursor plane

03:00 <chadmed_> im torn on whether or not to file a kwin bug for the colour management black panels

03:01 <chadmed_> on one hand it only happens with the display p3 profile and clearly there are issues given kwin's explosion when you first apply a profile

03:01 <chadmed_> on the other no one else seems to have run into anything similar on other so it could just be a gpu driver bug

03:01 <chadmed_> on other platforms*

06:03 <chadmed_> has anyone taken note of the fourccs used for NV12 and/or linear YUV420 by DCP yet?

06:03 <chadmed_> i was going to do that today but m1n1 doesnt like macos 14.2 and i have no space on any machine for a new 13.5 install at the moment

07:47 <janneg> leio: who knows which issues that fixes. I'm certain it explains the suspend issue. other than that I'm surprised it was working at all (except the initialization at boot)

07:53 <janneg> chadmed_: I spoke about the profile activate error in #kwin:kde.org, they don't see that anywhere else, it isn't triggered by SW cursors. appears to be an issue wit damage tracking. brokeness vanishes after repaint, for example by moving a window over it

07:56 <chadmed> janneg: that makes sense. i assume the persistent black panels are probably a gpu bug then

07:56 <chadmed> damage and repaint doesnt clear them

07:58 <janneg> I can't remember having seen black panels but I'm not using plasma 6 yet

08:02 <janneg> I think dcp only supports planar yuv and no nv12. macos fourccs are probbably 420v, 422v and 444v. not quite clear based on dcp fw strings

08:03 <janneg> issue with supporting overlays is that compositors then try to use the overlay for SW

08:03 <janneg> HW cursors

08:04 <chadmed> last time i had a play with it weston ignored the 2 overlay planes i instantiated because they were not _CURSOR

08:04 <chadmed> hopefully kwin behaves the same. either way i am forcing sw cursors at the moment so it shouldnt explode _too_ hard

08:05 <chadmed> unfortunately i think kwin still just doesnt support overlay planes at all except for cursor in any case, so ill have to throw weston on j314

09:15 <janneg> sven, marcan: please, update asahi-wip with https://github.com/jannau/linux/tree/asahi-wip . just a linear update since I don't think the hassle with full merge of the bits branches for 6.6 is justified at this point. I also pushed a signed asahi-6.6-16 tag. not sure if we want to use that or one signed with marcan's key

09:37 <chadmed> well planar 420 seems to just work when done "properly" :p

09:39 <chadmed> odd issue when scaling the viewport or trying to enter fullscreen mode but unclear whether that's vlc/weston being odd or us

09:39 <chadmed> but the colours are fine and frames are pushed to the plane correctly

09:50 <sven> janneg: done

09:52 <sven> pushed the tag as well

09:54 <janneg> thanks

15:27 <tristan2> I'm sorry to write about ALARM, but with the release of llvm 17, mesa-asahi-edge is broken, since it does not have a versioned dependency on llvm-libs 16

17:02 <janneg> axboe: did the broken asahi-wip-6.8 kernel have CONFIG_DRM_APPLE=y?

18:08 <janneg> sven: when you have time please refresh asahi-wip-6.8 with https://github.com/jannau/linux/tree/beta-6.8/asahi-wip

18:19 <zzywysm> sven: you probably also want to update the relevant bits branch with the devicetree fixes, or else marcan is likely to forget those fixes when he returns and rebases/merges onto 6.8 or 6.9

18:27 <janneg> my expectatation is that we will continue with the bits branches from https://github.com/jannau/linux/tree/beta-6.8/bits/000-devicetree, ... which already contain the fixups

18:28 <sven> I’ll update asahi-wip-6.8 later

18:28 <zzywysm> janneg: i was referring to the bits/000-devicetree branch at AsahiLinux/linux, which hasn't been updated in 4 months

18:29 <zzywysm> unless i missed an announcement that m a r c a n isn't merging/tagging new kernels anymore?

18:40 <janneg> currently not, I would expect a sync on resuming and using my 6.8 bits branches as base

21:05 <axboe> janneg: yep

21:17 <janneg> ok, issue should be fixed then

23:05 <axboe> janneg: perfect, I'll give it a whirl - so I can drop the work around?

23:38 <axboe> janneg: yep works, thanks!