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:

This level does not include:

Hardware Support

If your use case is not covered by DRM or nvidia-driver, non-DRM – 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:

DRM

The Direct Rendering Manager is a subsystem of the Linux kernel responsible for interfacing with GPUs of modern video cards.

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

nvidia-drm-kmod indirectly provides a kernel module for use with:

AMD graphics

Refer to the handbook to get information about how to configure an AMD Graphics card.

Intel Integrated Graphics (aka HD Graphics)

Refer to the handbook to get information about how to configure an Intel Graphics card.

NVIDIA Proprietary Graphics Driver

Refer to the handbook to get information about how to configure an NVIDIA Graphics card with the proprietary driver.

NVIDIA Open Source Graphics Driver

nvidia-drm.ko complements the x11/nvidia-driver port.

FreeBSD Display Driver – x64, 535.104.05, FreeBSD x64, NVIDIA includes:

nvidia-drm-510-kmod

Install graphics/nvidia-drm-kmod. If a package is not yet available, be patient:

Configure your /etc/rc.conf:

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

Restart your system, or run:

nvidia-drm-515-kmod

Install graphics/nvidia-drm-515-kmod, then follow the configuration and other hints above.

General

Other NVIDIA-related areas include:

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.

Side notes

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

GPU codenames vs. marketing names:

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.

Xorg -configure crashes with a segmentation fault.

Problems with drm-kmod on i386.

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.

Development

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

Team

who

area of responsibility/knowledge

NiclasZeising

Everything ports related, team meetings, etc.

EmmanuelVadot

mesa, drm drivers

BaptisteDaroussin

ports, a bit of everything

WarnerLosh

core liason, contact him before committing maintainer timeouts

JungukKim

ports, member emeritus

KoopMast

ports, member emeritus

MartinWilke

ports, member emeritus

Contact

TODO

Tasks for contributors

Task

Developer

Status

Comment

Get Intel GPU Tools working

Initial port exists

Outdated initial port here

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

Graphics (last edited 2023-10-20T01:20:04+0000 by MarkLinimon)