07:43 <chadmed> yeah the overlay planes are definitely being used, neat

08:20 <jannau> chadmed: only yuv format I tested so far is iirc "v024". it will need more setup in iomfb.c since it is multi-planar

08:35 <chadmed> jannau: ack

08:35 <chadmed> mpv definitely uses the hardware planes properly and kwin knows about them but just ignores them

08:35 <chadmed> tested both kwin_wayland and kwin_x11

08:36 <chadmed> no errors or anything, it knows theyre there and enumerates their supported formats etc properly. it just doesnt use them at all

08:36 <chadmed> at least according to drm_info

08:40 <marcan> yeah, getting this plumbed through the desktop stack is... not going to be easy

08:40 <jannau> I'm unsure about the state of direct scan-out for overlay planes kwin_wayland. I think it worked at some point for yuv but I don't think itworks at the moment. it should work in weston

08:40 <marcan> even chrome and firefox *on macOS* don't know how to do this

08:41 <marcan> jannau: we gave up on cursor support right? no good solution for the edge crop issue :(

08:41 <jannau> not sure if mpv automatically tries to use it though. it's probably pointless with vo opengl

08:41 <marcan> (without workarounds like padding the bitmap in kernel space)

08:44 <jannau> more or less, I wanted to try what happens if I reject a too far off-screen cursor in atomic_check but I would expect all kninds of broken desktops

08:44 <chadmed> mpv by default only uses one plane, i forced it by passing --drm-drmprime-video-plane=primary --drm-draw-plane=overlay

08:45 <jannau> the old cursor api was nicer for our use case

08:47 <jannau> I don't see a way to support hw cursors if we don't have a way to communicate to userspace that we need 31 pixel padding left and right of the cursor

08:48 <chadmed> format modifier? but then everything would have to support it i suppose

08:52 <jannau> another problem with hw cursor support is that we might need to use plane[1] for cursor. I don't remember if I tricked myself with the fake argb2101010 support of if blending plane[2] onto plane[1] didn't support transparency

08:53 <chadmed> is one of those the iboot framebuffer that we cant get rid of for some reason?

08:53 <chadmed> or did that get fixed

08:57 <jannau> no, the issue is that plane[0] seems to support only apple's wide RGB colorspace for 10-bit pixelformats

09:02 <chadmed> ahh right

09:07 <jannau> marcan: hw cursor support with copying when the cursor is too far off-screen is probably still a performance/power improvement even if it is usgly

09:07 <jannau> not to speak of sw cursor bugs it would fix silently

09:11 <marcan> yeah, probably worth it with a limited plane dimension to make sure compositors don't try to use it for non-cursor things?