My 2018 Linux Test

JSumrall said:
Since I'm in the CLI doing the install it just puts it onscreen right in the middle of whatever you're doing. So like I can be in the middle of typing a command and it will output 4 or 5 lines of error message.

It looks like they just rolled out Arch 5.0.6 and while my old install USB stick was generating the error message, it doesn't seem to be doing it once the install is up and running.

I guess I'll need to redo my install stick.

Nouveau is definitely loading. I've tried blacklisting it 2 ways but it still loads.

How would you recommend I blacklist the nouveau driver from loading?

I tried using nouveau_blacklist.conf in /etc/modprobe.d and nvidia.conf in /usr/lib/modprobe.d and neither worked to block it.
Click to expand...

You are running the mkinitcpio -p linux command after blacklisting right?

sudo pacman -Rc xf86-video-nouveau

Try that too to eliminate the driver completely before reboot after blacklisting.
 
Vermillion said:
You are running the mkinitcpio -p linux command after blacklisting right?

sudo pacman -Rc xf86-video-nouveau

Try that too to eliminate the driver completely before reboot after blacklisting.
Click to expand...

No. What does mkinitcpio do?
 
Ok, 5.0.6 seems to have fixed something because after installing the base package, Xfce, and X, Xfce loaded right up after reboot.

Currently using Intel and Nouveau drivers.
 
Vermillion said:
It re-generates the initial ram disk image used by the system.



Could have been a kernel bug....
Click to expand...
Could have been. System is definitely up and running and I'm posting this from Xfce on the laptop after getting a web browser installed.
 
I wonder if I'll completely bork it by installing the nvidia driver.

Only one way to find out. lol
 
Thankfully, pacman -R nvidia removed the driver and after reboot the system is up and running again.
 
Xfce 4 is up and running as a non-root user.
Web browser installed and setup.
Background image changed to something that doesn't make my eyes bleed.
I was able to adjust screen gamma using the xgamma setting; xgamma -gamma 0.7 seems to foot the bill for now.
I installed PulseAudio, the Xfce PulseAudio plugin, and the pavucontrol volume control and sound is up and running.

Still having to use the nouveau driver. I'll probably try and work on the nvidia driver later. Eyes hurt too much right now.
 
Vermillion said:
It re-generates the initial ram disk image used by the system.



Could have been a kernel bug....
Click to expand...
I'm really curious about this intial ramdisk thing you mentioned. I've read the Archwiki page on initramfs, mkinitcpio, but I still don't understand quite exactly what it is for, or does.
 
JSumrall said:
I'm really curious about this intial ramdisk thing you mentioned. I've read the Archwiki page on initramfs, mkinitcpio, but I still don't understand quite exactly what it is for, or does.
Click to expand...

If you make kernel changes and don't run it you haven't made any changes. If you download a new kernel package... and you don't update your init info you will just keep running the old kernel. Same thing with blacklisting kernel modules or adding new ones... if you don't update the boot image you haven't changed anything.

https://en.wikipedia.org/wiki/Initial_ramdisk

Basically when it comes to booting things are much more complicated then they where at one time... the initial ram disk basically mounts itself to ram and then uses the mkinitcpio.conf to load (things like NV drivers ect). This is all run from an img which is what mkinit is building. If you run from a terminal or pay attention to the output from pacman you will see it adding kernel hooks ect... its basically deciding what kernel drivers it needs to boot, and adding that info to the boot img.

In Arch distros mkinitcpio will create that ram boot stuff which is called by grub. It by default add a tailored kernel boot with specific driver calls. It will then create a "fallback" image which will boot the same kernel but boot with auto settings allowing the kernel to load a bunch of stuff you may not need. (but in general it always works).

When ever you update a kernel with Pacman in an arch distro you will notice pacman will run mcinitcpio and update the calls in grub.

Arch has created their own tool... but other disros have the same basic setup.

In debian based distros you would find configurations for kernel boot hooks in /etc/initramfs/initramfs.conf and the comparable debian tool is update-initramfs
In arch it would be /etc/mkinitcpio.conf and mcinitcpio
 
ChadD said:
If you make kernel changes and don't run it you haven't made any changes. If you download a new kernel package... and you don't update your init info you will just keep running the old kernel. Same thing with blacklisting kernel modules or adding new ones... if you don't update the boot image you haven't changed anything.

https://en.wikipedia.org/wiki/Initial_ramdisk

