[Ryzen 4700U, rx 6800XT, Steam Deck] Cursor bugs with hardware rotation

There's two problems I see with the primary plane rotation property being set to rotate-180 or rotate-270:

1. when CRTC_X or CRTC_Y of the cursor plane are negative, the whole cursor plane turns invisible
2. in the middle of the screen, the cursor plane gets clipped off. In some other places, there's even a stripe of the cursor appearing where it gets clipped off in the middle

Neither of these artifacts happen with rotate-0 or rotate-90.

This was discovered in the context of https://invent.kde.org/plasma/kwin/-/merge_requests/2269, which I patched to make the buffer for the cursor plane have a white background instead of transparency. This shows exactly what's happening: VID_20221103_180716

added DC label

changed title from [Ryzen 4700U, rx 6800XT] Cursor bugs with hardware rotation to [Ryzen 4700U, rx 6800XT, Steam Deck] Cursor bugs with hardware rotation

Managed to test on the Deck, the cursor also disappears with hw rotation when CRTC_X or CRTC_Y are negative. In addition, I found these artifacts (at rotation-270): VID_20221115_132133

Hi @Zamundaaa

I think these two patches address the cursor bugs on hw rotation 180 and 270:

1. https://lore.kernel.org/amd-gfx/20221118125935.4013669-22-Brian.Chang@amd.com/
2. https://lore.kernel.org/amd-gfx/20230131160546.150611-1-mwen@igalia.com

I tested using DCN 2.1 HW with KDE development environment where I included the HW rotation change from the MR you linked. There are some hooks regarding cursor position for HUBP and DPP AMD DC blocks that they set by HW family. Checking the code of DCN 301 (Steam Deck), it seems properly hooked via generic DCN 3.0 funcs. Can you check on the HW your have available to confirm?

In any case, I just sent the last patch, so I'm waiting the feedback of AMD developers. If it's helpful for testing, I pushed the change on top of amd-staging-drm-next kernel here: https://gitlab.freedesktop.org/mwen/linux-amd/-/commits/fix_rotation_180 where you will also find the above-mentioned patch already applied: https://gitlab.freedesktop.org/mwen/linux-amd/-/commit/5fe222152cc316b64229a8818cdf4b6442427ebf

I tested your fix_rotation_180 branch on my laptop and everything worked correctly. I'll test on the Deck as well

I tested on the Deck with kernel 6.1 and the fix_rotation_180 branch, with both the cursor doesn't disappear anymore but the weird artifacts from my other comment still happen with rotation-90 and rotation-270.

Just to confirm, with fix_rotation_180 branch:

1. you see those artifacts only on the Deck but you don't see/reproduce the issue on your laptop or other HW, right?
2. Is your laptop the Ryzen 4700U?
3. Does rotation-180 work fine on the Deck?

Yes, I see them only on the Deck.

Is your laptop the Ryzen 4700U?

Yes

Does rotation-180 work fine on the Deck?

0 and 180 show no problems, only 90 and 270 are affected

ugh, I found a weird behavior that I want to confirm if it's happening on your side. Do these artifacts appear when your deck isn't connected to charger? Or with and without the charger?

Until now I only tested without a charger. Having it plugged in, the artifacts no longer happened at first, but once I opened system settings it started again.

Can you check if this branch glitches_cursor_rotation (last comit) reduce or increase the artifacts on steam deck screen? The patch file is also attached (rebased on amd-staging-drm-next) [1]. If not, can you also try to change the same line of this commit to these other two values:

• dst_x_offset = (src_x_offset >= 0) ? 2 * src_x_offset : 0;
• dst_x_offset = (src_x_offset >= 0) ? src_x_offset / 4 : 0;

Some context: in the Deck driver, the pipe split policy is set to AVOID and therefore, there isn't pipe splitting, only one pipe. I don't see the issue in my laptop because the driver allows pipe splitting, but if I change the policy to the same of the Deck driver with only one pipe, then I can reproduce the issue when rotating screen. I'm suspecting some miscalculation around bandwidth and I see some clk values in the dst_x_offset equation. By changing the dst_x_offset value, the glitches disappear on my side, can you check if it has the same effect on your side?

Thanks

[1] 0001-drm-amd-display-halve-dst-offset-value.patch

until now I haven't seen any glitches with that branch

Thanks for testing!

mentioned in commit agd5f/linux@81da609d

mentioned in commit agd5f/linux@5dbfcd25

mentioned in commit agd5f/linux@49d05559

For the records, I sent a upstream patch that tries to address these artifacts: https://lore.kernel.org/amd-gfx/20230207233235.513948-1-mwen@igalia.com/ I'm waiting for feedback from AMD folks.

mentioned in commit nouveau@5af27a53

Hi @mwen @Zamundaaa , Recently we changed how DC commit sequence happens (check: https://patchwork.freedesktop.org/series/114632/); in this sense, could you try the below patch on top of the latest amd-staging-drm-next?

https://patchwork.freedesktop.org/patch/526108/?series=114927&rev=1

mentioned in commit agd5f/linux@a4c89726

mentioned in commit agd5f/linux@75b204ee

mentioned in commit agd5f/linux@91440d6b

added Vangogh label

@Zamundaaa Did you have a chance to validate the latest amd-staging-drm-next for this issue?

right, sorry, I completely forgot about this. I'll test it later today

I can confirm that it works without problems

Hi @Zamundaaa , thanks for checking.

closed