If it doesn't happen with older GPUs, it's more likely a kernel driver issue.

Does hacking drmmode_cm_enabled to return FALSE avoid the problem?

This needs to be forced in amdgpu DDX? If so, could you provide a patch?

Before you try this, run xrandr --prop | grep LUT_SIZE and let us know the value of the (DE)GAMMA_LUT_SIZE properties.

Both color and cursor look correct with the patch applied.

Thanks for confirming. Since the LUT size is 4096 as well with an RX 5500 XT here, it's hard to imagine how this could be an xf86-video-amdgpu issue, moving to the kernel driver.

As I pointed out in my recent comment (two years later :-)), the GAMMA_LUT_SIZE value seems to stay the same, however the GAMMA_LUT does not.

It is at 117 when the cursor is correct and changes to 123 when the issue happens.

Thanks, I've applied both patches to linux 5.12-rc3 and indeed the GitHub blue is once again blue instead of turquoise. However, the hardware cursor still has a too dark gamma.

We did indeed only use "limited" (legacy) gamma before, now with atomic gamma the cursor is a lot darker than it should be.

Any workaround for us folks using the Plasma Wayland session?

Is there a workaround for people using the Plasma Wayland session? Would it be feasible to alter the gamma on the cursor files to compensate for this bug?

Is there no way to achieve a software cursor on Wayland, or any other workaround?

The mouse cursor looks horrible on these graphics cards but I would hate to have to return my card just because of a buggy cursor.

You can use KWIN_DRM_NO_AMS=1 to force the legacy driver API to be used, which makes KWin fall back to legacy gamma ramps

That fixed it! Many thanks @Zamundaaa. Any thing important I'll be losing by using that setting?

I also posted this workaround on the issue on the KDE Bugtracking.

As a complete noob in this context, could you please let me know where I should update this value? And could you confirm whether or not it would also work on an Xorg session? Many thanks.

@saluki You can place it anywhere that loads environment variables. On Arch, I've set it on /etc/environment to make it global, for example. Not sure about other distros.

Doesn't seem to work on Xorg for me. Alternatively, as a workaround on Xorg, you can set your AMD GPU to use a software cursor until this is fixed.

Thanks for the reply! And sorry to bother you again, but could you point me towards getting my GPU to use a software cursor?

I have this issue as well.

System info:

Adding KWIN_DRM_NO_AMS=1 to /etc/environment and logging out and back in fixed it. However the issue seems to still be in SDDM.

Update for KDE users:

Use KWIN_FORCE_SW_CURSOR=1 environment variable for fixing this temporarily: KWIN_DRM_NO_AMS may cause other issues with the cursor.

I confirm this also fixes it for me.

KWIN_DRM_NO_AMS may cause other issues with the cursor.
What issues in particular?

I think non-atomic modesetting is unsupported-ish by recent Wayland compositers, imho don't go there for a cosmetic issue.

Still it would be nice if this got fixed in amdgpu, a patch fixing this might be just a few lines of code (uneducated guess)...

@aufkrawall Unfortunately this bug and this other bug forces us to to use KWIN_DRM_NO_AMS. It's pretty bad that these bugs are still present on RDNA 2 cards. I wonder if the new RDNA 3 will suffer from the same fate.

EDIT: The other bug I mentioned is related to this instead.

The workarounds listed here are for Xorg or Plasma Wayland. I'm using the sway Wayland compositor, is there anything that can be done against the darkened cursors in this case?

Coming in from closed issue #2459 (closed) and I'm noticing some fixes but I can't seem to apply them because I do not know how to. I'm using Plasma X11 and GNOME X11 with an 6800 XT Red Dragon (Powercooler) some people have mentioned something about modesetting? How would I move to that?

Create a file in /etc/X11/xorg.conf.d/ with these contents:

The filename has to end in ".conf". Name the file for example 20-modesetting.conf.

The line about "Identifier" is to help with searching in the Xorg log file. You can search for the identifier text in the log file to check for messages about your config.

The line about "Driver" forces the use of the "modesetting" Xorg module that you heard about.

