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

Snurg

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!
 
Snurg said:
pciconf -lv
Click to expand...
A better command is pciconf -lv | grep -B3 display. Much less output to search.
Snurg said:
linux_enable="YES"
Click to expand...
Why is enabling the linuxulator relevant for Xorg?
Snurg said:
if possible, your full
...xorg.conf
Click to expand...
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
Click to expand...
docs.freebsd.org

Chapter 5. The X Window System

This chapter describes how to install and configure Xorg on FreeBSD, which provides the open source X Window System used to provide a graphical environment
docs.freebsd.org docs.freebsd.org

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.
 
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.
 
Snurg said:
This comes from the nvidia driver (linux binary).
Click to expand...
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.
Snurg said:
Code: 
nvidia_load="YES" 
nvidia_name="nvidia" 
nvidia_modeset_load="YES" 
nvidia_modeset_name="nvidia-modeset" 
linux_load="YES"
Click to expand...
All wrong. Use kld_list="nvidia" or kld_list="nvidia-modeset" (depends on the card and driver version).


freebsd_noob said:
/boot/loader.conf
Code: 
kern.vty=vt
Click to expand...
This is the default, no need to explicitly set it.
 
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
 
SirDice said:
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.
Click to expand...
Thank you for clarifying this!
I guess it won't do damage having the Linux emulation active in case any app wants it.

SirDice said:
All wrong. Use kld_list="nvidia" or kld_list="nvidia-modeset" (depends on the card and driver version).
Click to expand...
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.
 
Snurg said:
My installer will grab and use the most recent driver from the nvidia website available
Click to expand...
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.

Snurg said:
which is atm 390.141 for newer cards.
Click to expand...
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.

Snurg said:
The configuration is done via nvidia-xconfig, so the configuration is exactly the way Nvidia recommends.
Click to expand...
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.
 
SirDice said:
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.
Click to expand...
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.
 
Snurg said:
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.
Click to expand...
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.
Click to expand...

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.
Click to expand...

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.
 
freebsd_noob said:
It's fun, easy and rewarding because you learn something. And you do it once and then never again.
Click to expand...
I have done it too often, and I find it more rewarding to write an installer than doing that manually again :)

freebsd_noob said:
The work to keep this installer up-to-date and working with all sorts of graphic cards will be enormous.
Click to expand...
80% of the work is needed for Nvidia, i915 and amdgpu do not need much work.
 
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.
 
SirDice said:
Don't. Use the port, x11/nvidia-driver.
Click to expand...
Seconded. If you don't like specific applied patches, fork the port and throw them out.

Zirias said:
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.
Click to expand...
It certainly isn't. Linux compat is entirely broken out the box, for example.
 
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.
 
Snurg said:
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.
Click to expand...
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.
 
Beastie7 said:
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
Click to expand...
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 said:
Why not a simple shell script or ncurses application? Installing a webserver in order to configure X is a bit... overkill.
Click to expand...
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.
 
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.
 
Snurg said:
What I already have implemented is a postinstaller that installs and boots up a webserver running a CGI as root,
Click to expand...
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 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
 
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.
 
You must log in or register to reply here.
Back
Top