DRM, graphics and X11 (X.Org)

Introduction

This page and linked articles present the status and directions of low-level components with which FreeBSD becomes a basis for desktop environments (DEs) such as KDE Plasma and Gnome.

This level includes:

This level does not include:


Other pages in this namespace:

Development

Developer information, including tasks in progress and similar, is available in the developer section.

TODO

Tasks available to contributers

Task

Developer

Status

Comment

Get Intel GPU Tools working

Initial port exists

Outdated initial port here

Team Members

who

area of responsibility/knowledge

zeising@

Everything ports related, team meetings, etc.

manu@

mesa, drm drivers

bapt@

ports, a bit of everything

imp@

core liason, contact him before committing maintainer timeouts

jkim@

ports, member emeritus

kwm@

ports, member emeritus

miwi@

ports, member emeritus

Contact

Hardware Support

The tables below are not an exhaustive list of supported hardware. Hardware is only listed if and when it has been explicitly tested/confirmed by developers and/or users. Graphics hardware missing from these tables may or may not work. If you have tested hardware that is not on the list, please report the results.

About GPU codenames vs. marketing names

The entries below are misleading because they use the marketing names as the "key". This table needs to be rewritten using GPU codenames as the key.

If your GPU is not supported

If your GPU is not supported by FreeBSD, you can fallback to VESA (if your computer uses a BIOS) or SCFB (if your computer uses UEFI). For the latter case, you can find instructions to setup SCFB in a dedicated article.

drm-kmod

graphics/drm-kmod indirectly provides a range of kernel modules for use with Intel Integrated Graphics and AMD graphics hardware.

Associated code is actively developed and allows us to track, more closely, drivers in the Linux kernel.

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:

In most cases:

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

AMD Graphics

Unlike the i915 Intel graphics driver, two modules exist for AMD hardware:

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

In most cases:

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:

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.

Radeon KMS (kernel mode setting)

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

Virtual Machines

VMware

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

Known issue:

VirtualBox

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

Reporting

Issues / Bugs

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

Debugging Tips

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:

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

Known Issues

Wayland

Wayland has its own page.

OpenCL

OpenCL has its own page.

Legacy Documentation

There is a copy of the previous iteration of this page available here. Hopefully no critical information was left out during this migration, but please notify the team if anything was missed!

Meeting Notes

Here's a handy link to the last couple of Graphics Team meetings:

July 12, 2021

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.


CategoryProject CategoryTeam CategoryPorts

Graphics (last edited 2021-10-17T14:00:59+0000 by GrahamPerrin)