The line with the "UseGammaLUT" option is what fixes the wrong color of the cursor.

You might want to add other options to this file. You can find the available options in man modesetting. There's for example "VariableRefresh" to enable FreeSync support.

That did it, thank you so much! This has been driving me nuts for a really long time and I thought it was just a me issue. Hope to see this permanently resolved someday.

What would be the configuration for kwin-wayland?

I can also confirm that this is still an issue with an RX 7900 XTX on Linux 6.3.0 (Plasma/X11); and that it did NOT affect an RX 5700 XT on a similar system.

Things look sane if I apply the hack from #1513 (comment 826647)

I guess this is not an RDNA 2 exclusive issue then. Maybe the title should be changed then.

As of Fedora 38 this issue is still appearing, although it no longer occurs in SDDM with the default settings.

I've done some experimenting on GNOME as some users reported not experiencing this issue on RNDA2 when they are on GNOME and I can consistently get the cursor to display correctly but when you cause the screen to flicker by changing resolution or refresh rate the cursor gets the wrong gamma. A reboot will get the cursor to display correctly again.

Can you run drm_info while GNOME is displaying the cursor correctly, and attach the output here?

Thanks for providing the file. Did you also have the intermittent issue or is it just working constantly?

And I haven't noticed it render properly since that message, so unfortunately I haven't been able to generate my own DRM info yet.

I haven't used it long enough to figure out whether it was intermittent or not.

AFAICT the HW cursor isn't being used, which would explain why the cursor looks correct.

There may be a message from mutter in the journal about why it fell back to SW cursor.

I wasn't able to find anything in the journal myself, is there something specific I need to run?

or just

and search for messages from gnome-shell.

This is what I got from restarting and then causing it to back to the hardware cursor. Also now that you've mentioned it I can feel that it is a software cursor.

Maybe the cursor was just hidden when drm_info ran, e.g. because the terminal hid the cursor while typing.

Are there any known workarounds for this issue with GNOME/Mutter? I'm using Fedora Workstation with Wayland and setting the KWIN_DRM_NO_AMS=1 variable seems to work sometimes (although I doubt it is actually causes the cursor to render correctly, as it is a KWIN variable).

Try MUTTER_DEBUG_FORCE_KMS_MODE=simple or MUTTER_DEBUG_ENABLE_ATOMIC_KMS=0

Thanks for the suggestions. I tried both of these variables separately, to no luck (or change).

The same issue with cursor shape/colors changing also started happening on my desktop computer (running GNOME Wayland session with AMD RX 6600 XT GPU) since upgrading to Fedora 38. I have originally reported it here. It happens almost every time after user login and sometimes even directly in GDM. When this happens, the incorrect cursor stays the same between logins and the only way to get rid of it is a reboot.

Here is how the bad mouse pointer theme looks like:

I apologize for the bad quality, however I had to take an actual screen shot (with my phone :-)), because it is not possible to capture the incorrect cursor using software screenshot tools (it shows as a correct one). You can however still see the missing color gradient, bigger aliasing on the edges and a slightly different shape than the correct cursor.

Here are drm_info outputs from two sessions with bad cursor and two sessions with the correct one:

drm_info_bad_cursor

drm_info_bad_cursor2

drm_info_correct_cursor

drm_info_correct_cursor2

When doing diff between these logs, I have noticed that the GAMMA_LUT value is always different between bad and correct sessions, but stays the same when comparing two correct or two bad sessions.

bad cursor session:

correct cursor session:

It is always at 123 when the cursor is bad and at 117 when the cursor is correct.

Here is my system hardware configuration:

hwinfo.txt

dmidecode.txt

I have also noticed that the same issue happens when booting a live Fedora 38 iso on this machine (but does not happen on my other machines with Intel and NVIDIA GPUs), so it is not a problem related to my local system/software configuration.

Here is a complete journal boot log from the Fedora 38 live system with the cursor bug also reproduced:

log.txt