Basically when it comes to booting things are much more complicated then they where at one time... the initial ram disk basically mounts itself to ram and then uses the mkinitcpio.conf to load (things like NV drivers ect). This is all run from an img which is what mkinit is building. If you run from a terminal or pay attention to the output from pacman you will see it adding kernel hooks ect... its basically deciding what kernel drivers it needs to boot, and adding that info to the boot img.

In Arch distros mkinitcpio will create that ram boot stuff which is called by grub. It by default add a tailored kernel boot with specific driver calls. It will then create a "fallback" image which will boot the same kernel but boot with auto settings allowing the kernel to load a bunch of stuff you may not need. (but in general it always works).

When ever you update a kernel with Pacman in an arch distro you will notice pacman will run mcinitcpio and update the calls in grub.

Arch has created their own tool... but other disros have the same basic setup.

In debian based distros you would find configurations for kernel boot hooks in /etc/initramfs/initramfs.conf and the comparable debian tool is update-initramfs
In arch it would be /etc/mkinitcpio.conf and mcinitcpio
Click to expand...

So should I just assume the distro is handling the updates itself, or manually run it every time I make changes?

I mean, up to this point I haven't been doing anything with mkinitcpio and changes seem to be taking place without it. Are there any hard, fast rules about when I should run it myself?
 
JSumrall said:
So should I just assume the distro is handling the updates itself, or manually run it every time I make changes?

I mean, up to this point I haven't been doing anything with mkinitcpio and changes seem to be taking place without it. Are there any hard, fast rules about when I should run it myself?
Click to expand...

If your manually blacklisting things with .conf files you would need to run it manually.

If your downloading a new kernel or something with pacman it will run it. (I mentioned it as you perhaps have seen arch running it when you switch kernels)

I guess keep it in mind if your messing with kernel module stuff trying to get NV kernel drivers working. You need to rebuild your Initial ram image with the new info.
 
I'm trying to determine what exactly is happening on system boot with regards to video drivers. Upon reviewing the Xorg.0.log file in /var/log it seems neither Intel or nouveau are being used but something called modesetting.

Code: 
[     9.689] (==) Matched modesetting as autoconfigured driver 0
[     9.689] (==) Matched intel as autoconfigured driver 1
[     9.689] (==) Matched fbdev as autoconfigured driver 2
[     9.689] (==) Matched vesa as autoconfigured driver 3
[     9.689] (==) Assigned the driver to the xf86ConfigLayout
[     9.689] (II) LoadModule: "modesetting"
[     9.689] (II) Loading /usr/lib/xorg/modules/drivers/modesetting_drv.so
[     9.691] (II) Module modesetting: vendor="X.Org Foundation"
[     9.691]     compiled for 1.20.4, module version = 1.20.4
[     9.691]     Module class: X.Org Video Driver
[     9.691]     ABI class: X.Org Video Driver, version 24.0
[     9.691] (II) LoadModule: "intel"
[     9.691] (WW) Warning, couldn't open module intel
[     9.691] (EE) Failed to load module "intel" (module does not exist, 0)
[     9.691] (II) LoadModule: "fbdev"
[     9.691] (WW) Warning, couldn't open module fbdev
[     9.691] (EE) Failed to load module "fbdev" (module does not exist, 0)
[     9.691] (II) LoadModule: "vesa"
[     9.691] (II) Loading /usr/lib/xorg/modules/drivers/vesa_drv.so
[     9.691] (II) Module vesa: vendor="X.Org Foundation"
[     9.691]     compiled for 1.20.0, module version = 2.4.0
[     9.691]     Module class: X.Org Video Driver
[     9.691]     ABI class: X.Org Video Driver, version 24.0
[     9.691] (II) modesetting: Driver for Modesetting Kernel Drivers: kms
[     9.691] (II) VESA: driver for VESA chipsets: vesa
[     9.707] (II) modeset(0): using drv /dev/dri/card0
 
JSumrall said:
I'm trying to determine what exactly is happening on system boot with regards to video drivers. Upon reviewing the Xorg.0.log file in /var/log it seems neither Intel or nouveau are being used but something called modesetting.

