Introduction

Graphics team members help to maintain the low-level components that support desktop environments (DEs) such as KDE Plasma and Gnome.

This level includes:

• X.Org-related ports – X server, libraries, tools

• Wayland

• Mesa ports – libGL, dri, libglesv2, libEGL, freeglut, libGLU, libGLw, mesa-demos, libosmesa

• OpenCL low-level libraries

• Userland drivers – xf86-*

• Input device detection and configuration

• GPU drivers – drm-* kernel modules.

This level does not include:

• The desktop environments themselves
• Image processing or drawing software applications.

Hardware Support

If neither drm-kmod nor NVIDIA graphics software (below) supports your hardware – and if your computer uses UEFI – you may use the system console frame buffer (SCFB). See x11-drivers/xf86-video-scfb and GraphicsOld/SCFB.

Features that will not work with the system console frame buffer include:

• sleep and wake (suspend and resume) of the computer.

drm-kmod

graphics/drm-kmod indirectly provides a range of kernel modules for use with:

• AMD graphics hardware
• Intel Integrated Graphics.

AMD graphics

Two modules exist for AMD hardware:

• amdgpu
• radeonkms

– choose one, based on the generation of the hardware.

In most cases:

• Manual configuration of X.Org is not required.

We have an AMD graphics support matrix. The X.Org project provides a Decoder ring for engineering vs marketing names.

If UEFI boot results in a conflict between a driver and the EFI frame buffer, you can add this line to /boot/loader.conf to disable the buffer:

• hw.syscons.disable=1

With the buffer disabled, console output will not appear until the driver loads. https://github.com/FreeBSDDesktop/DEPRECATED-freebsd-base-graphics/issues/170 explains.

AMD GPU

The amdgpu module is for post-HD7000 or Tahiti GPUs.

• Install the graphics/drm-kmod package

  • # pkg install drm-kmod

• The post-installation message presents essential information. With FreeBSD 13⋯, this command will safely configure your /etc/rc.conf:

  • # sysrc -f /etc/rc.conf kld_list+=amdgpu

• Ensure that your UID is a member of the video group.

• Restart your system. You should see amdgpu listed, and a flash of the console when the display driver is switched.

• Start X.Org via your usual method (i.e. startx, GDM, etc.)

Radeon KMS (kernel mode setting)

The radeonkms module is for older GPUs (pre-HD7000 or pre-Tahiti).

• Install the graphics/drm-kmod package

  • # pkg install drm-kmod

• The post-installation message presents essential information. With FreeBSD 13⋯, this command will safely configure your /etc/rc.conf:

  • # sysrc -f /etc/rc.conf kld_list+=radeonkms

• Ensure that your UID is a member of the video group.

• Restart your system. You should see radeonkms listed, and a flash of the console when the display driver is switched.

• Start X.Org via your usual method (i.e. startx, GDM, etc.)

Intel Integrated Graphics (aka HD Graphics)

Intel HD Graphics refers to the class of graphics chips that are integrated on the same die as an Intel CPU. Wikipedia offers a good overview of the variations and names used for generations of Intel HD Graphics. Intel HD Graphics chips are found in many modern laptop and desktop systems that ship with an Intel CPU. Commonly-found configurations include Kabylake Intel i915 HD Graphics.

To enable the integrated graphics chip on Intel CPUs, install drm-kmod. The resulting module should work well on all compatible systems.

This page includes a table of states for various Intel chipsets.

If you notice high CPU usage, or excessive tearing with HD video: multimedia/libva-intel-driver may help – installation should be in addition to drm-kmod, mesa-libs and mesa-dri.

Example configuration:

• Install the graphics/drm-kmod package

  • # pkg install drm-kmod

• The post-installation message presents essential information. With FreeBSD 13⋯, this command will safely configure your /etc/rc.conf:

  • # sysrc -f /etc/rc.conf kld_list+=i915kms

• Ensure that your UID is a member of the video group.

• Restart your system. You should see i915kms listed, and a flash of the console when the display driver is switched.

