There are two versions of SDDM in the repositories.
What is the output of
zypper se sddm
Might be this is the missing link.
I just installed the plasma patterns to see if I will have a problem with SDDM. So far it’s all good. I am using nvidia maybe that’s why I am not affected.
hi Fltlander2,
thanks for sharing, that fixed to problem for me too. laptop now back to normal.
cheers
1 Like
Thank you for sharing @Fltlander2, it works 
Let’s just hope Mesa comes with a fix soon.
The 24.0.3-372.1 version of Mesa appears to have resolved my issue. I removed all the locks, ran zypper refresh and zypper dist-upgrade followed by rebooting – and SDDM is now displayed and interactive as I expect it to.
Logging in after boot works, but SDDM or the screen locker will freeze after the monitor has been turned off after the default value of 10 minutes.
1 Like
Update to 24.0.3 didn’t make a difference for me, same issue.
1 Like
Doesn’t work for me. Still need “modprobe.blacklist=radeon” in grub conf to get any graphic display.
hi @Fltlander2
I have a similar problem and after the update I made these changes and currently able to log in via X11.
I really want to better understand what these options are doing so If it happens again I can troubleshoot this issue by myself.
Thanks!
The link in your thread is adding the amdgpu-pro (AMD proprietary) driver, which the fix I posted above enabled the amdgpu (Opensource) driver which is included in the kernel instead of the radeon (Open source) driver.
Without the context of your GPU and possibly CPU, this report has no meaning, except to show you’ve done a good job of preventing a multitude of AMD GPUs from doing their jobs competently. There are currently known issues in TW with AMD’s si and cik GPUs that do have satisfactory workarounds in their various bug reports.
With which AMD GPU?
Latest mesa update (24.0.5) seems to have fixed the problem for me.
Mesa 24.0.5 has fixed the problem for me too (I have an AMD Southern Islands GCN-1). I could remove all the workaround options I had put in grub conf (modprobe.blacklist=radeon amdgpu.cik_support=0 amdgpu.si_support=1) and everything works fine.
Exactly: The OS’s were not bootable with the radeon driver. At least with it disabled kde desktop was available.
Reading from other bug reports all functionality was restored with the following line in the boot loader parameters,
modprobe -r radeon radeon.cik_support=0 radeon.si_support=0 amdgpu.cik_support=1 amdgpu.si_support=1
cpu and gpu references were not given as the failing was more generic than relevant to specific versions.
When you say that everything works fine with which drivers? The AMDGPU proprietary?
That is a shell command to (attempt to) unload the radeon kernel module, not a command line parameter.
These two do nothing unless the installed GPU is an AMD Southern Islands (GCN #1) model, in which case they disable the (older technology) radeon kernel module, and enable the (newer technology, “experimental”) amdgpu kernel module.
These two do nothing unless the installed GPU is an AMD Sea Islands (GCN #2) model, in which case they disable the (older technology) radeon kernel module, and enable the (newer technology, “experimental”) amdgpu kernel module.
AFAICT, the problems reported were all specific to GCN #1 and GCN #2 AMD GPUs, and only to those who were using them with the (default) radeon kernel module. I have both GCN #1 and GCN #2 models. Since mine were specifically configured to utilize the so-called “experimental” amdgpu kernel module, I was unable to observe the reported problems, until I dis-configured use of the amdgpu kernel module and enabled use of the old-technology radeon module. Now that Mesa in TW20240426 has been upgraded from 24.0.3 to 24.0.5, I am unable to reproduce radeon module breakage on either my GCN #1 or my GCN #2.
No, I only have the opensource drivers radeon and amdgpu. It looks like I’m using the previously-broken radeonsi driver now without mishap. Here is my inxi output.
inxi -Gxxz
Graphics:
Device-1: AMD Oland [Radeon HD 8570 / R5 430 OEM R7 240/340 Radeon 520 OEM]
vendor: Dell driver: radeon v: kernel arch: GCN-1 pcie: speed: 5 GT/s
lanes: 4 ports: active: DVI-I-1 empty: DP-1 bus-ID: 04:00.0
chip-ID: 1002:6611 temp: 35.0 C
Display: x11 server: X.Org v: 21.1.12 compositor: xfwm4 v: 4.18.0 driver:
X: loaded: modesetting unloaded: fbdev,vesa dri: radeonsi gpu: radeon
display-ID: :0.0 screens: 1
Screen-1: 0 s-res: 1920x1080 s-dpi: 96
Monitor-1: DVI-I-1 model: Dell S2409W res: 1920x1080 dpi: 92
diag: 609mm (24")
API: OpenGL v: 4.5 vendor: amd mesa v: 24.0.5 glx-v: 1.4 es-v: 3.2
direct-render: yes renderer: OLAND (radeonsi LLVM 18.1.4 DRM 2.50
6.8.7-1-default) device-ID: 1002:6611
API: Vulkan Message: No Vulkan data available.
Prior to the Mesa 24.0.5 update, I had exactly the same problem as OP, which I could fix by putting “modprobe.blacklist=radeon” in my grub configuration file. I could remove this option without any problem after the Mesa 24.0.5 update.
AMD Oland Southern Islands GCN-1
I’m glad you and other thread participants seem to be happy now. But for this thread, other threads elsewhere, and bug reports about trouble exclusive to Sea Islands and Southern Islands GPUs, my Oland would unlikely ever have experienced this problem, as I have for many years had amdgpu.si_support=1 radeon.si_support=0 in most all of my Grub Oland stanzas, in order to disable radeon, in turn to take advantage of whatever technological advances might be available in the newer amdgpu products. I temporarily stopped forcing amdgpu in order to confirm the reports, the workarounds, and the Mesa fix. Even with the Mesa 24.0.5 updates in place, all Southern Islands users nevertheless retain the option to use amdgpu.si_support=1 radeon.si_support=0 for the same purpose I have now returned to using them, as do the Sea Islands users amdgpu.cik_support=1 radeon.cik_support=0. Have a lot of fun! 
1 Like
This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.