conflict with xlibre-server and xlibre-nvidia-driver.

ffn

Hello GhostBSD developers,

I hope you are doing well. I am a user of GhostBSD on an HP Pavilion Gaming 15-cx0 (Intel UHD 630 + NVIDIA GTX 1050 Mobile).

I have successfully configured both cards using xorg-server via a custom xorg.conf. However, I am now trying to migrate to xlibre to test its performance on this hardware.

I have encountered a dependency deadlock that prevents this:

I need to install nvidia-drm-kmod for KMS support.

nvidia-drm-kmod depends on nvidia-driver.

The nvidia-driver in the official repositories strictly depends on xorg-server.

This creates a direct conflict with xlibre-server and xlibre-nvidia-driver.

Is there a recommended way to bypass the xorg-server dependency check in the GhostBSD package manager? Or perhaps, are there plans to provide a xlibre-compatible version of the DRM kmod? Currently, the rigid dependency tree prevents testing this alternative X server on hardware that requires the proprietary driver.

ericbsd

DRM kmod itself is compatible, but we forgot about the NVIDIA DRM Kmod. I do not think there is a way to have that done other than by using the ports to build it for Xlibre. I will look into adding that.

Oh, since you have that working with Xorg, could you give a how-to on how you set up your Intel UHD 630 + NVIDIA GTX 1050 system? That would help me to make that automatic for users with both Intel and NVIDIA GPUs.

ffn

"Thank you for your response! I am happy to share the details of my configuration to help with the automation process.

To get the hybrid system working, I had to make the following adjustments:

1. Kernel & Boot Configuration In /boot/loader.conf, I enabled modesetting for the NVIDIA DRM driver: hw.nvidiadrm.modeset=1

In /etc/rc.conf, I ensured the modules are loaded in a specific order, prioritizing the Intel KMS driver before the NVIDIA modules: kld_list="i915kms cuse coretemp linux linux64 fusefs nvidia-modeset nvidia-drm nvidia acpi_video acpi_call fusefs hgame"

2. Xorg Configuration My xorg.conf requires explicitly defining two screens and two layouts to manage the provider handoff correctly. Notably, I set AccelMethod "none" for the Intel device to stabilize the output.

my xorg.conf:

Section "Module"
Load "glx"
EndSection

Section "ServerLayout"
Identifier "Layout0"
Screen 0 "Screen0"
InputDevice "Keyboard0" "CoreKeyboard"
InputDevice "Mouse0" "CorePointer"
Option "Xinerama" "0"
EndSection

Section "ServerLayout"
Identifier "Layout1"
Screen 1 "Screen1"
InputDevice "Keyboard0" "CoreKeyboard"
InputDevice "Mouse0" "CorePointer"
Option "Xinerama" "1"
EndSection

Section "Files"
EndSection

Section "Module"
Load "dbe"
Load "extmod"
Load "type1"
Load "freetype"
Load "glx"
EndSection

Section "InputDevice"
Identifier "Mouse0"
Driver "mouse"
Option "Protocol" "auto"
Option "Device" "/dev/sysmouse"
Option "Emulate3Buttons" "no"
Option "ZAxisMapping" "4 5"
EndSection

Section "InputDevice"
Identifier "Keyboard0"
Driver "keyboard"
EndSection

Section "Monitor"
Identifier "Monitor0"
VendorName "Unknown"
ModelName "Unknown"
Option "DPMS"
EndSection

Section "Monitor"
Identifier "Monitor1"
VendorName "Unknown"
ModelName "Unknown"
Option "DPMS"
EndSection

Section "Device"
Identifier "Device0"
Driver "nvidia"
VendorName "NVIDIA Corporation"
BoardName "NVIDIA GeForce GTX 1050"
BusID "PCI:1:0:0"
EndSection

Section "Device"
Identifier "Device1"
Driver "modesetting"
Option "AccelMethod" "none"
BusID "PCI:0:2:0"
Option "AsyncFlipSecondaries" "on"
EndSection