• Start X.Org via your usual method (i.e. startx, GDM, etc.)

In most cases:

• Manual configuration of X.Org is not required

• x11-drivers/xf86-video-intel is optional

– X.Org should autodetect the driver, and utilize the modesetting X.Org driver and glamor driver.

NVIDIA graphics

nvidia-driver

Five drivers are ported and packaged:

• 304.137 https://www.nvidia.com/Download/driverResults.aspx/123712/en-us/ is packaged at x11/nvidia-driver-304 and does not support x11-servers/xorg-server 1.20 or greater

• 340.108 https://www.nvidia.com/Download/driverResults.aspx/156167/en-us/ is packaged at x11/nvidia-driver-340

• 390.154 https://www.nvidia.com/Download/driverResults.aspx/191122/en-us/ is packaged at x11/nvidia-driver-390

• 470.161.03 https://www.nvidia.com/Download/driverResults.aspx/194639/en-us/ is packaged at x11/nvidia-driver-470

• 515.86.01 https://www.nvidia.com/Download/driverResults.aspx/194664/en-us/ is packaged at x11/nvidia-driver.

The number of available ports, and the related links, will vary.

NVIDIA-provided pages:

• list supported products (users can learn which driver to choose)
• offer downloads for source code (not package-oriented).

Most users will prefer a package.

Configuration

For versions prior to 358.09:

# sysrc -f /etc/rc.conf kld_list+=nvidia

For superior versions:

# sysrc -f /etc/rc.conf kld_list+=nvidia-modeset

x11/nvidia-xconfig can simplify X.Org configuration.

nvidia-drm

Announcing nvidia-drm port and Call for Testing (2022-11-13)

General

Other NVIDIA-related areas include:

• MarkLinimon/WorkAreaGraphics/NVidia (outdated)

• NvidiaFeatureRequests (stale)

• How can I get 3D hardware acceleration for OpenGL®? (outdated) amongst answers to FAQ

• Video Cards (outdated) in the FreeBSD Handbook

• FreeBSD bugs:

  • 260199 – FAQ references to NVIDIA resources

  • 264389 – Handbook has misleading information concerning wayland on NVIDIA

Virtual machines

VMware

Experimental support for accelerated graphics in FreeBSD as guest OS in VMware was added to graphics/drm-devel-kmod.

Known issue:

• A race condition in which the machine locks when loading the graphics driver or starting X. Observable only if the guest is configured with more than one CPU.

VirtualBox

A DRM driver for VirtualBox is planned for the Linux source tree. Once there, a FreeBSD port is planned.

Side notes

The tables that were once here were not a comprehensive record of supported hardware:

• hardware was listed only if it had been explicitly tested/confirmed by developers and/or users
• graphics hardware missing from the tables may or may not work.

GPU codenames vs. marketing names:

• entries may be misleading because they use marketing names as the key

• the table needed to be rewritten using GPU codenames as the key.

If you have tested hardware that is not listed, please report the results.

Known issues

Permission errors, or inability to start X when using drm-kmod.

• For access to /dev/drm/ devices, the user should be a member of the video group.

Xorg -configure crashes with a segmentation fault.

• Do not run this command – X.Org configuration is automated.

• If a section override is required, place the file for the section in /usr/local/etc/X11/xorg.conf.d/.

Problems with drm-kmod on i386.

• Disable PAE – add hw.above4g_allow=0 to /boot/loader.conf.

Reporting

Issues/bugs

If encountering problems in either the kernel driver or the in-development ports, post the following information to the mailing list

• dmesg command output

• pciconf -lvbce command output

• devinfo -vr command output

• sysctl hw.model

• pkg info command output

• Contents of xorg.conf file (and included sub-files, if any)

• Contents of Xorg.log (if the problem is at X.Org startup or during your X session)
• Any ports build or installation errors (if relevant)

• If a kernel panic: Contents of core.$n.txt (in /var/crash)

• Any other details that may be relevant

Debugging tips

