Bug 2264

Summary: Support for hybrid graphics (already implemented)
Product: Fedora Reporter: Xiao-Long Chen <chillermillerlong>
Component: xorg-x11-drv-nvidiaAssignee: Nicolas Chauvet <kwizart>
Status: RESOLVED EXPIRED    
Severity: normal CC: s.adam
Priority: P5    
Version: unspecified   
Hardware: All   
OS: GNU/Linux   
namespace:
Bug Depends on: 2072    
Bug Blocks:    
Attachments: diff between 295.40 spec and 295.40 with hybrid-detect spec

Description Xiao-Long Chen 2012-04-09 08:12:21 CEST
After two days of hard work, I've finally finished implementing hybrid graphics support in the xorg-x11-drv-nvidia package. It's based on the Ubuntu 12.04 implementation for hybrid graphics. Note that this feature is only for laptops with a hardware mux or a BIOS setting for switching graphics cards, but does NOT affect laptops or desktops with only a single graphics card.

The configuration files for the packages are now set up to be symlinks for the update-alternatives utility included in Fedora. Basically instead of:

* /etc/ld.so.conf.d/nvidia-%{_lib}.conf
* /etc/X11/xorg.conf.d/00-nvidia.conf

we now have:

* /etc/ld.so.conf.d/nvidia-%{_lib}.conf -> /etc/alternatives/nvidia-%{_lib}.conf -> /usr/share/nvidia-common/nvidia-%{_lib}.conf
* /usr/share/X11/xorg.conf.d/00-nvidia.conf -> /etc/alternatives/00-nvidia.conf -> /usr/share/nvidia-common/00-nvidia.conf

This allows the nVidia driver to be disabled, but remain installed, so that the Intel graphics card can work. Each configuration file has two alternatives: the actual configuration file in /usr/share/nvidia-common, and /dev/null to disable the nVidia driver.