Section "Screen"
Identifier "Screen0"
Device "Device0"
Monitor "Monitor0"
DefaultDepth 24
Option "Stereo" "0"
Option "nvidiaXineramaInfoOrder" "HDMI-0"
Option "metamodes" "nvidia-auto-select +0+0 {ForceCompositionPipeline=On, ForceFullCompositionPipeline=On}"
Option "SLI" "Off"
Option "MultiGPU" "Off"
Option "BaseMosaic" "off"
SubSection "Display"
Depth 24
EndSubSection
EndSection

Section "Screen"
Identifier "Screen1"
Device "Device1"
Monitor "Monitor1"
DefaultDepth 24
Option "Stereo" "1"
Option "nvidiaXineramaInfoOrder" "eDP-1-1"
Option "SLI" "Off"
Option "MultiGPU" "Off"
Option "BaseMosaic" "off"
SubSection "Display"
Depth 24
EndSubSection
EndSection

ffn

Hi Eric,
Regarding the NVIDIA DRM Kmod and Xlibre compatibility, I have some great new. I managed to get it working by manually adjusting the ports.

Here is what I did to fix the dependency and build it correctly:

1. Port Modification

I modified /usr/ports/x11/nvidia-driver/Makefile (specifically affecting the Xlibre flavor logic) to ensure it targets the second flavor:

Makefile

# Line 32 approximately
FLAVORS=        xorg xlibre
FLAVOR?=        ${FLAVORS:[2]}

2. Recompilation

After that, I recompiled both the driver and the DRM kernel module:

cd /usr/ports/x11/nvidia-driver && make reinstall
cd /usr/ports/graphics/nvidia-drm-kmod/ && make reinstall

3. Installed Packages

After the build, these are the current packages associated with NVIDIA and Xlibre on my system:

libva-nvidia-driver-0.0.16
nvidia-drm-66-kmod-580.126.18.1500068
nvidia-drm-kmod-580.126.18
nvidia-kmod-580.126.18.1500068 k
nvidia-settings-580.126.18
xlibre-nvidia-driver-580.126.18
xlibre-minimal-1.0_1
xlibre-nvidia-driver-580.126.18
xlibre-server-25.1.2_1
xlibre-xf86-input-evdev-25.0.0_1
xlibre-xf86-input-joystick-25.0.0_1
xlibre-xf86-input-keyboard-25.0.0_1
xlibre-xf86-input-libinput-25.0.1_1
xlibre-xf86-input-mouse-25.0.0_1
xlibre-xf86-input-synaptics-25.0.0_1
xlibre-xf86-input-vmmouse-25.0.0_1
xlibre-xf86-video-vesa-25.0.0_2

The system is now stable with this setup. I hope this helps you streamline the automation for other users!"

One remaining issue I’ve encountered is the display priority during login. LightDM currently defaults to the external screen connected to the HDMI port (NVIDIA) instead of the internal laptop screen (Intel). It seems LightDM is prioritizing the NVIDIA output as the primary display by default.

ghostbsd-261-r150p2-xlibre-ntel-nvidia-laptop-2026-03-09-23-02-59.png

ffn

Hi Eric,

I hope you are doing well. I wanted to share a script I’ve been using successfully in GhostBSD to handle display output during the LightDM login phase, specifically on a laptop with an Intel-Nvidia hybrid setup.

In this configuration, it seems the Nvidia card takes control of the buffer, which can cause display issues during the initial login. I’ve found that forcing the output configuration through xrandr within LightDM’s setup script solves this effectively.

#/usr/local/bin/lightdm-xrandr-setup.sh

#!/bin/sh
# Detect if HDMI-0 is connected (Nvidia buffer management)
if xrandr | grep -q "HDMI-0 connected"; then
# If connected, clone screens to ensure visibility
xrandr --output HDMI-0 --auto --output eDP-1-1 --auto --same-as HDMI-0
else
# If not, ensure the laptop screen (eDP) is the only one active
xrandr --output eDP-1-1 --auto --output HDMI-0 --off
fi
# Set default brightness
backlight 60

I added the following to my LightDM configuration
[Seat:*]
display-setup-script=/usr/local/bin/lightdm-xrandr-setup.sh

sudo chmod +x /usr/local/bin/lightdm-xrandr-setup.sh

This ensures the login screen is correctly rendered regardless of whether an external monitor is plugged in. I thought this might be a helpful reference for other users dealing with similar hybrid GPU issues in GhostBSD.