DRM(4)

πŸ“¦
version 11.0 Β· 2 versions
, in nixpkgs unstable

πŸ’– DRM(4) β€” drm from the Kernel Interfaces Manual πŸ’–

✨ NAME ✨

drm β€” Direct Rendering Manager β€” display configuration and graphics rendering acceleration


πŸ› οΈ SYNOPSIS πŸ› οΈ

🌟 Kernel mode-setting drivers

amdgpu*                at pci? dev ? function ?
i915drmkms*            at pci? dev ? function ?
nouveau*               at pci? dev ? function ?
radeon*                at pci? dev ? function ?
rkdrm*                 at fdt? pass 5
sunxidrm*              at fdt? pass 5
tegradrm*              at fdt? pass 5

πŸ•°οΈ Legacy user mode-setting options and drivers

options                DRM_LEGACY
viadrmums*             at drm?

πŸŽ›οΈ Options

options        DRM_MAX_RESOLUTION_HORIZONTAL=integer
options        DRM_MAX_RESOLUTION_VERTICAL=integer

🌸 DESCRIPTION 🌸

Okay bestie, so the Direct Rendering Manager is part of the Direct Rendering Infrastructure for supporting display configuration and hardware acceleration for graphics rendering and other computation on a graphics processing unit (GPU).

The drm drivers come in two generations:

πŸ‘‘ Kernel mode-setting (KMS)

Modern drivers that query and control display configuration in the kernel via ioctl(2) commands exposed to userland.

The /dev/dri/render* device nodes provide access to graphics buffers and command stream submission for rendering. The /dev/dri/card* device nodes additionally provide access to the display configuration.

KMS drivers provided as modules must generally be loaded by the bootloader, configured in boot.cfg(8), and cannot be loaded dynamically.

🫠 User mode-setting (UMS)

Legacy drivers that rely on userland support code that accesses device registers in the X(7) server to query and control display configuration. The kernel may be unable to recover if the display server crashes, or the device is suspended or resumed.

The kernel driver and /dev/dri/card* interfaces only manage buffers mapped in the GPU address space. Display configuration from userland requires the INSECURE option (see options(4)) to allow userland access to device registers.

The DRM_LEGACY option allows legacy UMS drivers to be loaded as modules (see module(7)).

The drm drivers provide support for the following graphics devices:

  • amdgpu β€” Newer AMD graphics devices.
  • i915drmkms β€” Intel integrated graphics devices from the i915 series onward. (Some i8xx support is included but not well-maintained. i7xx is not supported.)
  • nouveau β€” NVIDIA graphics devices.
  • radeon β€” Older AMD (including formerly ATI) Radeon graphics devices.
  • viadrmums (legacy UMS) β€” VIA graphics devices.

With some drivers (at least radeon(4)), in some cases the driver does not choose the resolution correctly. The options DRM_MAX_RESOLUTION_HORIZONTAL and DRM_MAX_RESOLUTION_VERTICAL allow limiting the maximum resolution in X and Y direction.

X(7) will attempt to create the device nodes automatically and use drm automatically. To create a device node manually:

mkdir -p /dev/dri
mknod /dev/dri/card0 c 180 0
chgrp wheel /dev/dri/card0
chmod 0660 /dev/dri/card0

Debugging output can be enabled and disabled by setting flag bits in the sysctl(8) node hw.drm2.__drm_debug. Various other knobs may be available under hw.drm2.


πŸŽ€ FILES πŸŽ€

  • /dev/dri/render* β€” Provides access to graphics buffers and command stream submission for rendering. Generally unprivileged.
  • /dev/dri/card* β€” In addition to everything provided by /dev/dri/render*, provides access to change the display configuration. Usually privileged.

πŸ¦‹ CODE REFERENCES πŸ¦‹

The drm subsystem and drivers mostly live under sys/external/bsd/drm2, with various Linux API shims in sys/external/bsd/common and some individual drm drivers scattered elsewhere in the tree.


🌈 SEE ALSO 🌈


πŸ’œ HISTORY πŸ’œ

drm was first available for Linux and later ported to FreeBSD and NetBSD. The port to NetBSD was redone after the introduction of KMS.

The first generation of drm drivers appeared in NetBSD 5.0. The second generation of drm with KMS appeared in NetBSD 7.0.


πŸ‘‘ AUTHORS πŸ‘‘

Too many to list.

Work on the NetBSD port was contributed by: Anonymous, Nia Alarie, Eric Anholt, Rafal Boni, Taylor R Campbell, Mihai Chelaru, David Brownlee, JaromΓ­r Doleek, Matthias Drochner, Christoph Egger, FUKAUMI Naoki, Paul Goyette, matthew green, Yorick Hardy, Nick Hudson, Martin Husemann, Arto Huusko, Thomas Klausner, Jonathan Kollasch, Tonnerre Lombard, Jared McNeill, Jeremy Morse, Kimihiro Nonaka, Tobias Nygren, Rin Okuyama, Maya Rashish, Erik Reid, Masanobu SAITOH, Blair Sadewitz, Chuck Silvers, Nathanial Sloss, JΓΆrg Sonnenberger, GrΓ©goire Sutre, Matt Thomas, Izumi Tsutsui, Patrick Welche, and Christos Zoulas.


πŸ’€ CAVEATS πŸ’€

drm is large and complicated and has no shortage of bugs. On systems where graphics is not important, you may wish to use userconf(4) to disable the special-purpose drm drivers for your graphics device and fall back to vga(4) or genfb(4) with the default display configuration provided by firmware.

drm is not β€˜Digital Rights Management’ and does not deprive you of agency over your own computer, except insofar as the code base is difficult to maintain.


okay bye bestie β€” this page is from Debian, dated October 21, 2023, and it’s the DRM(4) page. πŸ«ΆπŸ’…βœ¨

πŸ“¦ where this page comes from