Information collection thread: Graphics drivers, xorg.conf etc.

[Snurg]

I am going to write an installer for setting up xorg and graphics drivers.
As I currently only have computers with Nvidia graphics, I need information how other graphics chips are set up, in particular Intel and ATI/AMD.
In case anybody is willing to help me, I would be grateful if you can post the following information of your working configuration:

pciconf -lv | grep -A4 vgapci
needed are the lines containing the vgapci devices:

Code:

vgapci0@pci0:15:0:0:    class=0x030000 card=0x084a10de chip=0x0dd810de rev=0xa1 hdr=0x00
    vendor     = 'NVIDIA Corporation'
    device = 'GF106GL [Quadro 2000]'
    class = display
    subclass = VGA

relevant parts of...
...loader.conf

Code:

kern.vty="sc"
nvidia_load="YES"
nvidia_name="nvidia"
nvidia_modeset_load="YES"
nvidia_modeset_name="nvidia-modeset"
linux_load="YES"
module_blacklist="vt vesa"

relevant parts of...
...rc.conf

Code:

linux_enable="YES"

if possible, your full
...xorg.conf

Code:

# nvidia-xconfig: X configuration file generated by nvidia-xconfig
# nvidia-xconfig:  version 390.138  (buildmeister@swio-display-x64-rhel04-03)  Thu May 14 04:05:40 PDT 2020

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

Section "Files"
EndSection

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

Section "InputDevice"
# generated from default
Identifier "Keyboard0"
Driver "keyboard"
EndSection

Section "Monitor"
Identifier "Monitor0"
VendorName "Unknown"
ModelName "Unknown"
HorizSync 28.0 - 33.0
VertRefresh 43.0 - 72.0
Option "DPMS"
EndSection

Section "Device"
Identifier "Device0"
Driver "nvidia"


    VendorName     "NVIDIA Corporation"
EndSection

Section "Screen"
Identifier "Screen0"
Device "Device0"
Monitor "Monitor0"
DefaultDepth 24
SubSection "Display"
Depth 24
EndSubSection
EndSection

Thank you very much!

 

[freebsd_noob]

pciconf -lv

A better command is pciconf -lv | grep -B3 display. Much less output to search.

linux_enable="YES"

Why is enabling the linuxulator relevant for Xorg?

if possible, your full
...xorg.conf

The usage of xorg.conf is discouraged, the autodetection of Xorg works almost flawless these days.

Video cards, monitors, and input devices are automatically detected and do not require any manual configuration. Do not create xorg.conf or run a -configure step unless automatic configuration fails

5.4. Xorg Configuration

On topic:

I use (a rather ancient) Intel card:

Code:

[xx@xx ~]$ pciconf -lv | grep -B3 display
vgapci0@pci0:0:2:0:    class=0x030000 card=0x3048103c chip=0x2e128086 rev=0x03 hdr=0x00
    vendor     = 'Intel Corporation'
    device     = '4 Series Chipset Integrated Graphics Controller'
    class      = display
--
vgapci1@pci0:0:2:1:    class=0x038000 card=0x3048103c chip=0x2e138086 rev=0x03 hdr=0x00
    vendor     = 'Intel Corporation'
    device     = '4 Series Chipset Integrated Graphics Controller'
    class      = display

Relevant entry in /etc/rc.conf:

Code:

kld_list="/boot/modules/i915kms.ko"

/boot/loader.conf

Code:

kern.vty=vt

No Xorg config files.

 

[Snurg]

Good suggestion with the grep! Thanks

Regarding your remarks to...
...linux_enable:
This comes from the nvidia driver (linux binary).
...xorg.conf
It is relevant, in case there is any with Device section regarding the graphics driver.
My plan is to supply a working xorg.conf for all configurations.
It does no damage, and in case it turns out one needs to configure something, it is always convenient when a xorg.conf is already in place.

 

[SirDice]

This comes from the nvidia driver (linux binary).

Sigh, this incorrect information just seems to continue to propagate. The Linux option of the NVidia driver is for providing support for the Linux compatibility layer so you can use the driver with Linux applications. It is NOT required for the driver to work. And you don't need to load it, if the NVidia driver has been built with Linux support it will be automatically loaded, there's no need to do this yourself.

Code:

nvidia_load="YES" 
nvidia_name="nvidia" 
nvidia_modeset_load="YES" 
nvidia_modeset_name="nvidia-modeset" 
linux_load="YES"

All wrong. Use kld_list="nvidia" or kld_list="nvidia-modeset" (depends on the card and driver version).

/boot/loader.conf

Code:

kern.vty=vt

This is the default, no need to explicitly set it.

 

[hruodr]

Code:

# pciconf -lv | grep -B3 display
vgapci0@pci0:0:1:0:     class=0x030000 card=0x84a51043 chip=0x98021002 rev=0x00 hdr=0x00
    vendor     = 'Advanced Micro Devices, Inc. [AMD/ATI]'
    device     = 'Wrestler [Radeon HD 6310]'
    class      = display

All out of the box, nothing in loader.conf, xorg.conf or rc.conf, but I had to install:

Code:

# pkg info | grep video
xf86-video-ati-19.1.0_3,1      X.Org ati display driver
xf86-video-scfb-0.0.5_2        X.Org syscons display driver
xf86-video-vesa-2.5.0          X.Org vesa display driver

 

[Snurg]

Sigh, this incorrect information just seems to continue to propagate. The Linux option of the NVidia driver is for providing support for the Linux compatibility layer so you can use the driver with Linux applications. It is NOT required for the driver to work. And you don't need to load it, if the NVidia driver has been built with Linux support it will be automatically loaded, there's no need to do this yourself.

Thank you for clarifying this!
I guess it won't do damage having the Linux emulation active in case any app wants it.

All wrong. Use kld_list="nvidia" or kld_list="nvidia-modeset" (depends on the card and driver version).

My installer will grab and use the most recent driver from the nvidia website available for a particular chipset, which is atm 390.141 for newer cards.
The configuration is done via nvidia-xconfig, so the configuration is exactly the way Nvidia recommends.
These are configured differently than the old packaged 304 and 340 drivers, which my installer will not use, as the current drivers are more reliable.
For legacy cards, the latest according drivers will be downloaded and installed from the Nvidia driver site, i.e. 367, 340, 304, 173, 96 or 71.

 

[SirDice]

My installer will grab and use the most recent driver from the nvidia website available

Don't. Use the port, x11/nvidia-driver. The reason is that the NVidia driver install replaces a couple of Xorg libraries. The port takes care of this, the nvidia installer doesn't. There's no reason to use the driver from the NVidia website, the port is kept reasonably up to date. And this also registers correctly with the package database. Anything you install outside of this won't be registered.

which is atm 390.141 for newer cards.

It's 460.39, which is also the version that's available as a port/package. 390 is a legacy version, x11/nvidia-driver-390.

The configuration is done via nvidia-xconfig, so the configuration is exactly the way Nvidia recommends.

It's not. It's just a tool that generates an old school xorg.conf, which you don't need any more. NVidia doesn't recommend anything in this regard.

 

[Snurg]

Don't. Use the port, x11/nvidia-driver. The reason is that the NVidia driver install replaces a couple of Xorg libraries. The port takes care of this, the nvidia installer doesn't.

Mhh that is interesting!
Sounds like that this could result in update breakages. Need to look into that, which libs get replaced.
For my the reason not to use the packaged drivers is the higher (i.e. 100%) reliability of the current "original nvidia" drivers regarding suspend/resume.

Okay, I will add an option to use the packaged driver if the installed card is supported by it, in case people prefer to use that.

 

[freebsd_noob]

Okay, I will add an option to use the packaged driver if the installed card is supported by it, in case people prefer to use that.

This option should be enabled by default. Because

And this also registers correctly with the package database. Anything you install outside of this won't be registered.

I don't want to run down your effort to write an automated installer but:

Installing packages outside the package database in counterproductive.

You say that it is "tedious, time-consuming and not at all rewarding to manually fill out the gap between bsdinstall and having a working desktop system."
I disagree. It's fun, easy and rewarding because you learn something. And you do it once and then never again.

I quote Trihexagonal

But I don't see it as a tedious task. I see it as a labor of love, ability and individualism to get my own ground-up custom built FreeBSD desktop complied by me from source and like no other you see in any screenshot.

The work to keep this installer up-to-date and working with all sorts of graphic cards will be enormous.

I think a better approach would be to just point people to https://docs.freebsd.org/en/books/handbook/x11/
The handbook is excellent and it's there for a reason.

 

[Snurg]

It's fun, easy and rewarding because you learn something. And you do it once and then never again.

I have done it too often, and I find it more rewarding to write an installer than doing that manually again

The work to keep this installer up-to-date and working with all sorts of graphic cards will be enormous.

80% of the work is needed for Nvidia, i915 and amdgpu do not need much work.

 

[Zirias]

Hm, in general, setting up a FreeBSD desktop consists of two things:

* Configure the base system to be more suitable for a desktop (some sysctls, some devfs rules and config, ...)
* Install packages

I don't think that's all too tedious, but automating it *might* be useful for some users. Anyways, I agree, such an installer should *never* circumvent the package database by default.

If on your system, the upstream nvidia driver works somehow "better", that's an edge-case, and sure, your installer *might* offer to use it, but should add a big fat warning about the consequences.

