You are not logged in.
Hello, All
I am 4 days into a fresh arch install and things are going great. I made the mistake of trying to get openrgb installed, which crashed my pc or slowed down my startup significantly so I uninstalled it. Using
yay -Rns openrgp-git Since reboot, I am getting the exact same bug described on this post on KDE forum: https://gitlab.freedesktop.org/drm/amd/-/issues/4057
I am using Displayport in my case.
I have windows on the same machine (different drive) and no issues there, so I dont think its hardware or cable related. I tried HDMI and HDMI works fine on either setting (it may be possible the HDMI i have does not try to push the same color through). I have also tried a fresh out of package displayport and I run into the same issue.
Another interesting thing is that on login (SDDM) both monitors are perfectly fine, its just when I am in plasma proper.
I am not sure what to do, I have tried installing/updating plasma again with
yay -S plasmaI believe i am replacing what I have (i select [A]ll when prompted).
Im a bit at whits end, works perfectly fine in Preffer Efficiency as the post above mentions, but supposedly this was fixed. And it was working and I played a few games on steam everything seemed fine until I tried to get OpenRGB working.
System Info:
Operating System: Arch Linux
KDE Plasma Version: 6.5.1
KDE Frameworks Version: 6.19.0
Qt Version: 6.10.0
Kernel Version: 6.14.0-rt3-arch1-3-rt (64-bit)
Graphics Platform: Wayland
Processors: 16 × AMD Ryzen 7 9800X3D 8-Core Processor
Memory: 32 GiB of RAM (30.5 GiB usable)
Graphics Processor 1: AMD Radeon RX 9070 XT
Graphics Processor 2: AMD Ryzen 7 9800X3D 8-Core Processor
Manufacturer: Gigabyte Technology Co., Ltd.
Product Name: X870E AORUS ELITE WIFI7
System Version: Default string-CF-WCP-ADO
Let me know what logs or other details I can provide. The help is greatly appreciated.
Last edited by Greenmeep (2025-11-06 16:59:40)
Offline
You're using an (old) RT kernel, why exactly? And can you repro on the normal kernel? The bug report you posted mentions this is fixedd after 6.15.5 and we're on 6.17.7 now. I'm not sure why the RT kernels are still lagging behind, as the RT patches should be upstreamed and it should be possible to build current kernels with the RT guarantees, but unless you know exactly why and what for you should probably not default to them.
Also since switching the color profile logic helps, why do you want to select "accuracy", is your screen properly configured and calibrated to properly make use of advanced color information? Generally speaking openrgb should not have any lasting effects anyway, all of it's changes are normally transient and reapplied only when the relevant server starts anew. If this indeed flipped some firmware bit "magically" you probably want to try a hard reset or so (do a UEFI update, and/or shutdown your PC and trigger the UEFI reset or so)
Offline
Offline
You're using an (old) RT kernel, why exactly? And can you repro on the normal kernel? The bug report you posted mentions this is fixedd after 6.15.5 and we're on 6.17.7 now. I'm not sure why the RT kernels are still lagging behind, as the RT patches should be upstreamed and it should be possible to build current kernels with the RT guarantees, but unless you know exactly why and what for you should probably not default to them.
Also since switching the color profile logic helps, why do you want to select "accuracy", is your screen properly configured and calibrated to properly make use of advanced color information? Generally speaking openrgb should not have any lasting effects anyway, all of it's changes are normally transient and reapplied only when the relevant server starts anew. If this indeed flipped some firmware bit "magically" you probably want to try a hard reset or so (do a UEFI update, and/or shutdown your PC and trigger the UEFI reset or so)
Awesome and thanks so much for the response,
I believe I may have installed that rt-kernel when I was in a rabbit whole trying to get something else working, probably when troubleshooting Openrgp. I believe I have the other kernels installed.
find /boot/vmli* shows me:
/boot/vmlinuz-linux
/boot/vmlinuz-linux-rt I have GRUB, how would I go about checking the standard version is up to date, as well as making sure I boot to that by default?
As for why, color accuracy mode allows 16bit color, in color efficiency stops at 10. 100% might be placebo but I notice some things off as I have dual monitors, and somehow the nicer one (the one that flickers) has worse colors than my old one.
Are there any GUI methods to adjust color vibrance like in windows in linux?
Thanks again for the help!
Last edited by Greenmeep (2025-11-06 16:33:26)
Offline
I was able to switch to standard linux kernel via the sub-menu on GRUB on reboot.
No more flickering!
Operating System: Arch Linux
KDE Plasma Version: 6.5.1
KDE Frameworks Version: 6.19.0
Qt Version: 6.10.0
Kernel Version: 6.17.7-arch1-1 (64-bit)
Thank you for pointing that out, I for the life of me could not catch why or when this started happening, and did not occur to me that rt might be some versions behind or that I may have the older version.
I would assume we are all here and like to tinker, probably more than we should, is there a preferred snapshot/backup tool or similar that you would recommend so that I can rollback after doing something stupid?
Thank you all again!
Offline
Yes grub-mkconfig has a sorting logic when generating the entries list, which will make "more specialized kernels" lexographically more important and order them as the default. See https://wiki.archlinux.org/title/GRUB#S … menu_entry and/or https://wiki.archlinux.org/title/GRUB/T … le_entries for mitigation options for the kernel selection.
As for backup and rollbacking tools, kernel changes are somewhat a special beast and most back up solutions would probably not have caught this properly. If you're using BTRFS it's fairly easy to configure install and update snapshots but especially configuring kernel snapshots correctly can be somewhat finicky (especially so if your /boot is a distinct (FAT) partition), but I feel doing an in-depth discussion on this would be out of scope here, so my best general advice would be to be more weary of which kind of changes you are doing and how they can affect your current system state. Other than that something people often use in this space is https://wiki.archlinux.org/title/Timeshift -- but I have no real hands on experience and I feel this to be off-topic here.
Last edited by V1del (2025-11-06 17:01:39)
Offline
Yes grub-mkconfig has a sorting logic when generating the entries list, which will make "more specialized kernels" lexographically more important and order them as the default. See https://wiki.archlinux.org/title/GRUB#S … menu_entry and/or https://wiki.archlinux.org/title/GRUB/T … le_entries for mitigation options for the kernel selection.
As for backup and rollbacking tools, kernel changes are somewhat a special beast and most back up solutions would probably not have caught this properly. If you're using BTRFS it's fairly easy to configure install and update snapshots but especially configuring kernel snapshots correctly can be somewhat finicky (especially so if your /boot is a distinct (FAT) partition), but I feel doing an in-depth discussion on this would be out of scope here, so my best general advice would be to be more weary of which kind of changes you are doing and how they can affect your current system state. Other than that something people often use in this space is https://wiki.archlinux.org/title/Timeshift -- but I have no real hands on experience and I feel this to be off-topic here.
Thanks again, I will do some research, I took a very quick peek at Timeshift and it seems to accomplish what I am looking for. I will give it a deeper look.
Offline