Arch Linux

Please read this before reporting a bug:

Do NOT report bugs when a package is just outdated, or it is in the AUR. Use the 'flag out of date' link on the package page, or the Mailing List.

REPEAT: Do NOT report bugs for outdated packages!

FS#53090 - [nvidia-340xx-utils] Modulepath issue when using multiple Xserver

Attached to Project: Arch Linux
Opened by hamelg (hamelg) - Sunday, 26 February 2017, 19:01 GMT
Last edited by Antonio Rojas (arojas) - Thursday, 06 June 2019, 11:28 GMT
Task Type Bug Report
Category Packages: Extra
Status Closed
Assigned To Giancarlo Razzolini (grazzolini)
Architecture All
Severity Low
Priority Normal
Reported Version
Due in Version Undecided
Due Date Undecided
Percent Complete 100%
Votes 0
Private No


Modulepath setup is correct only for the 1st session and is ignored for additional session.

Additional info:
* package version(s)
nvidia-340xx-utils 340.102-5

Steps to reproduce:
1. Install the KDE plasma desktop
2. Open a KDE session
3. Goto K Menu : Power/Session > Switch User > Switch

Expected Result :
sddm launches a second XServer and a sddm-greater is displayed to select a login.

Current Result :
a black screen is displayed. sddm-greater crashes because glx has not been loaded.

In Xorg.0.log, the module path is correct : Xserver loads /usr/lib/nvidia/xorg/
In Xorg.1.log, the second X server tries to load the wrong module /usr/lib/xorg/modules/extensions/ (owned by xorg-server).

   Xorg.0.log (133.7 KiB)
   Xorg.1.log (134.3 KiB)
This task depends upon

Closed by  Antonio Rojas (arojas)
Thursday, 06 June 2019, 11:28 GMT
Reason for closing:  Won't fix
Additional comments about closing:  Package dropped
Comment by Laurent Carlier (lordheavy) - Monday, 27 February 2017, 12:43 GMT
Do you have any custom configuration file?
Comment by hamelg (hamelg) - Monday, 27 February 2017, 17:31 GMT
I have removed my custom setup and it changes nothing.
The issue still happens.
Comment by a b (leper) - Wednesday, 27 December 2017, 16:34 GMT
Ran into this issue today when I tried starting a game on a second X server. (`xinit /usr/bin/xonotic-glx -- :1` in a vt.)

I narrowed it down to
(II) xfree86: Adding drm device (/dev/dri/card0)
(EE) /dev/dri/card0: failed to set DRM interface version 1.4: Permission denied
in Xorg.1.log, which means the device isn't fully set up (as it already was by the first X server), thus failing that the driver auto-detection in /usr/share/X11/xorg.conf.d/10-nvidia-drm-outputclass.conf does not kick in, and the `ModulePath` stays `/usr/lib/xorg/modules` instead of being extended to `/usr/lib/nvidia/xorg,/usr/lib/xorg/modules`.

I fixed this for myself by adding
Section "Files"
ModulePath "/usr/lib/nvidia/xorg"
ModulePath "/usr/lib/xorg/modules"
to my xorg.conf.
Comment by Sven-Hendrik Haase (Svenstaro) - Friday, 29 December 2017, 03:58 GMT
This is an interesting problem but I don't really know how to debug this. I'm also not sure there is something to be done in the package that won't break things for everybody else. Can you help me fix this?
Comment by hamelg (hamelg) - Friday, 29 December 2017, 10:27 GMT
perhaps, some additional information about that, here :
Comment by hamelg (hamelg) - Friday, 29 December 2017, 11:00 GMT
Is it related or a duplicate ?
Comment by a b (leper) - Saturday, 30 December 2017, 16:36 GMT
#53704 seems somewhat related, at least the fix is the same. It does however not have a full log, but I suspect it is the same cause (though it does not seem to be about starting a second X server), also it is about nvidia instead of nvidia-340xx.

To properly debug this one would need access to some hybrid graphics machine to test if starting multiple X servers works currently (and what drivers are used in those cases), or if the changes proposed below break anything.