• It is useful to see what features the kernel reports as being available, especially in regards to driver features exposed via the linuxkpi. On FreeBSD these are mapped to sysctl compat.linuxkpi. The best way to see what's available for your driver is to execute sysctl compat.linuxkpi after you loaded the driver. For description of what these parameters do, call sysctl with the description flag.

  • % sysctl -d compat.linuxkpi.enable_fbc

    compat.linuxkpi.enable_fbc: Enable frame buffer compression for power savings (default: -1 (use per-chip default))

• Starting with FreeBSD 13 you can use the direct driver sysctls, the compat.linuxkpi will be removed at one point.

  • % sysctl -d hw.i915kms

• Periodically you will have a kernel panic but a core will not be recorded. You can test setting this sysctl knob which will prevent you from entering ddb on panic which has been found to unreliable in some circumstances:

  • debug.debugger_on_panic=0

• Also, adding this to your /boot/loader.conf can help in these scenarios:

  • dev.drm.skip_ddb="1"

• The following can be useful for providing context and can be set in /boot/loader.conf to ensure debug output remains enabled. The one problem with it is that debug output will slow things down enough to mask many problems.:

  • dev.drm.drm_debug_persist="1"

• Want to enable all DRM related debug flags at runtime? There is a knob for that:

  • dev.drm.drm_debug=-1

• kms drivers through linux-kpi report debugging information using debugfs. To mount it:

  • # mkdir /debug && mount -t debugfs none /debug

• To test how hardware acceleration is working you may want to run glxgears, but by default it may force syncing with your display (60fps for example). To disable this you can invoke glxgears like so:

  • $ env vblank_mode=0 glxgears

Test results

If everything works, let us know on the mailing list. Your information helps us confirm which hardware/software configurations work well.

Please include:

• dmesg command output

• pciconf -lvbce command output

• pkg info command output

• Contents of xorg.conf file (and included sub-files, if any)

• Contents of Xorg.log
• Any other details that may be relevant

If your laptop works well with FreeBSD, add it to the Laptops page.

Development

Developer information, including tasks in progress, is in the legacy GraphicsOld/Developer area.

Team

Contact

• freebsd-x11 mailing list

• FreeBSD Desktop Gitter and #freebsd-xorg Efnet IRC Channel – if taken to a server where #freebsd-xorg is unavailable, then try an alternative EFNet server

• GitHub: freebsd/drm-kmod, GitHub: FreeBSDDesktop

TODO

Tasks for contributors

Notes from meetings

https://github.com/freebsd/meetings#readme

Preferred policies on patches

In the past, the FreeBSD graphics stack got far behind the upstream sources. One of the main reasons for this was that as a project we'd been terrible about getting changes accepted upstream (or even trying to upstream them). These technical issues lead to much frustration and exacerbated many teamwork issues with the stack. For a time, things were somewhat dysfunctional. However, the graphics teams has caught up on all this technical debt by upstreaming changes; integrating Linux compatible APIs (like evdev); or by writing adapters to make FreeBSD-specific things like devd look like their Linux counterparts.

To avoid a repeat of this accumulation of technical debt, and all the issues that go with it, the graphics teams has a number of preferred practices it likes to follow. Generally we prefer using released versions of the elements of FreeBSD graphics stack. Issues come up between releases, and if the patches are accepted by upstream, then we'll include them. When there are issues that are being sorted out upstream, we prefer to let that run its course because they are usually the experts, though exceptions are made when reasonable. At the very least, we'd like any patches submitted upstream before they are included in a port to strongly encouraging upstreaming. Finally, when new features are implemented, there's a strong preference for using Linux and other APIs upstream sources are using over inventing something new for FreeBSD where possible.

We also desire to have FreeBSD be in the CI process for as many upstream sources as possible, though currently many do not yet have FreeBSD CI support. Helping upstreams get better CI integration will help us maintain the velocity of releases as FreeBSD is more likely to work and needs less regression testing on updates by us.

Legacy documentation

See GraphicsOld. If migration from the old page omitted anything critical, please notify the team.

CategoryProject CategoryTeam CategoryPorts