Hi,
one of the recent TW updates broke my system by not accepting any keyboard inputs or mouse clicks at the login screen. The mouse cursor, however, is moving as expected. And I can switch between the virtual consoles with CTRL-SHIFT-F*. In the virtual consoles , keyboard input is working normally.
Fortunately, I had taken a disk image before updating, so I could easily revert the computer back to a functional state. But I don’t dare trying any updates again.
I should mention that I also tried a fresh parallel installation of TW on a second disk in the machine. Shows exactly the same behaviour.
Any hints would be highly appreciated.
1 Like
What is your GPU, and do you use SDDM? Does X11 or Wayland work?
My graphics card is an AMD Radeon with an OLAND GPU. And, yes, I’m using SDDM.
I can’t tell anything about X11 or Wayland. The system is configured to start an X11 KDE session. But I cannot change this, because mouse clicks are ignored.
As suggested in “SDDM black login screen…” thread, I will try locking the AMD-related packages. But that won’t happen very soon, because I’m away from home for almost two weeks now.
Have you seen this: 1222213 – sddm-greeter-qt6 crashes on startup if used with kernel driver "radeon"
1 Like
No, I hadn’t seen this. Sounds like a very basic issue, which might not be solvable with simple measures by the users.
Last night, I unexpectedly found some time trying to lock the AMD-related packages. This ends up with a long list of unresolved package references with “zypper dup”.
A laptop? Try connecting a USB keyboard. My TW laptop has recently started having problems with the built-in keyboard.
Adding “modprobe.blacklist=radeon” to the GRUB command line (as work-around) resolves the issue.
See Comment #10 in this bug report
1 Like
That problem comes with Mesa 24 update and haven’t been fixed.
You could change packman repositiry to Slowroll’s and force Mesa package to downgrade to version 23.
I don’t see that as a “workaround”. For 3 years or more, via radeon.si_support=0 amdgpu.si_support=1, I’ve been purposely using the amdgpu kernel driver instead of radeon with my Oland, primarily because it’s intended for newer AMD technology that began with introduction of GCN. I wouldn’t have known there was any GCN #1 card using radeon module problem if I hadn’t seen bug 1222156.
1 Like
No, not a laptop.
Is it recommended to use amdgpu instead of radeon suppoort?
What’s recommended AFAIK is to use what works. If radeon does not, but amdgpu does, then what does any recommendation mean? Technically, amdgpu has been deemed “experimental” for AMD’s GCN #1 & GCN #2 cards. Except for short term testing, I’ve been using amdgpu to the exclusion of radeon on GCN #1 and GCN #2 cards for more than 4 years at least. It might be several years longer than that, long past “experimental” for me.
I tried adding “modprobe.blacklist=radeon” to the GRUB command line. In a way, it solves the issue, but now I’ve got a screen resolution of only 1024x68, which is not exactly what I’d like to keep.
@afalb I have a Mullins (Sea Island) GCN 2 gpu running Leap 15.5 using the amdgpu with the following
kernel options;
amdgpu.cik_support=1 amdgpu.si_support=0
inxi -Gxxz
Graphics:
Device-1: AMD Mullins [Radeon R3 Graphics] vendor: Hewlett-Packard driver: amdgpu v: kernel
arch: GCN-2 ports: active: eDP-1 empty: HDMI-A-1,VGA-1 bus-ID: 00:01.0 chip-ID: 1002:9850
Your Oland GPU is a Southern Island, so use;
amdgpu.cik_support=0 amdgpu.si_support=1
Fire up YaST bootloader and add there, save and reboot.
I would also ensure that xf86-video-amdgpu is installed, I also add a blacklist file;
/etc/modprobe.d/50-radeon.conf
blacklist radeon
1 Like
@malcolmlewis Thanks for your advice. The additional kernel options you suggested finally fixed the issue.