To handle the switching automatically, I created a new subpackage called nvidia-common with the 'hybrid-detect' tool. hybrid-detect (based on Ubuntu's version) is a C program that finds out whether the Intel or nVidia graphics card is enabled and then runs the appropriate update-alternatives command. The state is saved in /var/lib/nvidia-common/last_gfx_boot, so the tool will only run if the graphics card was actually switched since the last boot. **On non-hybrid graphics systems, the boot time only increases by the amount of time it takes to read a 10-byte file from the HDD.**

hybrid-graphics can handle the 32 bit libraries if they're installed on a 64 bit system. Also, /etc/X11/nvidia-xorg.conf had to be merged into /usr/share/nvidia-common/00-nvidia.conf.

Overview of what changed: http://paste.kde.org/454184/

Hopefully, these changes can be included in RPMFusion's xorg-x11-drv-nvidia package :)

SPEC + Sources: https://github.com/chenxiaolong/Fedora-SRPMS/tree/master/xorg-x11-drv-nvidia
SRPM: http://ompldr.org/vZGI2aA
SRPM signature: http://ompldr.org/vZGI2aw

GPG Key ID: 90EFF32C
Public key:
http://keys.niif.hu:11371/pks/lookup?search=0x90EFF32C&op=index
http://keyserver.ubuntu.com:11371/pks/lookup?search=0x90EFF32C&op=index

Thanks in advance!
Comment 1 Xiao-Long Chen 2012-04-12 22:46:19 CEST
Updated to version 295.40 to fix security vulnerability CVE-2012-0946.

SPEC + Sources: https://github.com/chenxiaolong/Fedora-SRPMS/tree/master/xorg-x11-drv-nvidia
SRPM: http://ompldr.org/vZGNzZg
SRPM signature: http://ompldr.org/vZGNzYw
Comment 2 Xiao-Long Chen 2012-04-13 17:42:52 CEST
Thix fixes a few minor mistakes (I accidentally left debug messages in the hybrid-detect tool :D).

SRPM: http://ompldr.org/vZGN3eA
SRPM signature: http://ompldr.org/vZGQyeg
Comment 3 Nicolas Chauvet 2012-04-13 17:46:26 CEST
Can you attach a diff from the spec file ?
Comment 4 Xiao-Long Chen 2012-04-13 18:06:07 CEST
Created attachment 855 [details]
diff between 295.40 spec and 295.40 with hybrid-detect spec
Comment 5 Xiao-Long Chen 2012-04-13 18:06:25 CEST
(In reply to comment #3)
> Can you attach a diff from the spec file ?

Absolutely :) It's attached.
Comment 6 Nicolas Chauvet 2012-05-04 14:11:33 CEST
- Some part of your changes rely on alternatives, please see rfbz#2072
- hybrid-detect should be a separate package (not a sub-package / and a new review), you can make this bug depends on the review.
Now the nvidia driver doesn't need to depends on the hybrid-detect in the case one don't want to rely on it. The part that need to be changed in the driver is just about an infrastructure that help to switch the right driver and that the hybric-graphic package will use.
- {{again}} - and please double check what you are assuming :
/xorg/modules/extensions/nvidia is NOT browsed recursively. This directory was choosen on purpose so it won't collapse with open-source version.
You might have a remaining file setting ModulePath in /etc/X11/xorg.conf.d and /usr/share/X11/xorg.conf.d

Thx
Comment 7 Xiao-Long Chen 2012-05-04 17:39:37 CEST
Thanks for the reply!

> - Some part of your changes rely on alternatives, please see rfbz#2072

Unless I'm missing something, that bug recommends that the alternative is for the /etc/ld.so.conf.d/nvidia-%{_lib}.conf file, which is what the packages does already.

If you were speaking of the last comment page, then I agree. There should be a general solution that can switch between the libraries for different graphics drivers. hybrid-detect can be a temporary solution.

> - hybrid-detect should be a separate package (not a sub-package / and a new
> review), you can make this bug depends on the review.
> Now the nvidia driver doesn't need to depends on the hybrid-detect in the case
> one don't want to rely on it. The part that need to be changed in the driver is
> just about an infrastructure that help to switch the right driver and that the
> hybric-graphic package will use.

Thanks. I'll separate hybrid-detect from the main driver and create another bug report for it.

> - {{again}} - and please double check what you are assuming :
> /xorg/modules/extensions/nvidia is NOT browsed recursively. This directory was
> choosen on purpose so it won't collapse with open-source version.
> You might have a remaining file setting ModulePath in /etc/X11/xorg.conf.d and
> /usr/share/X11/xorg.conf.d
> 
> Thx

In that case, I'm not sure how the switching would be done. If I comment out the ModulePath in /etc/X11/xorg.conf.d/00-nvidia.conf and boot with the Intel graphics card, xorg still attempts to load libglx.so from /usr/%{_lib}/xorg/extensions/nvidia/.

Thanks
Comment 8 Nicolas Chauvet 2012-05-04 18:48:07 CEST
(In reply to comment #7)
> Thanks for the reply!
> 
> > - Some part of your changes rely on alternatives, please see rfbz#2072
> 
> Unless I'm missing something, that bug recommends that the alternative is for
> the /etc/ld.so.conf.d/nvidia-%{_lib}.conf file, which is what the packages does
This have to be implemented for all the libraries mesa provides.

 
> > - {{again}} - and please double check what you are assuming :
> > /xorg/modules/extensions/nvidia is NOT browsed recursively. This directory was
> > choosen on purpose so it won't collapse with open-source version.
> > You might have a remaining file setting ModulePath in /etc/X11/xorg.conf.d
..
> In that case, I'm not sure how the switching would be done. If I comment out
> the ModulePath in /etc/X11/xorg.conf.d/00-nvidia.conf and boot with the Intel
> graphics card, xorg still attempts to load libglx.so from
> /usr/%{_lib}/xorg/extensions/nvidia/.
You probably have some ModulePath definition remaining in /usr/share/X11/xorg.conf.d or else.
Comment 9 Xiao-Long Chen 2012-05-04 19:10:29 CEST
(In reply to comment #8)
> (In reply to comment #7)
> > Thanks for the reply!
> > 
> > > - Some part of your changes rely on alternatives, please see rfbz#2072
> > 
> > Unless I'm missing something, that bug recommends that the alternative is for
> > the /etc/ld.so.conf.d/nvidia-%{_lib}.conf file, which is what the packages does
> This have to be implemented for all the libraries mesa provides.

I see what you mean. So like a graphics driver alternative that has slave alternatives for libGL.so, libGLU.so, etc.

> 
> > > - {{again}} - and please double check what you are assuming :
> > > /xorg/modules/extensions/nvidia is NOT browsed recursively. This directory was
> > > choosen on purpose so it won't collapse with open-source version.
> > > You might have a remaining file setting ModulePath in /etc/X11/xorg.conf.d
> ..
> > In that case, I'm not sure how the switching would be done. If I comment out
> > the ModulePath in /etc/X11/xorg.conf.d/00-nvidia.conf and boot with the Intel
> > graphics card, xorg still attempts to load libglx.so from
> > /usr/%{_lib}/xorg/extensions/nvidia/.
> You probably have some ModulePath definition remaining in
> /usr/share/X11/xorg.conf.d or else.

What I'm not understanding is what the alternative would be. The nvidia libraries can be switched by using alternatives for /etc/ld.so.conf.d/nvidia--lib.conf. What should I make an alternative, so that /usr/lib/xorg/extensions/nvidia/ is used when nVidia card is present and /usr/lib/xorg/extensions/ is used when Intel card is present?
Comment 10 Nicolas Chauvet 2012-05-04 19:40:24 CEST
(In reply to comment #9)
..
> What I'm not understanding is what the alternative would be. The nvidia
> libraries can be switched by using alternatives for
> /etc/ld.so.conf.d/nvidia--lib.conf. What should I make an alternative, so that
> /usr/lib/xorg/extensions/nvidia/ is used when nVidia card is present and
> /usr/lib/xorg/extensions/ is used when Intel card is present?

That can probably be done at the 00-nvidia.conf level, instead of having it in /etc/X11/xorg.conf.d but like /etc/X11/ and using /etc/X11/xorg.conf.d/10-driver.conf to alterne with the conf with the appropriate ModulePath.

(PS: I will be on vacation next week).
Comment 11 Xiao-Long Chen 2012-05-04 21:51:48 CEST
(In reply to comment #10)
> ..
> That can probably be done at the 00-nvidia.conf level, instead of having it in
> /etc/X11/xorg.conf.d but like /etc/X11/ and using
> /etc/X11/xorg.conf.d/10-driver.conf to alterne with the conf with the
> appropriate ModulePath.
> 
> (PS: I will be on vacation next week).

Okay, I have this implemented now. I'm starting to think that ModulePath is recursive in the new versions of Xorg now. If you look at my Xorg log: http://ompldr.org/vZG1mdw/Xorg.0.log, you can see that the ModulePath does not contain the nvidia directory. However, Xorg still attempts to load libGLX.so from the nvidia directory.

PS: Have a nice vacation :D
Comment 12 Xiao-Long Chen 2012-05-05 03:04:36 CEST
I can definitely confirm that ModulePath is now recursive :) I created another F16 partition, fully updated it, and installed the current RPMFusion nVidia driver. Then, I removed all the ModulePath lines from /etc/X11/xorg.conf.d/00-nvidia.conf. X was able to start properly and GL works fine.
Comment 13 Nicolas Chauvet 2012-05-05 04:25:13 CEST
(In reply to comment #12)
> I can definitely confirm that ModulePath is now recursive :) I created another
Tested on F-17, Nope
Comment 14 Xiao-Long Chen 2012-05-05 21:36:55 CEST
(In reply to comment #13)
> (In reply to comment #12)
> > I can definitely confirm that ModulePath is now recursive :) I created another
> Tested on F-17, Nope

I just installed F17 in a VM and installed the RPMFusion akmod-nvidia and xorg-x11-drv-nvidia. I commented out the ModulePath lines and Xorg still attempts to load /usr/lib64/xorg/modules/extensions/nvidia/libglx.so. Since it's a VM, there's no nVidia card, so mesa's libglx.so should be loading.

Xorg.0.log here: http://ompldr.org/vZG13bQ/Xorg.0.log

"grep -r ModulePath /etc/X11/ /usr/share/X11/" returns:

# ModulePath "/usr/lib64/xorg/modules/extensions/nvidia"
# ModulePath "/usr/lib64/xorg/modules"
Comment 15 Nicolas Chauvet 2012-10-30 22:20:10 CET
This turn out that I've made a new check with today's f18. and Indeed, the xorg/module directory is "now" recursive. So I appologies on this misstake from my part.

I'm about to move the xorg part to _libdir/nvidia/xorg instead to help switching from mesa/vendor driver.
Comment 16 Xiao-Long Chen 2012-10-31 00:37:58 CET
(In reply to comment #15)
> This turn out that I've made a new check with today's f18. and Indeed, the
> xorg/module directory is "now" recursive. So I appologies on this misstake from
> my part.
> 
> I'm about to move the xorg part to _libdir/nvidia/xorg instead to help
> switching from mesa/vendor driver.

Thanks a lot! All we need now is to have the alternatives set up.
Comment 17 Nicolas Chauvet 2016-11-09 16:52:05 CET
with PRIME support and libglvnd been enabled in mesa this is more the way to go.
http://rpmfusion.org/Howto/nVidia_Optimus

Closing since there is not much activity on this bug.