Code: 
[     9.689] (==) Matched modesetting as autoconfigured driver 0
[     9.689] (==) Matched intel as autoconfigured driver 1
[     9.689] (==) Matched fbdev as autoconfigured driver 2
[     9.689] (==) Matched vesa as autoconfigured driver 3
[     9.689] (==) Assigned the driver to the xf86ConfigLayout
[     9.689] (II) LoadModule: "modesetting"
[     9.689] (II) Loading /usr/lib/xorg/modules/drivers/modesetting_drv.so
[     9.691] (II) Module modesetting: vendor="X.Org Foundation"
[     9.691]     compiled for 1.20.4, module version = 1.20.4
[     9.691]     Module class: X.Org Video Driver
[     9.691]     ABI class: X.Org Video Driver, version 24.0
[     9.691] (II) LoadModule: "intel"
[     9.691] (WW) Warning, couldn't open module intel
[     9.691] (EE) Failed to load module "intel" (module does not exist, 0)
[     9.691] (II) LoadModule: "fbdev"
[     9.691] (WW) Warning, couldn't open module fbdev
[     9.691] (EE) Failed to load module "fbdev" (module does not exist, 0)
[     9.691] (II) LoadModule: "vesa"
[     9.691] (II) Loading /usr/lib/xorg/modules/drivers/vesa_drv.so
[     9.691] (II) Module vesa: vendor="X.Org Foundation"
[     9.691]     compiled for 1.20.0, module version = 2.4.0
[     9.691]     Module class: X.Org Video Driver
[     9.691]     ABI class: X.Org Video Driver, version 24.0
[     9.691] (II) modesetting: Driver for Modesetting Kernel Drivers: kms
[     9.691] (II) VESA: driver for VESA chipsets: vesa
[     9.707] (II) modeset(0): using drv /dev/dri/card0
Click to expand...

Good ole modesetting.

During boot press the E key and add this to the end of the linux line. nouveau.modeset=0

See if that solves the problem. That command disables nouveau on boot. to make it permanent though you should add it to the grub.cfg and re-generate that.
 
Vermillion said:
Good ole modesetting.

During boot press the E key and add this to the end of the linux line. nouveau.modeset=0

See if that solves the problem. That command disables nouveau on boot. to make it permanent though you should add it to the grub.cfg and re-generate that.
Click to expand...

I don't think it is working. I see the grub line in the log file but it seems to still be loading modeset.

Code: 
9.003] Kernel command line: BOOT_IMAGE=/boot/vmlinuz-linux root=UUID=697e957e-94d0-4969-8779-180525028d31 rw quiet nouveau.modeset=0

[     9.029] (==) Matched modesetting as autoconfigured driver 0
[     9.029] (==) Matched intel as autoconfigured driver 1
[     9.029] (==) Matched fbdev as autoconfigured driver 2
[     9.029] (==) Matched vesa as autoconfigured driver 3
[     9.029] (==) Assigned the driver to the xf86ConfigLayout
[     9.029] (II) LoadModule: "modesetting"
[     9.029] (II) Loading /usr/lib/xorg/modules/drivers/modesetting_drv.so
[     9.031] (II) Module modesetting: vendor="X.Org Foundation"
[     9.031]     compiled for 1.20.4, module version = 1.20.4
[     9.031]     Module class: X.Org Video Driver
[     9.031]     ABI class: X.Org Video Driver, version 24.0
[     9.031] (II) LoadModule: "intel"
[     9.031] (WW) Warning, couldn't open module intel
[     9.031] (EE) Failed to load module "intel" (module does not exist, 0)
[     9.031] (II) LoadModule: "fbdev"
[     9.032] (WW) Warning, couldn't open module fbdev
[     9.032] (EE) Failed to load module "fbdev" (module does not exist, 0)
[     9.032] (II) LoadModule: "vesa"
[     9.032] (II) Loading /usr/lib/xorg/modules/drivers/vesa_drv.so
[     9.032] (II) Module vesa: vendor="X.Org Foundation"
[     9.032]     compiled for 1.20.0, module version = 2.4.0
[     9.032]     Module class: X.Org Video Driver
[     9.032]     ABI class: X.Org Video Driver, version 24.0
[     9.032] (II) modesetting: Driver for Modesetting Kernel Drivers: kms
[     9.032] (II) VESA: driver for VESA chipsets: vesa
[     9.048] (II) modeset(0): using drv /dev/dri/card0
[     9.048] (II) modeset(0): Creating default Display subsection in Screen section
    "Default Screen Section" for depth/fbbpp 24/32
[     9.048] (==) modeset(0): Depth 24, (==) framebuffer bpp 32
[     9.048] (==) modeset(0): RGB weight 888
[     9.048] (==) modeset(0): Default visual is TrueColor
 
