Solved Dual Monitor Question... (NVIDIA Driver)

Hi guys,

I have a question... The second monitor is enabled only when X.org starts, is it possible firing it up earlier, at the boot-loader screen?

Thanks!

Code:
$ freebsd-version -k
13.0-RELEASE-p7
 
Code:
vgapci0@pci0:1:0:0:    class=0x030000 rev=0xa1 hdr=0x00 vendor=0x10de device=0x1618 subvendor=0x1558 subdevice=0x7703
    vendor     = 'NVIDIA Corporation'
    device     = 'GM204M [GeForce GTX 970M]'
    class      = display
    subclass   = VGA
 
Thanks. Next:

sysrc -f /etc/rc.conf kld_list

Depending on which NVIDIA-related kernel module is normally loaded, you might be able to safely load it earlier with loader.conf(5). Sorry, maybe early but not early for multiple displays (thanks SirDice for the sanity check below).

For convenience, here's a highlighted screenshot <https://forums.freebsd.org/posts/551939> of the package message <https://www.freshports.org/x11/nvidia-driver/#message> for nvidia-driver (if that's the package that you use).
 
Console is single monitor only. Remember, the console was once a serial terminal.
exactly this.

However, some firmwares (e.g. on laptops) default to cloning the output to the second monitor until they are told to do otherwise (i.e. until the driver loads and directly addresses each individual output).

When using a dedicated GPU for your second monitor, you might be able to select the primary output in your BIOS/UEFI. Otherwise the POST and default console output will always go to the first ("primary") GPU/output/monitor that is detected and single-screen only as SirDice pointed out
 
Apropos cloning output to a second monitor, it looks like it is possible to clone the same console to a second monitor with the help of a KMS video driver:

 
Apropos cloning output to a second monitor, it looks like it is possible to clone the same console to a second monitor with the help of a KMS video driver:


This is actually what I was looking for, I hope to be able to setup it properly... 🙏
 
I tried, but I didn't understand anything... 😩

kern.vt.fb.modes.connector_name
Set this value to a graphic mode to override the default mode
picked by the vt backend. This mode is applied to the output
connector connector_name only. It has precedence over
kern.vt.fb.default_mode. The names of available connector names
can be found in dmesg(8) after loading the KMS driver. It will
contain a list of connectors and their associated tunables. This
is currently only supported by the vt_fb backend when it is
paired with a KMS video driver.

Not sure about the connectors name, I couldn't find anything in DMESG but:

Code:
nvidia0: <NVIDIA GeForce GTX 970M> on vgapci0
   : child nvidia0 requested pci_enable_io
vgapci0: child nvidia0 requested pci_enable_io
nvidia-modeset: Loading NVIDIA Kernel Mode Setting Driver for UNIX platforms  470.86  Tue Oct 26 21:43:42 UTC 2021

Furthermore I could not find any KMS in the DMESG output, only nvidia-modeset...

Anyway Xrandr shows some connectors:

Code:
Screen 0: minimum 8 x 8, current 3840 x 1080, maximum 16384 x 16384
VGA-0 disconnected (normal left inverted right x axis y axis)
LVDS-0 disconnected (normal left inverted right x axis y axis)
HDMI-0 disconnected (normal left inverted right x axis y axis)
DP-0 connected 1920x1080+0+0 (normal left inverted right x axis y axis) 382mm x 215mm
   1920x1080     60.02*+
DP-1 connected primary 1920x1080+1920+0 (normal left inverted right x axis y axis) 527mm x 296mm
   1920x1080     60.00*+
   1600x900      60.00  
   1280x1024     75.02    60.02  
   1152x864      75.00  
   1024x768      75.03    60.00  
   800x600       75.00    60.32  
   640x480       75.00    59.94  
DP-2 disconnected (normal left inverted right x axis y axis)
DP-3 disconnected (normal left inverted right x axis y axis)
DP-4 disconnected (normal left inverted right x axis y axis)

Random proofs:

kern.vt.fb.modes.HDMI-DP-1="1920x1080" DID NOT WORK!
kern.vt.fb.modes.vgapci0="1920x1080" DID NOT WORK!
kern.vt.fb.modes.HDMI-A-2="1920x1080" DID NOT WORK!


Thanks... 🤷‍♂️
 
You can just do sysctl kern.vt, it is of course only available if you are actually using vt(4), which it should, it's been the default console driver for quite some time now.
 
Not knowing something is not the same as being dumb. Dumb is when you know something and still do it the wrong way.

I don't know... I read the man pages and really struggle to get what is written in there, I recognize my limits... 😩
 
I read the man pages and really struggle to get what is written in there
The "problem" with many man pages is that they are for reference, not for gaining an understanding of how it works. References are useful but only if you already know what you're looking for. For comparison, a C/C++ reference manual just tells you what each function does, not where or when to use them. It's not going to teach you how to program in C/C++.

I recognize my limits...
That's a sign of intelligence actually. The more you know about everything the more you realize you know nothing about anything.
 
I don't think the x11/nvidia-driver is capable of multi monitor in the console, only in Xorg.

Your systems dmesg(8) doesn't show any monitor connector names, which indicates there is no support.

Those KVM video drivers mentioned by the user and vt(1) manual I linked to are from graphics/drm-kmod.

Have you checked if your laptop has a BIOS/UEFI setting to clone the output as sko suggested?
 
I don't think the x11/nvidia-driver is capable of multi monitor in the console, only in Xorg.

Your systems dmesg(8) doesn't show any monitor connector names, which indicates there is no support.

Those KVM video drivers mentioned by the user and vt(1) manual I linked to are from graphics/drm-kmod.

Have you checked if your laptop has a BIOS/UEFI setting to clone the output as sko suggested?

The BIOS doesn't not have any setting for this...

But what about option 5 in the bootloader?
 
You can just do sysctl kern.vt, it is of course only available if you are actually using vt(4), which it should, it's been the default console driver for quite some time now.

Here we are...

Code:
sysctl kern.vt
kern.vt.splash_cpu_duration: 10
kern.vt.splash_cpu_style: 2
kern.vt.splash_ncpu: 0
kern.vt.splash_cpu: 0
kern.vt.kbd_panic: 0
kern.vt.kbd_debug: 1
kern.vt.kbd_reboot: 1
kern.vt.kbd_poweroff: 1
kern.vt.kbd_halt: 1
kern.vt.suspendswitch: 1
kern.vt.deadtimer: 15
kern.vt.debug: 0
kern.vt.enable_bell: 1
kern.vt.enable_altgr: 1

I don't see anything... 🤔

however after reading several time the handbook I couldn't find any evidence that nvidia-modeset is somehow related to the kernel mode setting...

Intel KMS driver, Radeon KMS driver, AMD KMS driver
2D and 3D acceleration is supported on most Intel KMS driver graphics cards provided by Intel.

Driver name: i915kms
2D and 3D acceleration is supported on most older Radeon KMS driver graphics cards provided by AMD.
Driver name: radeonkms
2D and 3D acceleration is supported on most newer AMD KMS driver graphics cards provided by AMD.
Driver name: amdgpu

Having it would have been fine, but... 🤷‍♂️
 
… handbook … couldn't find … nvidia-modeset is somehow related to the kernel mode setting

For this level of detail about a port, I should not expect to find details in the FreeBSD Handbook. IMHO it's already too cluttered.

Instead, look first to the port and what's given by the maintainer(s). The package message (above) mentions version 358.09.

FreeBSD Display Driver – x64 | 358.09 | FreeBSD x64 | NVIDIA

The fourth bullet-pointed release highlight:

Added a new kernel module, nvidia-modeset.ko. This new driver component works in conjunction with the nvidia.ko kernel module to program the display engine of the GPU.

nvidia-modeset.ko does not provide any new user-visible functionality or interfaces to third party applications. However, in a later release, nvidia-modeset.ko will be used as a basis for the modesetting interface provided by the kernel's direct rendering manager (DRM).

HTH
 
Back
Top