Presently, I work a lot on an old laptop which has a so called Optimus combination of a dedicated Nvidia GPU and an Intel GPU coming with the main CPU-processor. “prime-select” is a tool which Opensuse includes with Leap 15.4 to provide an efficient way of controlling which GPU shall be used. As good as prime-select has worked for me on Leap 15.3 and also some time with Leap 15.4 recent updates of a variety of SW packages lead into trouble.
I had the Nvidia card active before the SW updates. After a cold restart of the system it did no longer start the SDDM display manager on the default systemd target. This happened even when the updates did not directly affect the kernel or the Nvidia kernel modules.
The problem always had to do with bbswitch turning off the Nvidia device when the system switched to the default graphical target. And with a turned off Nvidia graphics device the Nvidia drivers can not be loaded.
So some SW updates lead to a change of the configuration prime-select had set up before the updates. The stupid thing is that it is not quite so simple to get things back to work. To try to us “init 3” to go to a console interface on a non-graphical target and then use “prime-select nvidia” plus a subsequent “init 5” on the command line does not work. You do not change the wrong bbswitch actions that way. You can also turn bbswitch off by “tee /proc/acpi/bbswitch <<< OFF". And then load the Nvidia driver successfully. But trying to afterward switch to the standard graphical target invokes bbswitch again in the wrong way.
It is a bit of a mess. The following steps seem to work to get back to normal operation again:
Step 1: Use “init 3” on a console terminal.
Step 2: Use the command “prime-select intel”.
Step 3: Restart your system. It should boot now into the graphical target based on the i915 intel GPU driver.
Step 4: Ignore any information from a prime-select icon. It shows you a plainly wrong info that you are using Nvidia.
Step 5: Log in as root on a root terminal window. Switch bbswitch off (e.g. by the command given above). Load the Nvidia module by “modprobe nvidia”. Check via lsmod that it is successfully loaded.
Step 6: Type in “prime-select nvidia”.
Step 7: Log out from your graphical interface.
Step 8: Check that SDDM or whatever display manager is started with bbswitch not shutting down the Nvidia card. Log inn with the Nvidia card active.
Step 9: Check that the Nvidia driver is still loaded on a root terminal window. Then issue “mkinitrd” and restart your Leap 15.4 system.
Afterward using the “prime-select intel” or “prime-select nvidia” commands at the command line of a root terminal window, a logout from the graphical desktop and a login again via the restarted graphical display manager switches correctly between the cards.
However, the prime-select applet gives you wrong information when the intel card is active. And it does not give you the chance to switch back to the Nvidia card again. Its stupid, but no major problem as long as the basic prime-select command does its job on the command line.
Hope this helps people having to work with Opensuse on an Optimus system.
Some days ago I have upgraded to Opensuse Leap 15.4 on an old laptop which had Leap 15.3 installed. I once again ran into a problem regarding Pulseaudio and its Ladspa based equalizer. The equalizer did not work, although you could start its GUI.
The problem: The Ladspa equalizer’s interface shows up – but the equalizer is not working and not usable as a Pulseaudio sink
You can start the pulseaudio-equalizer, its graphical interface shows up on your desktop (in my case a KDE desktop) – but it is not doing its work on any sound streams. One could also say: You can switch the Pulseaudio LADSPA equalizer on, but it has no effect on any sound. You do not see it as a sink in the Pulseaudio tools either. pavucontrol will not show it as a device we could attach a sound source to. Regarding KDE we can not define it as the standard device which sound sources should use for handling their output. A Pipewire installation alone does not solve this problem.
The Cause: A missing link to a library
A lot of programs try to find shared system library objects in the directory “/usr/lib64/”. Normally, an installation procedure would set up a soft link to required so-libs it brings with it in a sub-directory of “/usr/lib64”. The problem is that such a link is missing after the installation of the RPM “pulseaudio-equalizer” on Leap 15.4. The missing link is one to /usr/lib64/ladspa/mbeq_1197.so.
mytux:~ # cd /usr/lib64
mytux:/usr/lib64 # ln -s /usr/lib64/ladspa/mbeq_1197.so mbeq_1197.so
And your Pulseaudio – Ladspa – Equalizer will work again.
In the first post of this series I have covered the upgrade procedure of a Linux PC from Opensuse Leap 15.3 to Leap 15.4. In the second post I tested the system’s behavior for Plasma and Gnome on (X)Wayland. Which was surprisingly good.
The upgrade to Leap 15.4 may come with an inconvenience on systems with multiple attached screens:
You may loose your preferred screen order.
This means that your mouse cursor may not move across your screens as you expect it for your desktop display manager or for your graphical desktop spanned over the number of available screens. And windows moved on the desktop across the right edge of a particular screen may appear on another screen physically positioned to the left of your current screen. Which is not really funny.
Actually, my upgrade to Leap 15.4 confronted me with a wrong screen order for both SDDM and my KDE Plasma desktop sessions. This happened on two of my systems – both equipped with Nvidia graphics cards. Regarding Plasma and Gnome on X11 I have previously often used the nvidia-settings application to fix the screen order and put related statements into the xorg.conf. But on (X)Wayland this is currently not an option. nvidia-settings simply lacks the required functionality there.
Some people recommend in such a case to switch cables between the available plugs at the graphics card. No need to do so. In the present post I show you how to get your screens into the required order again without moving their physical positions or putting their video cables into different plugs.
But I only describe the measures for the display manager SDDM and for KDE Plasma and Gnome on Wayland / X11. For other display managers and desktop environments other tools and steps may have to be applied. Below I use the term (X)Wayland when the methods apply both to a native Wayland session or a Xwayland setup.