Although now that I keep re-reading it, it looks like it is using the VESA driver now instead of modesetting.
 
JSumrall said:
I don't think it is working. I see the grub line in the log file but it seems to still be loading modeset.

Code: 
9.003] Kernel command line: BOOT_IMAGE=/boot/vmlinuz-linux root=UUID=697e957e-94d0-4969-8779-180525028d31 rw quiet nouveau.modeset=0

[     9.029] (==) Matched modesetting as autoconfigured driver 0
[     9.029] (==) Matched intel as autoconfigured driver 1
[     9.029] (==) Matched fbdev as autoconfigured driver 2
[     9.029] (==) Matched vesa as autoconfigured driver 3
[     9.029] (==) Assigned the driver to the xf86ConfigLayout
[     9.029] (II) LoadModule: "modesetting"
[     9.029] (II) Loading /usr/lib/xorg/modules/drivers/modesetting_drv.so
[     9.031] (II) Module modesetting: vendor="X.Org Foundation"
[     9.031]     compiled for 1.20.4, module version = 1.20.4
[     9.031]     Module class: X.Org Video Driver
[     9.031]     ABI class: X.Org Video Driver, version 24.0
[     9.031] (II) LoadModule: "intel"
[     9.031] (WW) Warning, couldn't open module intel
[     9.031] (EE) Failed to load module "intel" (module does not exist, 0)
[     9.031] (II) LoadModule: "fbdev"
[     9.032] (WW) Warning, couldn't open module fbdev
[     9.032] (EE) Failed to load module "fbdev" (module does not exist, 0)
[     9.032] (II) LoadModule: "vesa"
[     9.032] (II) Loading /usr/lib/xorg/modules/drivers/vesa_drv.so
[     9.032] (II) Module vesa: vendor="X.Org Foundation"
[     9.032]     compiled for 1.20.0, module version = 2.4.0
[     9.032]     Module class: X.Org Video Driver
[     9.032]     ABI class: X.Org Video Driver, version 24.0
[     9.032] (II) modesetting: Driver for Modesetting Kernel Drivers: kms
[     9.032] (II) VESA: driver for VESA chipsets: vesa
[     9.048] (II) modeset(0): using drv /dev/dri/card0
[     9.048] (II) modeset(0): Creating default Display subsection in Screen section
    "Default Screen Section" for depth/fbbpp 24/32
[     9.048] (==) modeset(0): Depth 24, (==) framebuffer bpp 32
[     9.048] (==) modeset(0): RGB weight 888
[     9.048] (==) modeset(0): Default visual is TrueColor
Click to expand...

https://wiki.archlinux.org/index.php/kernel_mode_setting

nomodeset

is the kernel parameter you probably want to use instead. This will just turn it off. Kernel mode setting is fantastic as long as your not on stupid closed source drivers... that goes for AMD as well as NV.

On Intel and AMD open kernel drivers... it allows for seemless high resolution graphics switching between virtual terminals. CTL+ALT+F1 ect

Boot and add nomodeset to your boot parameters.... if that solves your issue. Then you will want to add that to your mkinitcpio confs and rebuild your boot image.

EDIT: just actually read the bottom of the arch wiki lol;
"Along with nomodeset kernel parameter, for Intel graphics card you need to add i915.modeset=0 and for Nvidia graphics card you need to add nouveau.modeset=0. For Nvidia Optimus dual-graphics system, you need to add all the three kernel parameters (i.e. "nomodeset i915.modeset=0 nouveau.modeset=0")."
 
ChadD said:
https://wiki.archlinux.org/index.php/kernel_mode_setting

nomodeset

is the kernel parameter you probably want to use instead. This will just turn it off. Kernel mode setting is fantastic as long as your not on stupid closed source drivers... that goes for AMD as well as NV.

On Intel and AMD open kernel drivers... it allows for seemless high resolution graphics switching between virtual terminals. CTL+ALT+F1 ect

Boot and add nomodeset to your boot parameters.... if that solves your issue. Then you will want to add that to your mkinitcpio confs and rebuild your boot image.

EDIT: just actually read the bottom of the arch wiki lol;
"Along with nomodeset kernel parameter, for Intel graphics card you need to add i915.modeset=0 and for Nvidia graphics card you need to add nouveau.modeset=0. For Nvidia Optimus dual-graphics system, you need to add all the three kernel parameters (i.e. "nomodeset i915.modeset=0 nouveau.modeset=0")."
Click to expand...