I have already mentioned that the bad cursor is not present on screenshots. I forgot to add that when recording a screencast using the integrated GNOME screencast tool, the cursor also changes to a correct one and changes back to the incorrect one after the recording gets stopped. When selecting not the whole screen, but only a screen area for the recording, it gets even more interesting: The cursor inside this area is a correct one, but changes to a wrong one when exiting the area. I have made a recording using my phone camera:

cursor

It is not a very good quality recording, however there is clearly visible how the cursor changes on its edges + there was a moment or two when there actually were two cursors displayed for a short time.

AFAIK this is because mutter uses SW cursor during screen grabbing.

I have also noticed that if I turn off my monitor for an extended period of time (for example overnight), the cursor also often changes to an incorrect one.

Two years on and this is still an issue. 7900XTX.

Very annoying, happens with any wlroots based compositor. The only fix is to force software cursors which is a workaround not a proper solution.

I will note that in addition, the image is scaled very poorly and looks very aliased compared to rendering it in software.

Yeah, this has existed for way too long. Is AMD directly responsible for fixing this? I might get in touch with someone over there.

Since software cursors fix it and hardware cursors are handled by the GPU I can't see it being able to be fixed by anyone else.

edit: And there is a patch that looks like it works here: #1513 (comment 826647) it just hasn't been applied

Is the issue really two years old? It did not happen for me on older Fedora releases, but started happening since Fedora 38. But yeah, this bug sadly is extremely annoying especially since it happens randomly, but really often, and usually requires several system reboots to disappear.

this issue was created in March 2021 so over 2 years 😞

Even a hacky kernel parameter to force the patch above would be better than nothing.

Ah, you are right about the ticket creation date. I wonder why it did not happen on my AMD system when using Fedora 37 or older. Maybe it also depends on an AMD GPU binary firmware version (shipped in Fedora as part of linux-firmware) or other system package that used to stay on older version before Fedora 38? But this is just a pure speculation.

I also wasn't running into it only on Fedora 37, all other distros i've tested were affected, but Fedora somehow wasn't, even with the same package versions and all that. I had checked the mutter patches that Fedora carries, but didn't notice anything interesting. So I am really not sure what has changed. Maybe something between Mutter (GNOME's compositor) v43 and v44?

It can be worked around by setting the MUTTER_DEBUG_FORCE_KMS_MODE=simple env variable in /etc/environment and rebooting.

This issue isn't present with legacy gamma ramps, so perhaps mutter changed something between 43 and 44. While there may be dirty hacks compositors can apply to work around this issue, this still needs to be fixed in amdgpu itself.

Just as a note, my patch in #2186 which uses the legacy API for setting the cursor, along with another patch that uses the legacy API for setting gamma does not fix this issue. So it probably isn't related to the API.

Any chance you could mention this also in the original GNOME ticket? Thanks!

I do not use GNOME so that would be irresponsible to do so since I can't verify it myself, I'm just repeating what has been said earlier by a KDE dev in this issue already and my own findings playing around with wlroots.

I've been seeing this since the very first day I installed my RX 6600 XT as an upgrade from an RX 580, which was on Solus Budgie in August 2021 - the bug continued to happen when I switched to Arch Budgie. It also happens on my Ryzen 5 6650U laptop, running EndeavourOS Budgie, and on my partner's Steam Deck in desktop mode, and my research project wlroots compositor. So yes, it's been happening for two years, and it's still happening on both X and Wayland on seemingly all RDNA2 and RDNA3 cards.

As an addendum to the above, I've heard through the grapevine that this was also an issue with RDNA2 cards on Windows at some point before being resolved. That implies that this is a hardware quirk that requires special handling. I don't have any evidence for this, though - it's just hearsay.

It can be worked around by setting the MUTTER_DEBUG_FORCE_KMS_MODE=simple env variable in /etc/environment and rebooting.

That's only helpful if you're on mutter, it looks like WLR_DRM_NO_ATOMIC=1 should work for wlroots based compositors but it's not for me on Wayfire.

It looks like that adding MUTTER_DEBUG_FORCE_KMS_MODE=simple to /etc/environment did work around the issue on my Fedora Workstation 38 (GNOME Wayland) system. Thanks a lot! :-)

