Just installed leap 15 on a laptop with nvidia optimus card.
Before, i was runing leap 42.2, and everything went smooth with nouveau.
The machine was switching from the discrete nvidia gpu and the intel integrated gpu silently without any action from me.
The leds on the laptop was indicating that the discrete nvidia gpu was turned off when not needed and turned on when necessary.
It was installed without any configuration from me.
Most important : the temperature and battery consumption was reasonable.
And now the leds on the laptop indicate that the discrete nvidia gpu is always on.
Disappointment : the temperature and battery consumption is high
Initially, i realised that the intel driver for x was not installed. I had to install manually the xorg intel drivers and other things like : nf86-video-intel, and xf86-video-nv … Don’t which one is doing what…
I also tried to install the switcheroo pakages and activated the service, but no joy.
Yet, it still doesn’t work and i am asking for your help.
Most Intel gfx users have no need for xf86-video-intel, which hasn’t had an official updated release in over 3 years. Intel gfx developers apparently put most of their time into the modesetting driver incorporated in the X server, which is why xf86-video-intel is commonly not installed. xf86-video-nv is only for antique NVidia gfx, more than somewhere around 12+ years old, long before Optimus first appeared. The modesetting driver should work for both Optimus GPUs for those who don’t demand non-FOSS drivers for their games.
How did you install? Clean install or upgrade from 42.2?
Before, i was runing leap 42.2, and everything went smooth with nouveau.
The machine was switching from the discrete nvidia gpu and the intel integrated gpu silently without any action from me.
The leds on the laptop was indicating that the discrete nvidia gpu was turned off when not needed and turned on when necessary.
It was installed without any configuration from me.
There was no such feature on a default install of 42.2, so either somebody configured that or you are not telling the whole story…
Most important : the temperature and battery consumption was reasonable.
And now the leds on the laptop indicate that the discrete nvidia gpu is always on.
Disappointment : the temperature and battery consumption is high
Initially, i realised that the intel driver for x was not installed. I had to install manually the xorg intel drivers and other things like : nf86-video-intel, and xf86-video-nv … Don’t which one is doing what…
I also tried to install the switcheroo pakages and activated the service, but no joy.
On a default install of LEAP 15 on an Optimus laptop discrete graphics is normally off and can be used by issuing “DRI_PRIME=1 <command>”.
xf86-video-intel, and xf86-video-nv are not needed, vga-switcheroo is not needed, so apparently you have been looking for trouble.
Maybe restarting from scratch with a clean install is the easiest way forward unless you can undo what you did after the default install.
Please show the result of:
/sbin/lspci -nnk | grep -EiA3 'vga|3d|display'
and describe further your HW if possible, maybe you are using an unusual model or configuration.
Btw, i only installed xf86-video-intel, xf86-video-nv and vga-switcheroo after : i decided to install theses packages only after i noticed that it didn’t work properly, whereas with 42.2 it worked out of the box, without any configuration action from me.
With 42.2, that i still use as my every day production tool, the dgpu only turns on when needed, and stays off otherwise.
NB : on 42.2, without the proprietary driver = no bumblebee, only nouveau… And no configuration action from me.
And i don’t understand why it doesn’t work out of the box with 15.0 .
When dgpu does not turn off automatically, laptop is too warm and battery is too short. And i can see what happens because there is a led on the laptop that shows when dgpu is on and another led that shows when the integrated gpu is used instead.
Moreover, the fan noise confirms that something is wrong.
So with 15.0, laptop too warm and battery too short. Why ?
That does not look like the usual “Optimus” laptop, seems more similar to a desktop setup. Maybe there is something in the firmware (BIOS) that can control which GPU is used?
Please provide the result of the following command:
journalctl -b |grep -E 'DSM|nouveau'
Maybe you can add nouveau.runpm=1 to the kernel boot line and see if something changes? (sorry, I’m just guessing; no direct experience with Clevo and some models might have unusual “custom” configurations)
No doubt about that and if you could write the exact model somebody might find more info about its configuration, which seems more similar to what we can usually find in a desktop.
OK thanks, what I understand is that your laptop uses the “Optimus” architecture but unfortunately…
oct. 15 09:42:28 diesel kernel: nouveau 0000:01:00.0: enabling device (0006 → 0007)
oct. 15 09:42:28 diesel kernel: nouveau 0000:01:00.0: NVIDIA GK107 (0e7110a2)
oct. 15 09:42:28 diesel kernel: nouveau 0000:01:00.0: bios: version 80.07.1d.00.21
oct. 15 09:42:28 diesel kernel: nouveau 0000:01:00.0: fb: 1024 MiB GDDR5
oct. 15 09:42:28 diesel kernel: nouveau 0000:01:00.0: DRM: VRAM: 1024 MiB
oct. 15 09:42:28 diesel kernel: nouveau 0000:01:00.0: DRM: GART: 1048576 MiB
oct. 15 09:42:28 diesel kernel: nouveau 0000:01:00.0: DRM: TMDS table version 2.0
oct. 15 09:42:28 diesel kernel: nouveau 0000:01:00.0: DRM: DCB version 4.0
oct. 15 09:42:28 diesel kernel: nouveau 0000:01:00.0: DRM: MM: using COPY for buffer copies
**oct. 15 09:42:28 diesel kernel: [drm] Initialized nouveau 1.3.1 20120801 for 0000:01:00.0 on minor 0
oct. 15 11:44:14 diesel.diesel /usr/lib/gdm/gdm-x-session[2856]: (==) Matched nouveau as autoconfigured driver 2
oct. 15 11:44:14 diesel.diesel /usr/lib/gdm/gdm-x-session[2856]: (II) LoadModule: “nouveau”
oct. 15 11:44:14 diesel.diesel /usr/lib/gdm/gdm-x-session[2856]: (II) Loading /usr/lib64/xorg/modules/drivers/nouveau_drv.so
oct. 15 11:44:14 diesel.diesel /usr/lib/gdm/gdm-x-session[2856]: (II) Module nouveau: vendor=“X.Org Foundation”
oct. 15 11:44:14 diesel.diesel /usr/lib/gdm/gdm-x-session[2856]: (II) [drm] nouveau interface version: 1.3.1
oct. 15 11:44:14 diesel.diesel /usr/lib/gdm/gdm-x-session[2856]: (II) NOUVEAU(G0): [DRI2] DRI driver: nouveau
oct. 15 11:44:14 diesel.diesel /usr/lib/gdm/gdm-x-session[2856]: (II) NOUVEAU(G0): [DRI2] VDPAU driver: nouveau
**
… the nouveau driver activates the dGPU and stays that way no matter what instead of putting it to rest unless it is needed (and I don’t understand why at this stage).
Since you appear to still have 42.2 on that box, can you run the same command in 42.2 and look for any differences?
The result of the following under 42.2 might also help, even if I don’t expect differences here:
If you cannot load GPU drivers - while bbswitch being loaded - and get an error like this on a Kepler card:
[INFO]Response: No - error: Could not load GPU driver
[ERROR]Cannot access secondary GPU - error: Could not load GPU driver
Try changing value of ‘load_state’ in “/etc/modprobe.d/50-bbswitch.conf” from 0 to -1
Please also note that with a successfully installed bumblebee you should be able to switch off the dGPU via:
switch state of card manually with bbswitch
check the state of your card:
cat /proc/acpi/bbswitch
to turn your card off, type:
tee /proc/acpi/bbswitch <<<OFF
Please be aware that the instructions to install bumblebee are expected to work on a clean install, so you should revert any other installation or configuration in the video area before trying that.
P.S.: Notice to graphics/Nvidia gurus: your help is welcome, I’m running out of ideas
I understand that installing bbswitch might solve the problem, but does it imply that i install the sometimes very unstable nvidia proprietary driver ?
As expected, no differences here. It might be more interesting to see any differences in the result of:
journalctl -b |grep -E 'DSM|nouveau'
I understand that installing bbswitch might solve the problem, but does it imply that i install the sometimes very unstable nvidia proprietary driver ?
No, as explained in the linked page the proprietary Nvidia driver is optional, bumblebee (and bbswitch) should work with the nouveau driver as well.
OK, here is (in BOLD) where the nouveau kernel module switches off the dGPU after failing to deal with the “Optimus” _DSM method on 42.2.
Ironically an updated ACPI on Leap 15 seems to be able to deal with that _DSM method and so uses the dGPU whenever possible…
I never witnessed such a behaviour on my “standard Optimus” machines, so I’m running out of ideas here.
But from an earlier post of yours I read that apparently you are using GDM (the Gnome Display Manager) with a Plasma desktop environment:
oct. 15 09:42:28 diesel kernel: [drm] Initialized nouveau 1.3.1 20120801 for 0000:01:00.0 on minor 0
oct. 15 11:44:14 diesel.diesel /usr/lib/**gdm/gdm-x-session**[2856]: (==) Matched nouveau as autoconfigured driver 2
oct. 15 11:44:14 diesel.diesel /usr/lib/gdm/gdm-x-session[2856]: (II) LoadModule: "nouveau"
oct. 15 11:44:14 diesel.diesel /usr/lib/gdm/gdm-x-session[2856]: (II) Loading /usr/lib64/xorg/modules/drivers/nouveau_drv.so
oct. 15 11:44:14 diesel.diesel /usr/lib/gdm/gdm-x-session[2856]: (II) Module nouveau: vendor="X.Org Foundation"
oct. 15 11:44:14 diesel.diesel /usr/lib/gdm/gdm-x-session[2856]: (II) [drm] nouveau interface version: 1.3.1
oct. 15 11:44:14 diesel.diesel /usr/lib/gdm/gdm-x-session[2856]: (II) NOUVEAU(G0): [DRI2] DRI driver: nouveau
oct. 15 11:44:14 diesel.diesel /usr/lib/gdm/gdm-x-session[2856]: (II) NOUVEAU(G0): [DRI2] VDPAU driver: nouveau
oct. 15 11:44:25 diesel.diesel **plasmashell[3010]**: org.kde.plasmaquick: New Applet "Notification de nouveau périphérique" with a weight of 0
I really don’t know if this “non default” setup has anything to do with your problem, but if I were to use KDE/Plasma I would use sddm as display manager, or at least give it a shot.
By default GDM uses Wayland and that might have a role in keeping your dGPU alive; if you definitely need GDM there is a config to disable Wayland though:
just uncomment the line reading “WaylandEnable=false” in /etc/gdm/custom.conf
Thank you OrsoBruno for your very accurate observations and explanations.
But, regarding gdm/ssdm, it doesn’t change anything. The same bad behavior is observed with sddm.