I suspect having a /usr/share/X11/xorg.conf.d/10-nvidia.conf with the content above in the nvidia-340xx-utils package, and having the current /usr/share/X11/xorg.conf.d/10-nvidia-drm-outputclass.conf renamed to /usr/share/X11/xorg.conf.d/20-nvidia-drm-outputclass.conf to overwrite these settings in eg the bumblebee package could be a working solution.

This assumes that someone installing nvidia-340xx{,-utils} wants to use that somewhat exclusively if they don't write an xorg.conf or install bumblebee. Anyone using more than 1 gpu (or 2 with bumblebee) is likely to already need an xorg.conf to do what they want.

If the above is not a proper solution I guess we can just add a note to the wiki on how to fix this, or extend the install message of nvidia-340xx-utils.
Comment by a b (leper) - Saturday, 30 December 2017, 17:09 GMT
I forgot adding that the renamed /usr/share/X11/xorg.conf.d/20-nvidia-drm-outputclass.conf should also reset the ModulePath to /usr/lib/xorg/modules.
Comment by Sven-Hendrik Haase (Svenstaro) - Sunday, 07 January 2018, 12:48 GMT
Please try the package in [testing].
Comment by a b (leper) - Sunday, 07 January 2018, 17:03 GMT
Works for me. (340.104-4)

Comment by hamelg (hamelg) - Sunday, 07 January 2018, 17:47 GMT
here too, 340.104-4 has fixed the issue.
Great !
Comment by a b (leper) - Tuesday, 09 January 2018, 14:49 GMT
  • Field changed: Percent Complete (100% → 0%)
Broken by nvidia-340xx-utils-340.104-5.

By to be specific.

The /usr/share/X11/xorg.conf.d/10-nvidia-drm-outputclass.conf hook does not apply since the setting of the DRM interface version fails. Which is the reason why that file did not work initially.
Comment by Sven-Hendrik Haase (Svenstaro) - Tuesday, 09 January 2018, 16:31 GMT
-4 broke for pretty much everybody else. Unless you can suggest a configuration based solution that will work for everyone without breaking existing setups I think we should keep this fix in the wiki rather than try to put it in the packagae somehow.
Comment by a b (leper) - Tuesday, 09 January 2018, 18:37 GMT
(The other ticket being

I outlined one above, I can however not test this since I don't have any hybrid/dual graphics box to test this on, I'll however detail the approach in a possibly easier to understand manner.

Dual/hybrid graphics with nvidia* (not noveau) are doable via or Optimus does not allow switching and uses the nvidia card, and requires an xorg.conf, so we will ignore that configuration.

So the only hybrid graphics solution that uses nvidia* and should work without any configuration requires installing bumblebee. This is what the proposed solution will rely on.

Provide /usr/share/X11/xorg.conf.d/10-nvidia.conf
Does not provide /usr/share/X11/xorg.conf.d/20-nvidia-drm-outputclass.conf anymore. This also seems logical since a file that is meant to make hybrid graphics work is now provided by bumblebee which is about hybrid graphics.

Provide /usr/share/X11/xorg.conf.d/20-nvidia-drm-outputclass.conf with a new Files section.

That way a purely nvidia* box will have 10-nvidia.conf, while a hybrid box will have 20-nvidia-drm-outputclass.conf which fixes the modulepath for the hybrid graphics case.

For the specific file contents 10-nvidia.conf should be:
Section "Files"
ModulePath "/usr/lib/nvidia/xorg"
ModulePath "/usr/lib/xorg/modules"

Whereas 20-nvidia-drm-outputclass.conf should be:
Section "Files"
ModulePath "/usr/lib/xorg/modules"

Section "OutputClass"
Identifier "intel"
MatchDriver "i915"
Driver "modesetting"

Section "OutputClass"
Identifier "nvidia"
MatchDriver "nvidia-drm"
Driver "nvidia"
Option "AllowEmptyInitialConfiguration"
Option "PrimaryGPU" "yes"
ModulePath "/usr/lib/nvidia/xorg"

It would be nice if someone that has access to a hybrid graphics box could test this.