ChanServ changed the topic of #asahi-dev to: Asahi Linux: porting Linux to Apple Silicon macs | Non-development talk: #asahi | General development | GitHub: https://alx.sh/g | Wiki: https://alx.sh/w | Logs: https://alx.sh/l/asahi-dev
leah2 has quit [Read error: Connection reset by peer]
leah2 has joined #asahi-dev
cobypear has joined #asahi-dev
cobypear has left #asahi-dev [#asahi-dev]
psykose has quit [Remote host closed the connection]
<marcan>
jannau: I think the blend order is BG, 2, 0, 1, 3? And some hardware can support only 2 layers enabled at once, some 3
<marcan>
the surfaces probably have specific meanings, they aren't just arbitrary layers
<marcan>
that's why we have 4 when hardware only supports 2 or 3
<marcan>
I bet they added 3 for HDR or something like that
<marcan>
and then 2 is probably meant as a YUV plane (I think it should be an underlay, not an overlay, to allow UI element compositing on top) and 1 as an overlay that can do more advanced blending
<marcan>
or something like that
<marcan>
jannau: the 0xff000000 bg_color is just setting it, and bit 31 of the swap_enabled stuff isn't clear, it's background set enable
<marcan>
I think the bits in swap_completed may actually enable swap presentation timestamping or something like that?
jluthra has quit [Remote host closed the connection]
whomst has quit [Quit: My Mac has gone to sleep. ZZZzzz…]
SSJ_GZ has quit [Ping timeout: 480 seconds]
<jannau>
marcan: makes sense in general
<jannau>
for 10-bit xrgb and many yuv formats we can workaround the missing support by using the corresponding pixelformat with a separate alpha plane and use driver managed buffer of 0xFFs
<jannau>
I don't see anything for 8-bit XRGB though
<jannau>
but as long as we use just a single plane blending as premutiplied alpha with the black background will work
<jannau>
marcan: unrelated, do you plan to submit t8110 dart for 6.3? if not I'll prepare a base t8112 device tree / bindings series
<jannau>
kettenis: please ping me when you start porting the dcp driver. we should avoid squashing changes after that, do you have other suggestions to make porting easier?
<kettenis>
jannau: not looked at it in detail yet
<kettenis>
is your current driver based on 6.1? or did you already move ahead?
<kettenis>
(we just integrated drm from linux 6.1 into OpenBSD)
systwi has quit [Read error: Connection reset by peer]
systwi has joined #asahi-dev
<jannau>
we're still based on 6.1 and I wouldn't expect that we lose backwards compatibility with 6.1 drm anytime soon
<jannau>
drm integrated backlight handling is the only upcoming DRM change I want to integrate asap but as far as I'm aware that still needs to be written
<kettenis>
ah, interesting, I have drm integrated backlight handling on OpenBSD ;)
<kettenis>
yes, as (fairly minimal) patches to the drm code
<kettenis>
same fundamental idea; a
<kettenis>
same fundamental idea; a property on the connector
<jannau>
I would expect the actual changes to be rather small on linux sise as well but cleanup and code for backwards compatibility is more complicated
bcrumb has joined #asahi-dev
bcrumb has quit [Quit: WeeChat 3.7.1]
SSJ_GZ has joined #asahi-dev
bps has joined #asahi-dev
bluetail8 has joined #asahi-dev
___nick___ has joined #asahi-dev
___nick___ has quit []
___nick___ has joined #asahi-dev
tobhe has joined #asahi-dev
<marcan>
jannau: 10-bit is already xrgb
<marcan>
there is no support for a2rgb10
<marcan>
it's x2
<marcan>
and most yuv formats are already alphaless
<marcan>
it's only xrgb8888 that is missing
<marcan>
so yes, this means we can support xrgb8888 in the bottommost plane only
<jannau>
oh, I missed that w30r is without alpha, we probably shouldn't claim to support a2rgb10 then
<jannau>
currently ok but a2rgb10 overlays will not work
<marcan>
correct, we shouldn't
<marcan>
though I don't know why anyone would want to use that format anyway
<marcan>
it's kind of useless
<marcan>
lol @ the broadcom guy ignoring my original email then replying to the silly-but-safer proposal from the T2 guy asking WTF
<marcan>
because y'all from the actual company don't bother answering questions about how to do actually do this *correctly*, that's why
<jannau>
yuv overlay on surf 1 over surf 0 was only working with the premultied bit set
<jannau>
yes, a2rgb10 is mostly useless. it would support hole punching for video underlays. that breaks with blending with the video, 2 bits of alpha are not enough to look good
axboe has joined #asahi-dev
<marcan>
oh god and my reply flew right over the T2 guy's head... *sigh*
bcrumb has joined #asahi-dev
bcrumb has quit [Quit: WeeChat 3.7.1]
corion has quit [Ping timeout: 480 seconds]
yamii has quit [Quit: WeeChat 3.6]
yamii has joined #asahi-dev
compassion8 has joined #asahi-dev
compassion has quit [Ping timeout: 480 seconds]
compassion8 is now known as compassion
bcrumb has joined #asahi-dev
bcrumb has quit []
bcrumb has joined #asahi-dev
bcrumb has quit [Quit: WeeChat 3.7.1]
bps has quit [Ping timeout: 480 seconds]
djorz has joined #asahi-dev
axboe has quit [Remote host closed the connection]
<jannau>
replaces Thierry's reserved region patches with the latest version. implemented by reverting the original commits and redoing the updated changes
<jannau>
https://github.com/jannau/linux/tree/dcp/sleep is dcp/sleep rebased onto asahi-6.1-3_dcp-components, it still has issue (PCIe) but dcp runtime pm seems to work. tested on j274, j375 and j493 but not j314