Well, that definitely worked and effectively killed the install. Now it just hangs. HAHA
 
JSumrall said:
Well, that definitely worked and effectively killed the install. Now it just hangs. HAHA
Click to expand...

At least its easy to go back. lol If you just added the parameter in grub it won't survive a reboot. If you did just go into your grub boot parameters and add "systemd.unit=multi-user.target" ... and for that matter I am pretty sure you can just add "3" to your parameters. So like "quite splash 3"
Run mode 3 technically doesn't exist with a systemd running disro... but I believe systemd still has "3" set as an alias for multi-user.target. I'm 99% sure I booted into multi user in manjaro not that long ago by just adding "3".

Anyway that should give you a working terminal to undo any config changes and re build your boot image. lol :)
 
ChadD said:
At least its easy to go back. lol If you just added the parameter in grub it won't survive a reboot. If you did just go into your grub boot parameters and add "systemd.unit=multi-user.target" ... and for that matter I am pretty sure you can just add "3" to your parameters. So like "quite splash 3"
Run mode 3 technically doesn't exist with a systemd running disro... but I believe systemd still has "3" set as an alias for multi-user.target. I'm 99% sure I booted into multi user in manjaro not that long ago by just adding "3".

Anyway that should give you a working terminal to undo any config changes and re build your boot image. lol :)
Click to expand...

I've definitely gotten pretty good at unborking borked systems :D
 
  • Like
Reactions: ChadD
like this
I was able to get the system to stop hanging by disabling the sddm service with systemctl. sddm isn't the problem but it is what was causing the system to hang.

I've got the system booted and I'm typing this from Xfce.

Here's the current status.

I've removed nomodeset and i915.modeset=0 from the linux line in the grub file and the system boots and works.

I installed the xf86-video-intel package and the intel driver seems to list appropriately now

Code: 
00:02.0 VGA compatible controller: Intel Corporation HD Graphics 630 (rev 04) (prog-if 00 [VGA controller])
    DeviceName:  Onboard IGD
    Subsystem: Dell HD Graphics 630
    Flags: bus master, fast devsel, latency 0, IRQ 139
    Memory at eb000000 (64-bit, non-prefetchable) [size=16M]
    Memory at 80000000 (64-bit, prefetchable) [size=256M]
    I/O ports at f000 [size=64]
    [virtual] Expansion ROM at 000c0000 [disabled] [size=128K]
    Capabilities: <access denied>
    Kernel driver in use: i915
    Kernel modules: i915

Still hard to tell from the Xorg.0.log which driver is really being used. I'm going to try adding the i915.modeset=0 back to grub and see what happens.
 
After fiddling with it quite a bit I can't seem to get it to go back to where the second screen works so I'm having to squint at 4k resolution trying to figure it out. Fun.
 
I need a break from the freak show that is nVidia, Optimus, and linux. Think I'm going to try working on netboot.
 
JSumrall said:
I need a break from the freak show that is nVidia, Optimus, and linux. Think I'm going to try working on netboot.
Click to expand...

Optimus and Arch...[Shudder.]

Assuming the Nvidia drivers are installed and running, shouldn't 'prime-select query' without the quotes display what video device is currently active?
 
Mazzspeed said:
Optimus and Arch...[Shudder.]

Assuming the Nvidia drivers are installed and running, shouldn't 'prime-select query' without the quotes display what video device is currently active?
Click to expand...

Yeah, it's a complete joke. You should shudder. I have been every time I see that login prompt. lol

What is the source of that prime-select command? It is saying command not found.
 
JSumrall said:
Yeah, it's a complete joke. You should shudder. I have been every time I see that login prompt. lol

What is the source of that prime-select command? It is saying command not found.
Click to expand...

That command is part of the Nvidia driver package, if it doesn't work it means the drivers aren't installed correctly.

[EDIT] What happens if you open terminal and enter 'nvidia-smi' without quotes?
 
Well, it is a lot of output but I'll try and get it all here.

NVIDIA-SMI 418.56 Driver Version: 418.59 CUDA Version: 10.1
GPU 0 Name GeForce GTX 1050 Persistence-M Off
Bus-ID 00:01:00.0 Disp.A Off

Ok, guess most of the output was headers lol
 
JSumrall said:
I will never, EVER buy an optimus enabled laptop again.

