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
sckova has joined #asahi-dev
chadmed_ has joined #asahi-dev
<chadmed_>
nicolas17: i have a suspicion that it doesnt just based on the cursor's behaviour, but i havent traced it or anything
<chadmed_>
but that's kind of irrelevant for us. for optimal video playback etc we need an overlay plane and compositors need to know about it. the issue here is that drm has moved to "universal" planes because most modern hardware doesnt have special snowflake planes _just_ for cursors
<chadmed_>
this is an issue for dcp as it does not support swap surfaces smaller than 32x32, likely owing to its original use case in apple tvs and idevices. just like how no one needs 4K RAM, who needs a 32x32 framebuffer on a television
<chadmed_>
unfortunately this doesnt really explain why it cant do audio bitstream formats. this has been a critical shortcoming of the apple tv for a very long time
<chadmed_>
im not sure if it's going to be better to put in the work to add like min_x min_y specifications to planes generically or just make the dcp driver reject a swap if the source fb is too small. will compositors respect that? might just test it later
chadmed_ has quit [Quit: Page closed]
pb17 has quit [Ping timeout: 480 seconds]
cylm has quit [Ping timeout: 480 seconds]
KxCORP5894 has quit [Quit: Bye!]
KxCORP5894 has joined #asahi-dev
pb17 has joined #asahi-dev
jeisom has quit [Ping timeout: 480 seconds]
pb17 has quit [Ping timeout: 480 seconds]
pb17 has joined #asahi-dev
tristan2 has joined #asahi-dev
tristan2_ has quit [Ping timeout: 480 seconds]
sckova has quit [Quit: sckova]
chadmed has quit [Quit: Konversation terminated!]
pb17 has quit [Ping timeout: 480 seconds]
Wolfram has joined #asahi-dev
<Wolfram>
:
Wolfram has quit [Remote host closed the connection]
pb17 has joined #asahi-dev
JayBeeFOSS has quit [Ping timeout: 480 seconds]
JayBeeFOSS has joined #asahi-dev
<jannau>
the default cursor size is 64x64, I would expect drm helpers already check / enforce mode_config.min_width / mode_config.min_height
<jannau>
nicolas17: macos uses hw cursors but switches to sw cursors when the cursor hits the screen edges
chadmed has joined #asahi-dev
<chadmed>
jannau: unfortunately it looks like planes are unaffected by the mode min and max. drm_info reports that the src rectangle can still be [0, UINT32_MAX] in both x and y
<chadmed>
and rejecting the framebuffer in iomfb_flush doesnt seem to do anything? e.g. the text entry beam/resize cursors cause dcp to crash due to being too narrow in one dimension
glem has quit [Read error: Connection reset by peer]
glem has joined #asahi-dev
SalimTerryLi has joined #asahi-dev
SalimTer- has quit [Ping timeout: 480 seconds]
SalimTer- has joined #asahi-dev
SalimTerryLi has quit [Ping timeout: 480 seconds]
SalimTerryLi has joined #asahi-dev
SalimTer- has quit [Ping timeout: 480 seconds]
SalimTer- has joined #asahi-dev
pb17 has quit [Ping timeout: 480 seconds]
SalimTerryLi has quit [Ping timeout: 480 seconds]
chadmed has quit [Remote host closed the connection]
SalimTerryLi has joined #asahi-dev
<jannau>
chadmed: reject it in apple_plane_atomic_check() then
SalimTer- has quit [Ping timeout: 480 seconds]
chadmed has joined #asahi-dev
<chadmed>
jannau: that was the first thing i tried since it is the "correct" way to do it, no dice :p
<chadmed>
unless it's just crashing for some other reason now
SalimTerryLi has quit [Ping timeout: 480 seconds]
pb17 has joined #asahi-dev
<jannau>
min_width/height are checked in addfb2 but we might need to check the plane's CRTC_W/CRTC_H
chadmed has quit [Quit: Konversation terminated!]
SalimTerryLi has joined #asahi-dev
<jannau>
apparently page flips are slower on dcpext compared to dcp, no or less issues on m1 mac mini
<chadmed>
i suspect theres some horsin around with the "legacy" ioctls not calling some atomic helper function because this _only_ happens when setting up the plane as a cursor plane
<chadmed>
the fun thing is i can freely wiggle the cursor around with no issues until one of these swaps fails, then the planes swap and dcp treats the cursor as the primary plane until the next failed swap. not sure what is trying to make the fb 64x9 either since the cursor is not actually changing
<chadmed>
also not sure why it tolerates some of these but then crashes on others
<chadmed>
1/2 in 16.16 is ((1 << 16) / 2) right
<jannau>
this has nothing to do with scaling on DRM/KMS level. dcp interprets sizes smaller than 32 as requests for scaling
<chadmed>
either way apple_plane_atomic_check doesnt appear to be doing what it's supposed to
<jannau>
I don't think dcp is complaining about what apple_plane_atomic_check is checking
<jannau>
I always forget if I already checked if the comment matches the code. looks to me like it might be checking for 4x downscaling and 2x upscaling
<chadmed>
yeah thats why i asked about 16.16. the arguments to FRAC_16_16 look the wrong way around too?
chadmed has quit [Remote host closed the connection]
jeffmiw has quit [Ping timeout: 480 seconds]
<jannau>
sven: works, I confused myself for a moment by the missing bcm4388 support upstream
jeffmiw has joined #asahi-dev
<jannau>
I think it's not necessary on bcm4378, at least bt le still worked on j274
<jannau>
sven: feel free to add my Tested-by:
<sven>
great, thanks! and I confused 4377 with 4378 :D
<sven>
so I guess only enable it for 4387
<jannau>
shouldn't the fixes tag be Fixes: 2e7ed5f5e69b ("Bluetooth: hci_sync: Use advertised PHYs on hci_le_ext_create_conn_sync")? also please add "Cc: stable@vger.kernel.org"
<sven>
yup
<jannau>
yes, schould be only bcm4387. I have a fixup commit for our out of tree bcm4388 support
<sven>
alright, i'll wait another day or so and see if luiz replies again and submit it otherwise
<jannau>
sven: typo "Broadcpm" in include/net/bluetooth/hci.h
<sven>
:D
<sven>
i'm glad we're doing this now before git send-email ;)
<sven>
I guess we can at least send the two fixes after the 4388 support commit as well
chadmed has joined #asahi-dev
<chadmed>
i tamed the beast! (kinda)
<chadmed>
it even works with small cursors
<chadmed>
very funny and silly fix: l = new_state->zpos
<chadmed>
for_each_oldnew_plane_in_state seems to not have a set order, and dcp seems to expect to receive surfaces in order
<chadmed>
userspace will always want the cursor over the primary plane, so just feed the planes into req->surf[] in the order userspace tells us!
<chadmed>
new issue: alpha doesn't alpha and the cursor plane is filled with black
<chadmed>
but at least it doesnt crash
<jannau>
sven: I've switched to b4 (https://b4.docs.kernel.org/en/latest/) and that beats manual git format-patch/send-email use by heaps and bounds. especially for cover letter composing and revisions
<sven>
yeah, same
<jannau>
pushed out asahi-6.8.9-5 with this bt le fix and some "fixups" for the flip complete timestamps so that kwin commits in time
<jannau>
fixes the the half rate display on on devices where dcpext is used
<jannau>
which apparently takes around 0.7 ms longer from swap_submit ot swap_complete
<chadmed>
this fixes dcp crashing when using hardware cursors
<chadmed>
of any size btw
<chadmed>
only two issues left: stupid behaviour near the edge of the screen (why tf do compositors try to squish the cursor? just noclip out of the bounds of the primary plane), and the fact that alpha doesn't seem to work as it should (the cursor plane is filled with black instead of transparency)
<chadmed>
also surface 0 works on m2 on 13.5. it's getting late now but i will build this patch on j314 and see if it works there now too with 13.5 fw
<chadmed>
LarstiQ: when you move to the right of the screen, rather than clip out past the bounds of the primary plane as youd expect, the cursor just gets compressed along the x axis such that the rightmost edge of its framebuffer never clips outside the rightmost edge of the primary below it
<chadmed>
its very odd and im sure its not _supposed_ to do that (we are probably doing something odd)
<LarstiQ>
hmm, not seeing that happen on river I think
<chadmed>
you wont see it happen, we havent wired up hardware planes yet :p
<LarstiQ>
or at least not such that it's obvious to my eye
<chadmed>
theres no point until at least kwin supports universal planes, as the old api that distinguishes between overlays and cursors is dead
<LarstiQ>
chadmed: doh :)
<chadmed>
anyway the issue is that dcp does _not_ like framebuffers smaller than 32x32, and will fail to swap. kwin is squishing the cursor down past 8x64
<LarstiQ>
right
<chadmed>
but at least it doesnt just crash now :)
<LarstiQ>
progress is finding the next problem
<chadmed>
i was just about ready to give up too!
TheLink has quit [Quit: Bye!]
TheLink has joined #asahi-dev
ddxtanx has joined #asahi-dev
<jannau>
chadmed: the squishing at the edges is dcp's doing. it requires that 32x32 of the cursor plane are on the screen. This is the reason why there is no HW cursor support
TheLink has quit [Quit: Bye!]
linuxgemini65 has joined #asahi-dev
cylm_ has joined #asahi-dev
<jannau>
the issue with with surface 0 is that x2rgb10 wasn't respectinmg the color space and was always using apple's wide rgb space
linuxgemini6 has quit [Ping timeout: 480 seconds]
cylm has quit [Ping timeout: 480 seconds]
<sven>
huh, i didn't realize b4 supports submission via web endpoint instead of smtp. that's very convenient
TheLink has joined #asahi-dev
<chadmed>
no (obvious) colour space issues observed here, but obv the pros have different screens. will test tomorrow on j314.
TheLink has quit []
<chadmed>
hw cursor specifically is no big deal right now but fixing as much as we can for multiple planes in general will make it less painful to wire them up for video playback and such when we want that eventually
<chadmed>
i am slightly worried about universal planes though...
jeffmiw has joined #asahi-dev
TheLink has joined #asahi-dev
<chadmed>
oh i think we misunderstood the docs. plane types havent/arent going away, userspace just gets to see all of them rather than kms tying the primary and cursor to the crtc internally and using unique ioctls for them
<chadmed>
it doesnt mean that all plane types will be treated the same
<chadmed>
so we're still "good" :)
oneiros has joined #asahi-dev
___nick___ has joined #asahi-dev
pb17 has quit [Ping timeout: 480 seconds]
___nick___ has quit []
___nick___ has joined #asahi-dev
oneiros has quit [Remote host closed the connection]
<jannau>
the plane types are not going away but it would be reasonable for universal planbe aware user space client to fallback using an overlay plane for HW cursor
<leio>
sven: "Broadcpm" in one of the comments
<sven>
yeah, see backlog
<leio>
righto, was still catching up, sorry
pb17 has joined #asahi-dev
<leio>
I believe mutter/gnome-shell uses only cursor plane for cursor, but are open to using a generic one for it when needed; I gather it would give more freedom too, so you have more planes available when e.g. mouse cursor is hidden cause you are watching a video and can then put shell chrome in one plane, zero-copy video in another and subtitles on another on top of it, while otherwise it might only work when video is fullscreen
<nicolas17>
"when you move to the right of the screen, rather than clip out past the bounds of the primary plane as youd expect, the cursor just gets compressed along the x axis" I want to see that :D
<chadmed>
leio: that is the point yeah. i dont think it is reasonable for compositors to use generic overlays for the cursor. planes have been universal since 3.x and neither xorg nor any wayland compositor has yet to use overlay planes for the cursor
pb17 has joined #asahi-dev
<chadmed>
i think "universal" really is a misnomer here
<leio>
chadmed: not following now, as you seem to be saying kind of the opposite of what I thought we both meant
<chadmed>
i mean overlay planes in general, the point is for that use case
<chadmed>
the problem with consuming an overlay with the cursor is that most hardware either doesnt support them at all or only has two or three planes
<leio>
oh, me not knowing the types thjere maybe? do you mean there's a cursor planer, generic plane and universal plane?
<chadmed>
there is primary, overlay, and cursor
<leio>
and you think compositors shouldn't use the overlay when cursor one doesn't exist?
skipwich has quit [Ping timeout: 480 seconds]
<chadmed>
in most hardware they behave mostly the same, but cursors are special and they shouldnt be treated the same as content for an overlay
<chadmed>
and we are proof of that
<chadmed>
if the driver has not exposed a cursor plane, it should be assumed that the hardware does not support hardware cursors. its that simple
<chadmed>
theres no point even enumerating a type anymore if we're just going to ignore them
<leio>
but we do want hardware cursors, do we not? You intend to "fake" a cursor plane for that?
<jannau>
the type enumerations are for backward compatibility in the kernel
<jannau>
the kernel needs a cursor plane to emulate the old cursor ioctls
<jannau>
for userspace it's just a hint
<jannau>
HW / drivers can have "arbitrary" restrictions on planes so it makes sense that hardware which has real HW cursor support to export that as cursor plane
<leio>
what I hope we can avoid is that we tie up a plane in a way that it can ONLY be used as a cursor
<jannau>
but hw as apples which has mostly universal planes it doesn't make much of difference
<jannau>
exporting cursor and overlay is not an issue (if we can get a unrestricted cursor plane to work) those don't have to match HW
<jannau>
the only issue is that we can only blend 2 layers (planes)
<jannau>
so it would make sense to only export the primary and overlay plane to inform userspace about this limitation
<leio>
but how do we declare the types; 1) do we mark one as cursor and then expect compositors to see its properties and find it's usable for other purposes too and use it when they deem it useful; 2) do we mark all as (primary +) overlay, as they are full sized and think compositors should pick one for cursor then; 3) something else
<leio>
under blend, you mean blend with alpha channel?
<jannau>
it could then decide if it want to use the overlay plane for an overlay or the cursor
<jannau>
no, also blending/composting with full occlusion (i.e. no alpha blending)
<leio>
what for would you use all 3 at once?
<jannau>
desktop with cursor and the overlay for non-fullscreen video playback
<leio>
is that the same kind of usage as for example having no cursor (as it gets auto-hidden typically by video players) and in its place would be subtitles on top of the video?
<jannau>
subtitles could be handled by using a video underlay instead of an overlay
<jannau>
video player shouldn't hide the cursor if it's not over/under the video or it hasn't pointer focus
aradhya7 has quit [Quit: Connection closed for inactivity]
oneiros has joined #asahi-dev
<leio>
OK, so I think the point here with the terminology is that when you have a video overlay, you seem to be composite them together without alpha blending needed, but you're just "placing" that plane in some specific location and it isn't counting as a blending with the other plane that happens to be lower z-priority (in CSS terms), so only the plane used for cursor ends up being blended on top of the combined visual result of the other 2 or so?
<leio>
that's where I'm mentally blocked right now - how is it not "blending" more than 2 layers
<nicolas17>
what happens when another window partially covers the video player window?
<Nefsen402>
Either that second window is allocated a hardware plane which the hardware will continue to composite both the overlapping surface and the video
<Nefsen402>
or it falls back to software
hightower4 has quit [Remote host closed the connection]
hightower4 has joined #asahi-dev
<nicolas17>
I'm surprised that switching has acceptable latency :P
<Nefsen402>
Switching isn't the hard part. It's really just a matter of reprogramming registers. Nothing in there that could introduce a bunch of latency
<nicolas17>
I mean mostly userspace overhead
<Nefsen402>
Not much goes on in userspace either
<Nefsen402>
However, on AMD, it runs some pretty complex logic (a bunch of machine generated code) to decide if a buffer is viable for use as a hardware plane
<Nefsen402>
and that logic is pretty expensive
<Nefsen402>
don't know how it looks for other hw tho
<jannau>
leio: we might have confused each other. primary + cursor + overlay/underlay at the same time doesn't work
<jannau>
switching might lose 1 frame because userspace notices to late that needs to switch and then has no time left for re-rendering
<jannau>
no direct HW register programming on apple systems though
<jannau>
linux 6.9 is released
<Nefsen402>
Well, yeah, apple has an entire firmware stack between the kernel and the hw, at some point it needs to reprogram registers
<jannau>
sure, but there's overhead before programming regs
<Nefsen402>
Most overhead comes from just bad API design
<Nefsen402>
KMS requires compositors to basically guess what it will be happy with and if not, try another configuration
<Nefsen402>
do that until it hits a deadline then just fallback to compositing
chadmed_ has joined #asahi-dev
<chadmed_>
leio: in our case blending = compositing. we can only have two surfaces
<chadmed_>
again this makes sense given DCP's backstory in the apple sip extended universe
<chadmed_>
now that we've fixed the crashing we can probably find ways around the other silly behaviour. e.g. make the primary plane dest rectangle x+64, y+64 then offset the fb placement on that surface so that the cursor plane technically does not clip the edges of the primary surface
nela has quit [Ping timeout: 480 seconds]
<chadmed_>
idk if that will work of course but its an idea
<Nefsen402>
Is it not possible to just crop the cursor buffer manually as it approaches the edges?
<nicolas17>
in the "DCP backstory" / non-Mac devices, it may even be more common for the video to be in the "background" plane, with controls overlaid
chadmed has quit [Quit: Konversation terminated!]
chadmed has joined #asahi-dev
chadmed has quit []
chadmed has joined #asahi-dev
chadmed has quit []
chadmed has joined #asahi-dev
chadmed has quit []
chadmed has joined #asahi-dev
chadmed has quit []
chadmed has joined #asahi-dev
chadmed has quit []
<jannau>
chadmed_: the issue we had with genpatches was just circular dependencies during config?
chadmed has joined #asahi-dev
<jannau>
chadmed: the issue we had with genpatches was just circular dependencies during config?
chadmed has quit []
chadmed has joined #asahi-dev
* nicolas17
kicks chadmed's modem
chadmed has quit []
chadmed has joined #asahi-dev
chadmed has quit []
chadmed has joined #asahi-dev
<chadmed_>
oh god is my laptop at home having a fit again
<chadmed_>
its some brcmfmac thing
<nicolas17>
broadcom strikes again
<chadmed_>
my internet is rock solid and when im connected via the studio its fine
<chadmed_>
its just over wifi on the j415
<chadmed_>
anyway jannau no if i patch out the circular dependencies the kernel just fails to build. something in there assumes acpi is configured or some such
<jannau>
gcc build has finished, and llvm build looks good so far
<chadmed_>
ill try again tonight then. thats promising though
pb17 has quit [Ping timeout: 480 seconds]
<jannau>
yes, llvm build succeeded as well with https://paste.centos.org/view/b4e11d0e could of course be a config issue. This was with the plain fedora config and chosing the default in `make oldconfig` except for GENTOO_INIT_SYSTEMD
<nicolas17>
RANDSTRUCT breaking it smells like something relying on struct layout in a way it shouldn't
<chadmed_>
yeah, all of the rust bindings :p
<chadmed_>
theres efforts to sort that out in upstream r4l aiui