[AMD Public Use] Yeah, but... it works with bigger FBs (300x300). So looks like some clipping somewhere works OK until a corner-case is reached. -----Original Message----- From: Simon Ser <contact@xxxxxxxxxxx> Sent: Tuesday, December 15, 2020 2:58 AM To: Cornij, Nikola <Nikola.Cornij@xxxxxxx> Cc: Alex Deucher <alexdeucher@xxxxxxxxx>; Kazlauskas, Nicholas <Nicholas.Kazlauskas@xxxxxxx>; Deucher, Alexander <Alexander.Deucher@xxxxxxx>; Wentland, Harry <Harry.Wentland@xxxxxxx>; amd-gfx list <amd-gfx@xxxxxxxxxxxxxxxxxxxxx> Subject: Re: Overlay issues On Tuesday, December 15th, 2020 at 5:09 AM, Cornij, Nikola <Nikola.Cornij@xxxxxxx> wrote: > [AMD Public Use] > > Hi Simon, > > Just to keep you updated, I've reproduced issue '[1] - Overlay plane: > position not updated when CRTC_X is negative' on Ubuntu using IGT. > Seems to happen only with smaller FBs (so far tried 24x24 and I can > repro, but 300x300 is OK). > > I'll look into fixing this. Thanks for the update and for looking into this! Let me know if I can help with anything. Nicholas replied on the issue tracker that overlay planes couldn't have negative positions, so I was thinking of having a look at the SRC_Y handling (see if we can do the same for SRC_X), experimenting with FB sizes and SRC_W/H to figure out what's the overlay max size still triggering the bug. If we really can't emulate neg SRC_X we should fail atomic commits with negative SRC_X by returning EINVAL (so that user-space can fall back to not using the plane in this case). Simon _______________________________________________ amd-gfx mailing list amd-gfx@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/amd-gfx