Does MUTTER_DEBUG_FORCE_KMS_MODE=simple cause issues like KWIN_DRM_NO_AMS does on KDE?

@tobyg I've seen people mentioning issues with KWIN_DRM_NO_AMS but no one ever gave me examples of those issues. Are you aware of any in particular?

If it's of any use, this is the hardware cursor on Steam Deck. You can try each cursor by hovering over it in the cursor appearance settings dialog. The dark cursor is hardware, the preview behind it shows the correct colors/gamma you would see in software mode:

That is pretty insane that this is also affecting the Steam Deck, I wonder if talking to Valve could get someone to look into this as I know that they contract developers to work the AMDgpu driver.

@tobyg Yeah, that's a good idea. If enough people complain there, they might get someone to look into it.

It seems we need to change the base for DGM/RGM in the atomic gamma of the kernel-driver. Can you compile/install a custom kernel and test the change suggested by this patch:0001-drm-amd-display-set-SRGB-as-a-base-to-avoid-too-dark.patch?

@mwen Hey, thanks for the patch, it seems to make the Breeze cursor gray (as it should be) on KDE Wayland without having to use legacy modesetting or a software cursor.

This is on a desktop with an RX 6800, but i'd imagine it would also solve it for the Steam Deck, considering it also has an RDNA2 GPU.

@kostadinsh are you sure you tested correctly? It doesn't seem to fix the issue for me on 6600 XT, which is also an RDNA2 gpu :(

edit: apparently after this patch, the issue is only reproducible on wlroots-based compositors. no idea why

@llyyr The patch doesn't work on GNOME Wayland either, I believe I applied the patch correctly so not sure why.

To add I'm using a 6700 XT.

edit: Tested it on KDE Wayland and cursor appears as it should.

@mwen's patch did the trick for me on KDE/X11, FWIW; thanks!

Great news that this seems to be working to some people. Any hopes of this being merged? Is it a proper fix, or a hack?

So, is this fix only for KDE or does it also work on other DEs including GNOME?

From reports, it seems to only address the issue for KDE.

It's not the proper fix yet, I'm still investigating. Thanks.

Very likely this is the proper fix: 0001-drm-amd-display-set-cursor-degamma-on-DCN3-only-if-i.patch

Let me know the result on your desktop environment (don't forget to discard the previous patch). Thanks.

@mwen: Yup, that one also works over here! (KDE/X11 on a 7900 XTX)

@mwen Thanks! that fixes it for me on RDNA2 on wlroots-based compositors

@mwen Works on both KDE and GNOME Wayland, thanks!

Hi all, this patch was accepted and applied to AMD and stable trees. Can we close this issue?

That's great news! :-) Thanks a much for your great work Melissa and other folks from Igalia!

Thank you Melissa - great work!

Just upgraded to 6.4.11, and my cursor gamma is fixed on Budgie (X11)! Thanks Melissa 😄

I now seem to have a very strange, opposite issue on my Fedora 38 system. My mouse pointer (on GNOME Wayland) looks too bright after updating to kernel 6.4.11. :-)

(Sorry for the bad quality. It is an actual photo since the cursor looks correct on a screenshot.)

Here is a drm_info output: drm_info_bright_cursor

Both the GAMMA_LUT and GAMMA_LUT_SIZE values seem to be correct, so I am not sure what is wrong.

Anyway, it is not annoying like the previous issue and seems to stay the same between reboots (unlike the previous issue), so I consider it a minor issue when compared to the original one. :-)

ugh 😞 I have an idea of what is the missing part: I guess the sRGB degamma in the legacy mode doesn't apply to cursor (only to other planes) and I need to enable cursor degamma separately for the legacy case. But let me examine the legacy path a little more to have a better idea that it's not just a workaround.

Thanks @asciiwolf and @Zamundaaa for reporting.

FWIW, I'm continuing this discussion at #2803 (closed)