NEVER
Click to expand...

When it comes to laptops, I only use Intel iGPU's and they work awesome.

My desktops however all run Nvidia cards/drivers under Linux and I don't encounter a single issue. However (and this is a big 'however'), my Arch days are over and I tend to stick to Ubuntu based distro's these days.
 
Mazzspeed said:
When it comes to laptops, I only use Intel iGPU's and they work awesome.

My desktops however all run Nvidia cards/drivers under Linux and I don't encounter a single issue. However (and this is a big 'however'), my Arch days are over and I tend to stick to Ubuntu based distro's these days.
Click to expand...

For sanity's sake I don't blame you. Arch is great for learning and having something to fiddle with, but I'm also glad I installed Kubuntu on the laptop on a separate partition so I have something I can actually use without the frustration of trying to figure out why it won't (work).

If the laptop was just running nVidia or just running Intel I think either would be fine. This Optimus crap on Arch is just impossible to figure out.

PRIME: https://wiki.archlinux.org/index.php/PRIME
  • Doesn't work. Most of the time I can't even get xrandr to return without an error.
Optimus: https://wiki.archlinux.org/index.php/NVIDIA_Optimus
  • Didn't work. Couldn't even get XFCE to load past a black screen. Ever.
Bumblebee: https://wiki.archlinux.org/index.php/Bumblebee
  • Didn't work. I got everything to output what it wanted, primarily that the nVidia card was disabled, but still wouldn't work.
Xrun: https://wiki.archlinux.org/index.php/Nvidia-xrun
  • Didn't work. I couldn't even get it to download right from the AUR. It was almost like it didn't even exist anymore.
XPS 15 9560: https://wiki.archlinux.org/index.php/Dell_XPS_15_9560
  • None of the information here seems to work. Primary problem with any of the instructions here is they almost all don't want you to install the nvidia driver, but as I've stated before, the system crashes when you do almost anything without the nvidia driver installed.
 
Hard part is that it's not 'Optimus' as much as it is the lack of a solution for the basic configuration to begin with. Discrete GPU being used with the same outputs as the integrated GPU?

Very thin use case there, really. Nvidia / Microsoft had a reason to get it working, but that's a niche of a niche market itself.
 
IdiotInCharge said:
Hard part is that it's not 'Optimus' as much as it is the lack of a solution for the basic configuration to begin with. Discrete GPU being used with the same outputs as the integrated GPU?

Very thin use case there, really. Nvidia / Microsoft had a reason to get it working, but that's a niche of a niche market itself.
Click to expand...

I don't disagree that's for sure. Whether blame falls on Dell, Microsoft, Nvidia, or Intel, I'm just going to have to stick with the only distro that works on the laptop which is Kubuntu.

I honestly tend to want to say it is more Dell & Nvidia's fault. Dell for not giving you the ability to disable either of the cards in the BIOS and nvidia for their Linux support being so spotty.
 
JSumrall said:
I honestly tend to want to say it is more Dell & Nvidia's fault. Dell for not giving you the ability to disable either of the cards in the BIOS and nvidia for their Linux support being so spotty.
Click to expand...

Can't really blame Nvidia more than anyone else; this goes beyond the driver, for which Nvidia's have been first-class and have been for some time. This is a 'Linux' thing and it would affect Intel and AMD the same if they even had a solution to begin with. Nvidia gets the blame because they've dominated the mobile discrete GPU market with better products and came up with a solution that allowed real-time switching on Windows.

Where you could (and probably should) blame Nvidia is for not contributing a fix to the greater Linux community to include the Linux kernel. Assuming that Intel and AMD are going to push their own solutions at some point, they're far more likely to get the needed support in place outside of the drivers.
 
I'm going to just say, I am absolutely stunned I finally figured this crap out. STUNNED!

ABSOLUTELY STUNNED!

Not only at how simple a solution it is, but the fact the simplicity of the solution hasn't been shared on the internet anywhere to my knowledge.

I'm going to document what I did to solve this problem in another post, but for now, I just want to run around my house screaming PRIME FOR ME IS FIXED!

PRAISE THE LORD AND PASS THE SAUCE! (MASH Adams Ribs episode reference included free of charge)
 
Prefacing this solution with kudos going to the Ubuntu team. They figured this out, I just deconstructed it for Arch.

Kubuntu installed on my PRIME laptop with no problem. So I started working backwords trying to figure out why it worked and Arch was having so many issues.

