Overlay issues

[Cornij, Nikola]

[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 at emersion.fr> 
Sent: Tuesday, December 15, 2020 2:58 AM
To: Cornij, Nikola <Nikola.Cornij at amd.com>
Cc: Alex Deucher <alexdeucher at gmail.com>; Kazlauskas, Nicholas <Nicholas.Kazlauskas at amd.com>; Deucher, Alexander <Alexander.Deucher at amd.com>; Wentland, Harry <Harry.Wentland at amd.com>; amd-gfx list <amd-gfx at lists.freedesktop.org>
Subject: Re: Overlay issues

On Tuesday, December 15th, 2020 at 5:09 AM, Cornij, Nikola <Nikola.Cornij at 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