[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 <cont...@emersion.fr> Sent: Tuesday, December 15, 2020 2:58 AM To: Cornij, Nikola <nikola.cor...@amd.com> Cc: Alex Deucher <alexdeuc...@gmail.com>; Kazlauskas, Nicholas <nicholas.kazlaus...@amd.com>; Deucher, Alexander <alexander.deuc...@amd.com>; Wentland, Harry <harry.wentl...@amd.com>; amd-gfx list <amd-gfx@lists.freedesktop.org> Subject: Re: Overlay issues On Tuesday, December 15th, 2020 at 5:09 AM, Cornij, Nikola <nikola.cor...@amd.com> 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@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/amd-gfx