Through the Xorg.0.log file in Kubuntu I tracked the config file to /usr/share/X11/xorg.conf.d.
With Intel set as the primary driver in nvidia-settings, this configuration file was being used:

10-nvidia.conf

Code: 
Section "OutputClass"
    Identifier "nvidia"
    MatchDriver "nvidia-drm"
    Driver "nvidia"
    Option "AllowEmptyInitialConfiguration"
    ModulePath "/usr/lib/x86_64-linux-gnu/nvidia/xorg"
EndSection

When I used nvidia-settings to switch to the nVidia driver, it generated another file:

11-nvidia-prime.conf
Code: 
Section "OutputClass"
    Identifier "Nvidia Prime"
    MatchDriver "nvidia-drm"
    Driver "nvidia"
    Option "AllowEmptyInitialConfiguration"
    Option "IgnoreDisplayDevices" "CRT"
    Option "PrimaryGPU" "Yes"
    ModulePath "/x86_64-linux-gnu/nvidia/xorg"
EndSection

When I switched back to the Intel driver in nvidia-settings, the system deleted the 11-nvidia-prime.conf file and reverted back to the default 10-nvidia.conf.

Literally it seems Ubuntu's solution of a manual toggle in nVidia settings is to either add or delete the 11-nvidia-prime.conf file.

So I copied these files and emailed them to myself and rebooted into Arch.

In the conf file from Kubuntu you see an entry for ModulePath /x86_64-linux-gnu/nvidia/xorg. In Kubuntu I wrote down the 3 files in this directory which were libglx.so, libglex.so.390.116, and nvidia_drv.so. On Arch, these files are in different locations. Thankfully though on Arch there was a config file already created in /usr/share/X11/xorg.conf.d called 10-nvidia-drm-outputclass.conf. In it the file looked something like this:

Code: 
Section "OutputClass"
    Identifier "intel"
    MatchDriver "i915"
    Driver "modesetting"
EndSection

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

So it included the two ModulePaths needed to complete the config file.

First I started by removing the section for intel completely. I saved it and started Xfce and it immediately worked better than it has ever. Instantly booted and the appropriate dialogues came up.

Next I modified the nvidia section to match the non prime version from Kubuntu and saved it back as 10-nvidia-drm-outputclass.conf:

Code: 
Section "OutputClass"
    Identifier "nvidia"
    MatchDriver "nvidia-drm"
    Driver "nvidia"
    Option "AllowEmptyInitialConfiguration"
ModulePath "/usr/lib/nvidia/xorg"
    ModulePath "/usr/lib/xorg/modules"

I restarted Xfce and once again it loaded fast and worked great.

Next I generated the 11-nvidia-prime.conf file and put the PRIME information in it
Code: 
Section "OutputClass"
    Identifier "Nvidia Prime"
    MatchDriver "nvidia-drm"
    Driver "nvidia"
    Option "AllowEmptyInitialConfiguration"
    Option "IgnoreDisplayDevices" "CRT"
    Option "PrimaryGPU" "Yes"
    ModulePath "/usr/lib/nvidia/xorg"
    ModulePath "/usr/lib/xorg/modules"
EndSection

So I fired up Xfce again and boom, PRIME worked and nVidia settings showed the nvidia driver was now being used.

So basically, all I have to do to switch between intel and nvidia drivers is to add or delete 11-nvidia-prime.conf file in the /usr/share/X11/xorg.conf.d folder. If I delete it, X will default to the Intel driver. If I add it, X will default to nVidia.

I have the nvidia, mesa, xf86-video-intel, and vulkan-intel drivers installed.
 
Thanks for that. I won't bother trying that on this 5510 since it's 100% rock solid stable with just xrandr but I just placed an order at work for three 5530s and one will become mine so I will probably try this on that system as I do my initial Arch install.
 
And on a separate note I started playing with Gentoo again today just for the helluva it. On another E7270....god I forgot how painful this is lol.
 
Vermillion said:
And on a separate note I started playing with Gentoo again today just for the helluva it. On another E7270....god I forgot how painful this is lol.
Click to expand...

I looked at Gentoo yesterday as well and all I could think was Arch 2.0 lol
 
Oddly enough I was installing Arch on that old machine from circa 2007 and it put the same strange conf file with intel and nvidia in it. I thought that was odd considering the machine has no intel video card and just a 8600GT.
 
You must log in or register to reply here.
Back
Top