There could be other edge cases no installer could ever handle, like e.g. on my 12.2 desktop with an aging AMD APU, I need to use drm-fbsd11.2-kmod, because the version in -fbsd12.0- contains a bug (obviously from upstream Linux) hitting exactly my graphics chip. IMHO no way to handle *such* things in an installer.

 

[shkhln]

Don't. Use the port, x11/nvidia-driver.

Seconded. If you don't like specific applied patches, fork the port and throw them out.

If on your system, the upstream nvidia driver works somehow "better", that's an edge-case, and sure, your installer *might* offer to use it, but should add a big fat warning about the consequences.

It certainly isn't. Linux compat is entirely broken out the box, for example.

 

[Zirias]

Linux compat is entirely broken out the box, for example.

You mean in the port? Then it must be fixed there…

 

[Beastie7]

I would like make something that probes, sets up, and configuration all hardware/ACPI interfaces. This could also be an API that KDE recognizes and can give me a damn power off button, or brightness change indicators. Like a SMIT-like or ncurses version Windows device driver manager or something.. I need the system to tell me what doesn't work, and what does work. What's supported and what isn't. Having to sift through sysctls, kmods, tuning rc.conf/loader.conf, etc, is very tedious and frustrating. CLI desktop administration is fine, but fscking around with hardware is not worth my time; it gives me Windows XP nightmares. Especially when the system doesn't even save my ACPI settings that I set for brightness, etc. I was on the verge of giving up the other day. Adopting OpenRC would fix a lot of this.

 

[shkhln]

You mean in the port? Then it must be fixed there…

No, the other way around.

 

[hruodr]

For my the reason not to use the packaged drivers is the higher (i.e. 100%) reliability of the current "original nvidia" drivers regarding suspend/resume.

I think, packaged by default, other optional with warning, is the better solution for people that
want transparency, do not want to spend much time understanding the system, configuring
and troubleshooting if something did not work.

I agree with you, one has other things to do than configure and administer the system, one wants to
do his work with the computer. For that reason I like the package system, although I do compile some
software.

 

[Snurg]

I need the system to tell me what doesn't work, and what does work. What's supported and what isn't. Having to sift through sysctls, kmods, tuning rc.conf/loader.conf, etc, is very tedious and frustrating. CLI desktop administration is fine, but fscking around with hardware is not worth my time

Exactly.
What I already have implemented is a postinstaller that installs and boots up a webserver running a CGI as root, to do all that crap interactively, and nicely presented, with more than 80x24 screen space.
Either using a browser on another computer (especially when no GUI gets installed on that particular computer), or on the computer itself, be it using lynx or a graphical browser on top of X. This is the part I will add next.

 

[freebsd_noob]

a postinstaller that installs and boots up a webserver running a CGI as root, to do all that crap interactively.

Why not a simple shell script or ncurses application? Installing a webserver and use lynx in order to configure X is a bit... overkill.

 

[Snurg]

Why not a simple shell script or ncurses application? Installing a webserver in order to configure X is a bit... overkill.

Hehe no. This is only the beginning, the real purpose is to provide a basis to easily do all this fine tuning (sysctl, dev, rc.conf etc) so no step gets forgotten, and administer things like network, pf and jails in an easy way, without need for CLI.
Just a toolbox that the community can use and contribute to.

Edit: I use [PMAN=]dialog[/PMAN] for the basic setup. The more complex things are easier done with HTML, lynx is only needed if you want to locally set up/configure a non-GUI computer without using anothers' computers' browser.

 

[Zirias]

No, the other way around.

Then you misinterpreted what I meant with "upstream" But nevermind!

 

[shkhln]

Then you misinterpreted what I meant with "upstream" But nevermind!

I'm assuming upstream = Nvidia. My reply is entirely consistent with this assumption.

 

[Zirias]

Well, no. But I won't continue arguing about the semantics of the english language…

 

[shkhln]

Besides "it" being inherently ambiguous I really don't see anything wrong with that sentence. You act like it's obvious, but it's not.

 

[hruodr]

What I already have implemented is a postinstaller that installs and boots up a webserver running a CGI as root,

If you use a language like tcl for your project, you may perhaps write a small, special purpose
http-server (not even cgi necessary). Perhaps only few lines.

You can see examples to begin with here:

The Smallest Tcl Web Server

Tclers wiki

wiki.tcl-lang.org

The difficult thing to write is the http client, not the server, specially if the purpose is very restricted.
And here you see a description of the protocoll:

HTTP Made Really Easy

Tutorial: Quickly learn how to use HTTP in your network applications, if you know basic sockets programming. Covers HTTP 1.0 and HTTP 1.1. Includes sample clients in Perl.

www.jmarshall.com

 

[Snurg]

Didn't know one can use even Tcl for web serving...
I am used to Perl, it is powerful like shell and easy like BASIC.
CGI script size is heavy. The integrated web based jail manager alone is a few thousand lines.