Requirements for KMS UAPI¶

• KMS connectors must change their status to disconnected.

• Legacy modesets and pageflips, and atomic commits, both real and TEST_ONLY, and any other ioctls either fail with ENODEV or fake success.

• Pending non-blocking KMS operations deliver the DRM events userspace is expecting. This applies also to ioctls that faked success.

• open() on a device node whose underlying device has disappeared will fail with ENXIO.

• Attempting to create a DRM lease on a disappeared DRM device will fail with ENODEV. Existing DRM leases remain and work as listed above.

Requirements for Render and Cross-Device UAPI¶

• All GPU jobs that can no longer run must have their fences force-signalled to avoid inflicting hangs on userspace. The associated error code is ENODEV.

• Some userspace APIs already define what should happen when the device disappears (OpenGL, GL ES: GL_KHR_robustness; Vulkan: VK_ERROR_DEVICE_LOST; etc.). DRM drivers are free to implement this behaviour the way they see best, e.g. returning failures in driver-specific ioctls and handling those in userspace drivers, or rely on uevents, and so on.

• dmabuf which point to memory that has disappeared will either fail to import with ENODEV or continue to be successfully imported if it would have succeeded before the disappearance. See also about memory maps below for already imported dmabufs.

• Attempting to import a dmabuf to a disappeared device will either fail with ENODEV or succeed if it would have succeeded without the disappearance.

• open() on a device node whose underlying device has disappeared will fail with ENXIO.

Requirements for Memory Maps¶

Memory maps have further requirements that apply to both existing maps and maps created after the device has disappeared. If the underlying memory disappears, the map is created or modified such that reads and writes will still complete successfully but the result is undefined. This applies to both userspace mmap()’d memory and memory pointed to by dmabuf which might be mapped to other devices (cross-device dmabuf imports).

Raising SIGBUS is not an option, because userspace cannot realistically handle it. Signal handlers are global, which makes them extremely difficult to use correctly from libraries like those that Mesa produces. Signal handlers are not composable, you can’t have different handlers for GPU1 and GPU2 from different vendors, and a third handler for mmapped regular files. Threads cause additional pain with signal handling as well.

Kernel Mode Driver¶

The KMD is responsible for checking if the device needs a reset, and to perform it as needed. Usually a hang is detected when a job gets stuck executing.

Propagation of errors to userspace has proven to be tricky since it goes in the opposite direction of the usual flow of commands. Because of this vendor independent error handling was added to the &dma_fence object, this way drivers can add an error code to their fences before signaling them. See function dma_fence_set_error() on how to do this and for examples of error codes to use.

The DRM scheduler also allows setting error codes on all pending fences when hardware submissions are restarted after an reset. Error codes are also forwarded from the hardware fence to the scheduler fence to bubble up errors to the higher levels of the stack and eventually userspace.

Fence errors can be queried by userspace through the generic SYNC_IOC_FILE_INFO IOCTL as well as through driver specific interfaces.

Additional to setting fence errors drivers should also keep track of resets per context, the DRM scheduler provides the drm_sched_entity_error() function as helper for this use case. After a reset, KMD should reject new command submissions for affected contexts.

User Mode Driver¶

After command submission, UMD should check if the submission was accepted or rejected. After a reset, KMD should reject submissions, and UMD can issue an ioctl to the KMD to check the reset status, and this can be checked more often if the UMD requires it. After detecting a reset, UMD will then proceed to report it to the application using the appropriate API error code, as explained in the section below about robustness.

Robustness¶

The only way to try to keep a graphical API context working after a reset is if it complies with the robustness aspects of the graphical API that it is using.

Graphical APIs provide ways to applications to deal with device resets. However, there is no guarantee that the app will use such features correctly, and a userspace that doesn’t support robust interfaces (like a non-robust OpenGL context or API without any robustness support like libva) leave the robustness handling entirely to the userspace driver. There is no strong community consensus on what the userspace driver should do in that case, since all reasonable approaches have some clear downsides.

Reporting causes of resets¶

Apart from propagating the reset through the stack so apps can recover, it’s really useful for driver developers to learn more about what caused the reset in the first place. For this, drivers can make use of devcoredump to store relevant information about the reset and send device wedged event with none recovery method (as explained in “Device Wedging” chapter) to notify userspace, so this information can be collected and added to user bug reports.

Driver prerequisites¶

The driver, before opting for recovery, needs to make sure that the ‘wedged’ device doesn’t harm the system as a whole by taking care of the prerequisites. Necessary actions must include disabling DMA to system memory as well as any communication channels with other devices. Further, the driver must ensure that all dma_fences are signalled and any device state that the core kernel might depend on is cleaned up. All existing mmaps should be invalidated and page faults should be redirected to a dummy page. Once the event is sent, the device must be kept in ‘wedged’ state until the recovery is performed. New accesses to the device (IOCTLs) should be rejected, preferably with an error code that resembles the type of failure the device has encountered. This will signify the reason for wedging, which can be reported to the application if needed.

Recovery¶

Current implementation defines several recovery methods, out of which, drivers can use any one, multiple or none. Method(s) of choice will be sent in the uevent environment as WEDGED=<method1>[,..,<methodN>] in order of less to more side-effects. See the section Vendor Specific Recovery for WEDGED=vendor-specific. If driver is unsure about recovery or method is unknown, WEDGED=unknown will be sent instead.

Userspace consumers can parse this event and attempt recovery as per the following expectations.

Recovery method	Consumer expectations
none	optional telemetry collection
rebind	unbind + bind driver
bus-reset	unbind + bus reset/re-enumeration + bind
vendor-specific	vendor specific recovery method
cold-reset	remove device + slot power cycle + rescan
unknown	consumer policy

No Recovery¶

Here WEDGED=none signifies that no recovery is expected from the consumer but it can still try to gather telemetry information (devcoredump, syslog) for debug purpose in order to root cause the hang. This is useful because the first hang is usually the most critical one which can result in consequential hangs or complete wedging.

Cold Reset Recovery¶

When WEDGED=cold-reset is sent, it indicates that the device has encountered an error condition that cannot be resolved through other recovery methods such as driver rebind or bus reset, and requires a complete device power cycle to restore functionality.

This method is used by devices that are plugged directly into the PCIe slot which supports removing the power.

Vendor Specific Recovery¶

When WEDGED=vendor-specific is sent, it indicates that the device requires a recovery procedure specific to the hardware vendor and is not one of the standardized approaches.

WEDGED=vendor-specific may be used to indicate different cases within a single vendor driver, each requiring a distinct recovery procedure. In such scenarios, the vendor driver must provide comprehensive documentation that describes each case, include additional hints to identify specific case and outline the corresponding recovery procedure. The documentation includes:

Case - A list of all cases that sends the WEDGED=vendor-specific recovery method.

Hints - Additional Information to assist the userspace consumer in identifying and differentiating between different cases. This can be exposed through sysfs, debugfs, traces, dmesg etc.

Recovery Procedure - Clear instructions and guidance for recovering each case. This may include userspace scripts, tools needed for the recovery procedure.

It is the responsibility of the admin/userspace consumer to identify the case and verify additional identification hints before attempting a recovery procedure.

Example: If the device uses the Xe driver, then userspace consumer should refer to Xe Device Wedging for the detailed documentation.

Task information¶

The information about which application (if any) was involved in the device wedging is useful for userspace if they want to notify the user about what happened (e.g. the compositor display a message to the user “The <task name> caused a graphical error and the system recovered”) or to implement policies (e.g. the daemon may “ban” an task that keeps resetting the device). If the task information is available, the uevent will display as PID=<pid> and TASK=<task name>. Otherwise, PID and TASK will not appear in the event string.

The reliability of this information is driver and hardware specific, and should be taken with a caution regarding it’s precision. To have a big picture of what really happened, the devcoredump file provides much more detailed information about the device state and about the event.

Consumer prerequisites¶

It is the responsibility of the consumer to make sure that the device or its resources are not in use by any process before attempting recovery. With IOCTLs erroring out, all device memory should be unmapped and file descriptors should be closed to prevent leaks or undefined behaviour. The idea here is to clear the device of all user context beforehand and set the stage for a clean recovery.

For WEDGED=vendor-specific recovery method, it is the responsibility of the consumer to check the driver documentation and the usecase before attempting a recovery.

Example - rebind¶

Udev rule:

SUBSYSTEM=="drm", ENV{WEDGED}=="rebind", DEVPATH=="*/drm/card[0-9]", \
RUN+="/path/to/rebind.sh $env{DEVPATH}"

Recovery script:

#!/bin/sh

DEVPATH=$(readlink -f /sys/$1/device)
DEVICE=$(basename $DEVPATH)
DRIVER=$(readlink -f $DEVPATH/driver)

echo -n $DEVICE > $DRIVER/unbind
echo -n $DEVICE > $DRIVER/bind

Example - cold-reset¶

Udev rule:

SUBSYSTEM=="drm", ENV{WEDGED}=="cold-reset", DEVPATH=="*/drm/card[0-9]", \
RUN+="/path/to/cold-reset.sh $env{DEVPATH}"

Recovery script:

#!/bin/sh
die() { echo "ERROR: $*" >&2; exit 1; }

[ -n "$1" ] || die "Usage: $0 <device-path>"

PCI_DEVS=/sys/bus/pci/devices
PCI_SLOTS=/sys/bus/pci/slots

syspath=$(readlink -f "/sys/$1/device" 2>/dev/null || readlink -f "/sys/$1" 2>/dev/null)
[ -n "$syspath" ] || die "cannot resolve sysfs path for: $1"

dev=$(basename "$syspath")
[ -e "$PCI_DEVS/$dev" ] || die "not a PCI device: $dev"
echo "device : $dev"

slot=""
walk=$(dirname "$(readlink -f "$PCI_DEVS/$dev")")

while true; do
    ancestor=$(basename "$walk")
    case "$ancestor" in pci*) break ;; esac  # reached the virtual bus root

    ancestor_nofn=${ancestor%.*}  # strip function: 0000:03:01.0 -> 0000:03:01

    for f in "$PCI_SLOTS"/*/address; do
        [ -f "$f" ] || continue
        addr=$(cat "$f")
        case "$ancestor_nofn" in
            *"$addr") slot=$(basename "$(dirname "$f")"); break ;;
        esac
    done

    if [ -n "$slot" ] && [ -e "$PCI_SLOTS/$slot/power" ]; then
        echo "slot   : $slot (port $ancestor)"
        break
    fi
    slot=""
    walk=$(dirname "$walk")
done

[ -n "$slot" ] || die "no hotplug slot with power control found in PCIe topology"

# Cold reset: remove the device, cut slot power, restore power, rescan.
echo "Removing $dev..."
[ -e "$PCI_DEVS/$dev" ] && echo 1 > "$PCI_DEVS/$dev/remove"

echo "Powering off slot $slot..."
echo 0 > "$PCI_SLOTS/$slot/power"

echo "Powering on slot $slot..."
echo 1 > "$PCI_SLOTS/$slot/power"

echo "Rescanning PCI bus..."
echo 1 > /sys/bus/pci/rescan

if [ -e "$PCI_DEVS/$dev" ]; then
    echo "Done: $dev is back online."
else
    echo "WARNING: $dev did not re-appear after rescan."
fi

Customization¶

Although basic recovery is possible with a simple script, consumers can define custom policies around recovery. For example, if the driver supports multiple recovery methods, consumers can opt for the suitable one depending on scenarios like repeat offences or vendor specific failures. Consumers can also choose to have the device available for debugging or telemetry collection and base their recovery decision on the findings. This is useful especially when the driver is unsure about recovery or method is unknown.

Recommended IOCTL Return Values¶

In theory a driver’s IOCTL callback is only allowed to return very few error codes. In practice it’s good to abuse a few more. This section documents common practice within the DRM subsystem:

ENOENT:

Strictly this should only be used when a file doesn’t exist e.g. when calling the open() syscall. We reuse that to signal any kind of object lookup failure, e.g. for unknown GEM buffer object handles, unknown KMS object handles and similar cases.

ENOSPC:

Some drivers use this to differentiate “out of kernel memory” from “out of VRAM”. Sometimes also applies to other limited gpu resources used for rendering (e.g. when you have a special limited compression buffer). Sometimes resource allocation/reservation issues in command submission IOCTLs are also signalled through EDEADLK.

Simply running out of kernel/system memory is signalled through ENOMEM.

EPERM/EACCES:

Returned for an operation that is valid, but needs more privileges. E.g. root-only or much more common, DRM master-only operations return this when called by unprivileged clients. There’s no clear difference between EACCES and EPERM.

ENODEV:

The device is not present anymore or is not yet fully initialized.

EOPNOTSUPP:

Feature (like PRIME, modesetting, GEM) is not supported by the driver.

ENXIO:

Remote failure, either a hardware transaction (like i2c), but also used when the exporting driver of a shared dma-buf or fence doesn’t support a feature needed.

EINTR:

DRM drivers assume that userspace restarts all IOCTLs. Any DRM IOCTL can return EINTR and in such a case should be restarted with the IOCTL parameters left unchanged.

EIO:

The GPU died and couldn’t be resurrected through a reset. Modesetting hardware failures are signalled through the “link status” connector property.

EINVAL:

Catch-all for anything that is an invalid argument combination which cannot work.

IOCTL also use other error codes like ETIME, EFAULT, EBUSY, ENOTTY but their usage is in line with the common meanings. The above list tries to just document DRM specific patterns. Note that ENOTTY has the slightly unintuitive meaning of “this IOCTL does not exist”, and is used exactly as such in DRM.

drm_ioctl_t¶

Typedef: DRM ioctl function type.

Syntax

typedef int drm_ioctl_t (struct drm_device *dev, void *data, struct drm_file *file_priv)

drm_ioctl_compat_t¶

Typedef: compatibility DRM ioctl function type.

Syntax

typedef int drm_ioctl_compat_t (struct file *filp, unsigned int cmd, unsigned long arg)

enum drm_ioctl_flags¶

DRM ioctl flags

Description

Various flags that can be set in drm_ioctl_desc.flags to control how userspace can use a given ioctl.

struct drm_ioctl_desc¶

DRM driver ioctl entry

struct drm_ioctl_desc {
    unsigned int cmd;
    enum drm_ioctl_flags flags;
    drm_ioctl_t *func;
    const char *name;
};

Description

For convenience it’s easier to create these using the DRM_IOCTL_DEF_DRV() macro.

DRM_IOCTL_DEF_DRV¶

DRM_IOCTL_DEF_DRV (ioctl, _func, _flags)

helper macro to fill out a struct drm_ioctl_desc

int drm_noop(struct drm_device *dev, void *data, struct drm_file *file_priv)¶

DRM no-op ioctl implementation

int drm_invalid_op(struct drm_device *dev, void *data, struct drm_file *file_priv)¶

DRM invalid ioctl implementation

long drm_ioctl(struct file *filp, unsigned int cmd, unsigned long arg)¶

ioctl callback implementation for DRM drivers

bool drm_ioctl_flags(unsigned int nr, unsigned int *flags)

Check for core ioctl and return ioctl permission flags

long drm_compat_ioctl(struct file *filp, unsigned int cmd, unsigned long arg)¶

32bit IOCTL compatibility handler for DRM drivers

Testing Requirements for userspace API¶

New cross-driver userspace interface extensions, like new IOCTL, new KMS properties, new files in sysfs or anything else that constitutes an API change should have driver-agnostic testcases in IGT for that feature, if such a test can be reasonably made using IGT for the target hardware.

Validating changes with IGT¶

There’s a collection of tests that aims to cover the whole functionality of DRM drivers and that can be used to check that changes to DRM drivers or the core don’t regress existing functionality. This test suite is called IGT and its code and instructions to build and run can be found in https://gitlab.freedesktop.org/drm/igt-gpu-tools/.

Using VKMS to test DRM API¶

VKMS is a software-only model of a KMS driver that is useful for testing and for running compositors. VKMS aims to enable a virtual display without the need for a hardware display capability. These characteristics made VKMS a perfect tool for validating the DRM core behavior and also support the compositor developer. VKMS makes it possible to test DRM functions in a virtual machine without display, simplifying the validation of some of the core changes.

To Validate changes in DRM API with VKMS, start setting the kernel: make sure to enable VKMS module; compile the kernel with the VKMS enabled and install it in the target machine. VKMS can be run in a Virtual Machine (QEMU, virtme or similar). It’s recommended the use of KVM with the minimum of 1GB of RAM and four cores.

It’s possible to run the IGT-tests in a VM in two ways:

1. Use IGT inside a VM

2. Use IGT from the host machine and write the results in a shared directory.

Following is an example of using a VM with a shared directory with the host machine to run igt-tests. This example uses virtme:

$ virtme-run --rwdir /path/for/shared_dir --kdir=path/for/kernel/directory --mods=auto

Run the igt-tests in the guest machine. This example runs the ‘kms_flip’ tests:

$ /path/for/igt-gpu-tools/scripts/run-tests.sh -p -s -t "kms_flip.*" -v

In this example, instead of building the igt_runner, Piglit is used (-p option). It creates an HTML summary of the test results and saves them in the folder “igt-gpu-tools/results”. It executes only the igt-tests matching the -t option.

Display CRC Support¶

DRM device drivers can provide to userspace CRC information of each frame as it reached a given hardware component (a CRC sampling “source”).

Userspace can control generation of CRCs in a given CRTC by writing to the file dri/0/crtc-N/crc/control in debugfs, with N being the index of the CRTC. Accepted values are source names (which are driver-specific) and the “auto” keyword, which will let the driver select a default source of frame CRCs for this CRTC.

Once frame CRC generation is enabled, userspace can capture them by reading the dri/0/crtc-N/crc/data file. Each line in that file contains the frame number in the first field and then a number of unsigned integer fields containing the CRC data. Fields are separated by a single space and the number of CRC fields is source-specific.

Note that though in some cases the CRC is computed in a specified way and on the frame contents as supplied by userspace (eDP 1.3), in general the CRC computation is performed in an unspecified way and on frame contents that have been already processed in also an unspecified way and thus userspace cannot rely on being able to generate matching CRC values for the frame contents that it submits. In this general case, the maximum userspace can do is to compare the reported CRCs of frames that should have the same contents.

On the driver side the implementation effort is minimal, drivers only need to implement drm_crtc_funcs.set_crc_source and drm_crtc_funcs.verify_crc_source. The debugfs files are automatically set up if those vfuncs are set. CRC samples need to be captured in the driver by calling drm_crtc_add_crc_entry(). Depending on the driver and HW requirements, drm_crtc_funcs.set_crc_source may result in a commit (even a full modeset).

CRC results must be reliable across non-full-modeset atomic commits, so if a commit via DRM_IOCTL_MODE_ATOMIC would disable or otherwise interfere with CRC generation, then the driver must mark that commit as a full modeset (drm_atomic_crtc_needs_modeset() should return true). As a result, to ensure consistent results, generic userspace must re-setup CRC generation after a legacy SETCRTC or an atomic commit with DRM_MODE_ATOMIC_ALLOW_MODESET.

int drm_crtc_add_crc_entry(struct drm_crtc *crtc, bool has_frame, uint32_t frame, uint32_t *crcs)¶

Add entry with CRC information for a frame

Debugfs Support¶

DRM_DEBUGFS_GPUVA_INFO¶

DRM_DEBUGFS_GPUVA_INFO (show, data)

drm_info_list entry to dump a GPU VA space

struct drm_info_list¶

debugfs info list entry

struct drm_info_list {
    const char *name;
    int (*show)(struct seq_file*, void*);
    u32 driver_features;
    void *data;
};

Description

This structure represents a debugfs file to be created by the drm core.

struct drm_info_node¶

Per-minor debugfs node structure

struct drm_info_node {
    struct drm_minor *minor;
    const struct drm_info_list *info_ent;
};

Description

This structure represents a debugfs file, as an instantiation of a struct drm_info_list on a struct drm_minor.

FIXME:

No it doesn’t make a hole lot of sense that we duplicate debugfs entries for both the render and the primary nodes, but that’s how this has organically grown. It should probably be fixed, with a compatibility link, if needed.

struct drm_debugfs_info¶

debugfs info list entry

struct drm_debugfs_info {
    const char *name;
    int (*show)(struct seq_file*, void*);
    u32 driver_features;
    void *data;
};

Description

This structure represents a debugfs file to be created by the drm core.

struct drm_debugfs_entry¶

Per-device debugfs node structure

struct drm_debugfs_entry {
    struct drm_device *dev;
    struct drm_debugfs_info file;
    struct list_head list;
};

Description

This structure represents a debugfs file, as an instantiation of a struct drm_debugfs_info on a struct drm_device.

int drm_debugfs_gpuva_info(struct seq_file *m, struct drm_gpuvm *gpuvm)¶

dump the given DRM GPU VA space

void drm_debugfs_create_files(const struct drm_info_list *files, int count, struct dentry *root, struct drm_minor *minor)¶

Initialize a given set of debugfs files for DRM minor

void drm_debugfs_add_file(struct drm_device *dev, const char *name, int (*show)(struct seq_file*, void*), void *data)¶

Add a given file to the DRM device debugfs file list

void drm_debugfs_add_files(struct drm_device *dev, const struct drm_debugfs_info *files, int count)¶

Add an array of files to the DRM device debugfs file list

CRTC index¶

CRTC’s have both an object ID and an index, and they are not the same thing. The index is used in cases where a densely packed identifier for a CRTC is needed, for instance a bitmask of CRTC’s. The member possible_crtcs of struct drm_mode_get_plane is an example.

DRM_IOCTL_MODE_GETRESOURCES populates a structure with an array of CRTC ID’s, and the CRTC index is its position in this array.

struct drm_gem_close¶

Argument for DRM_IOCTL_GEM_CLOSE ioctl.

struct drm_gem_close {
    __u32 handle;
    __u32 pad;
};

Description

Releases the handle to an mm object.

struct drm_gem_flink¶

Argument for DRM_IOCTL_GEM_FLINK ioctl.

struct drm_gem_flink {
    __u32 handle;
    __u32 name;
};

Description

Create a global name for an object, returning the name.

Note that the name does not hold a reference; when the object is freed, the name goes away.

struct drm_gem_open¶

Argument for DRM_IOCTL_GEM_OPEN ioctl.

struct drm_gem_open {
    __u32 name;
    __u32 handle;
    __u64 size;
};

Description

Open an object using the global name, returning a handle and the size.

This handle (of course) holds a reference to the object, so the object will not go away until the handle is deleted.

struct drm_gem_change_handle¶

Argument for DRM_IOCTL_GEM_CHANGE_HANDLE ioctl.

struct drm_gem_change_handle {
    __u32 handle;
    __u32 new_handle;
};

Description

This ioctl changes the handle of a GEM object to the specified one. The new handle must be unused. On success the old handle is closed and all further IOCTL should refer to the new handle only. Calls to DRM_IOCTL_PRIME_FD_TO_HANDLE will return the new handle.

DRM_CAP_DUMB_BUFFER¶

DRM_CAP_DUMB_BUFFER

Description

If set to 1, the driver supports creating dumb buffers via the DRM_IOCTL_MODE_CREATE_DUMB ioctl.

DRM_CAP_VBLANK_HIGH_CRTC¶

DRM_CAP_VBLANK_HIGH_CRTC

Description

If set to 1, the kernel supports specifying a CRTC index in the high bits of drm_wait_vblank_request.type.

Starting kernel version 2.6.39, this capability is always set to 1.

DRM_CAP_DUMB_PREFERRED_DEPTH¶

DRM_CAP_DUMB_PREFERRED_DEPTH

Description

The preferred bit depth for dumb buffers.

The bit depth is the number of bits used to indicate the color of a single pixel excluding any padding. This is different from the number of bits per pixel. For instance, XRGB8888 has a bit depth of 24 but has 32 bits per pixel.

Note that this preference only applies to dumb buffers, it’s irrelevant for other types of buffers.

DRM_CAP_DUMB_PREFER_SHADOW¶

DRM_CAP_DUMB_PREFER_SHADOW

Description

If set to 1, the driver prefers userspace to render to a shadow buffer instead of directly rendering to a dumb buffer. For best speed, userspace should do streaming ordered memory copies into the dumb buffer and never read from it.

Note that this preference only applies to dumb buffers, it’s irrelevant for other types of buffers.

DRM_CAP_PRIME¶

DRM_CAP_PRIME

Description

Bitfield of supported PRIME sharing capabilities. See DRM_PRIME_CAP_IMPORT and DRM_PRIME_CAP_EXPORT.

Starting from kernel version 6.6, both DRM_PRIME_CAP_IMPORT and DRM_PRIME_CAP_EXPORT are always advertised.

PRIME buffers are exposed as dma-buf file descriptors. See PRIME Buffer Sharing.

DRM_PRIME_CAP_IMPORT¶

DRM_PRIME_CAP_IMPORT

Description

If this bit is set in DRM_CAP_PRIME, the driver supports importing PRIME buffers via the DRM_IOCTL_PRIME_FD_TO_HANDLE ioctl.

Starting from kernel version 6.6, this bit is always set in DRM_CAP_PRIME.

DRM_PRIME_CAP_EXPORT¶

DRM_PRIME_CAP_EXPORT

Description

If this bit is set in DRM_CAP_PRIME, the driver supports exporting PRIME buffers via the DRM_IOCTL_PRIME_HANDLE_TO_FD ioctl.

Starting from kernel version 6.6, this bit is always set in DRM_CAP_PRIME.

DRM_CAP_TIMESTAMP_MONOTONIC¶

DRM_CAP_TIMESTAMP_MONOTONIC

Description

If set to 0, the kernel will report timestamps with CLOCK_REALTIME in struct drm_event_vblank. If set to 1, the kernel will report timestamps with CLOCK_MONOTONIC. See clock_gettime(2) for the definition of these clocks.

Starting from kernel version 2.6.39, the default value for this capability is 1. Starting kernel version 4.15, this capability is always set to 1.

DRM_CAP_ASYNC_PAGE_FLIP¶

DRM_CAP_ASYNC_PAGE_FLIP

Description

If set to 1, the driver supports DRM_MODE_PAGE_FLIP_ASYNC for legacy page-flips.

DRM_CAP_CURSOR_WIDTH¶

DRM_CAP_CURSOR_WIDTH

Description

The CURSOR_WIDTH and CURSOR_HEIGHT capabilities return a valid width x height combination for the hardware cursor. The intention is that a hardware agnostic userspace can query a cursor plane size to use.

Note that the cross-driver contract is to merely return a valid size; drivers are free to attach another meaning on top, eg. i915 returns the maximum plane size.

DRM_CAP_CURSOR_HEIGHT¶

DRM_CAP_CURSOR_HEIGHT

Description

See DRM_CAP_CURSOR_WIDTH.

DRM_CAP_ADDFB2_MODIFIERS¶

DRM_CAP_ADDFB2_MODIFIERS

Description

If set to 1, the driver supports supplying modifiers in the DRM_IOCTL_MODE_ADDFB2 ioctl.

DRM_CAP_PAGE_FLIP_TARGET¶

DRM_CAP_PAGE_FLIP_TARGET

Description

If set to 1, the driver supports the DRM_MODE_PAGE_FLIP_TARGET_ABSOLUTE and DRM_MODE_PAGE_FLIP_TARGET_RELATIVE flags in drm_mode_crtc_page_flip_target.flags for the DRM_IOCTL_MODE_PAGE_FLIP ioctl.

DRM_CAP_CRTC_IN_VBLANK_EVENT¶

DRM_CAP_CRTC_IN_VBLANK_EVENT

Description

If set to 1, the kernel supports reporting the CRTC ID in drm_event_vblank.crtc_id for the DRM_EVENT_VBLANK and DRM_EVENT_FLIP_COMPLETE events.

Starting kernel version 4.12, this capability is always set to 1.

DRM_CAP_SYNCOBJ¶

DRM_CAP_SYNCOBJ

Description

If set to 1, the driver supports sync objects. See DRM Sync Objects.

DRM_CAP_SYNCOBJ_TIMELINE¶

DRM_CAP_SYNCOBJ_TIMELINE

Description

If set to 1, the driver supports timeline operations on sync objects. See DRM Sync Objects.

DRM_CAP_ATOMIC_ASYNC_PAGE_FLIP¶

DRM_CAP_ATOMIC_ASYNC_PAGE_FLIP

Description

If set to 1, the driver supports DRM_MODE_PAGE_FLIP_ASYNC for atomic commits.

DRM_CLIENT_CAP_STEREO_3D¶

DRM_CLIENT_CAP_STEREO_3D

Description

If set to 1, the DRM core will expose the stereo 3D capabilities of the monitor by advertising the supported 3D layouts in the flags of struct drm_mode_modeinfo. See DRM_MODE_FLAG_3D_*.

This capability is always supported for all drivers starting from kernel version 3.13.

DRM_CLIENT_CAP_UNIVERSAL_PLANES¶

DRM_CLIENT_CAP_UNIVERSAL_PLANES

Description

If set to 1, the DRM core will expose all planes (overlay, primary, and cursor) to userspace.

This capability has been introduced in kernel version 3.15. Starting from kernel version 3.17, this capability is always supported for all drivers.

DRM_CLIENT_CAP_ATOMIC¶

DRM_CLIENT_CAP_ATOMIC

Description

If set to 1, the DRM core will expose atomic properties to userspace. This implicitly enables DRM_CLIENT_CAP_UNIVERSAL_PLANES and DRM_CLIENT_CAP_ASPECT_RATIO.

If the driver doesn’t support atomic mode-setting, enabling this capability will fail with -EOPNOTSUPP.

This capability has been introduced in kernel version 4.0. Starting from kernel version 4.2, this capability is always supported for atomic-capable drivers.

DRM_CLIENT_CAP_ASPECT_RATIO¶

DRM_CLIENT_CAP_ASPECT_RATIO

Description

If set to 1, the DRM core will provide aspect ratio information in modes. See DRM_MODE_FLAG_PIC_AR_*.

This capability is always supported for all drivers starting from kernel version 4.18.

DRM_CLIENT_CAP_WRITEBACK_CONNECTORS¶

DRM_CLIENT_CAP_WRITEBACK_CONNECTORS

Description

If set to 1, the DRM core will expose special connectors to be used for writing back to memory the scene setup in the commit. The client must enable DRM_CLIENT_CAP_ATOMIC first.

This capability is always supported for atomic-capable drivers starting from kernel version 4.19.

DRM_CLIENT_CAP_CURSOR_PLANE_HOTSPOT¶

DRM_CLIENT_CAP_CURSOR_PLANE_HOTSPOT

Description

Drivers for para-virtualized hardware (e.g. vmwgfx, qxl, virtio and virtualbox) have additional restrictions for cursor planes (thus making cursor planes on those drivers not truly universal,) e.g. they need cursor planes to act like one would expect from a mouse cursor and have correctly set hotspot properties. If this client cap is not set the DRM core will hide cursor plane on those virtualized drivers because not setting it implies that the client is not capable of dealing with those extra restictions. Clients which do set cursor hotspot and treat the cursor plane like a mouse cursor should set this property. The client must enable DRM_CLIENT_CAP_ATOMIC first.

Setting this property on drivers which do not special case cursor planes (i.e. non-virtualized drivers) will return EOPNOTSUPP, which can be used by userspace to gauge requirements of the hardware/drivers they’re running on.

This capability is always supported for atomic-capable virtualized drivers starting from kernel version 6.6.

DRM_CLIENT_CAP_PLANE_COLOR_PIPELINE¶

DRM_CLIENT_CAP_PLANE_COLOR_PIPELINE

Description

If set to 1 the DRM core will allow setting the COLOR_PIPELINE property on a drm_plane, as well as drm_colorop properties.

Setting of these plane properties will be rejected when this client cap is set: - COLOR_ENCODING - COLOR_RANGE

The client must enable DRM_CLIENT_CAP_ATOMIC first.

struct drm_syncobj_eventfd¶

struct drm_syncobj_eventfd {
    __u32 handle;
    __u32 flags;
    __u64 point;
    __s32 fd;
    __u32 pad;
};

Description

Register an eventfd to be signalled by a syncobj. The eventfd counter will be incremented by one.

DRM_IOCTL_GEM_CLOSE¶

DRM_IOCTL_GEM_CLOSE

Close a GEM handle.

Description

GEM handles are not reference-counted by the kernel. User-space is responsible for managing their lifetime. For example, if user-space imports the same memory object twice on the same DRM file description, the same GEM handle is returned by both imports, and user-space needs to ensure DRM_IOCTL_GEM_CLOSE is performed once only. The same situation can happen when a memory object is allocated, then exported and imported again on the same DRM file description. The DRM_IOCTL_MODE_GETFB2 IOCTL is an exception and always returns fresh new GEM handles even if an existing GEM handle already refers to the same memory object before the IOCTL is performed.

DRM_IOCTL_PRIME_HANDLE_TO_FD¶

DRM_IOCTL_PRIME_HANDLE_TO_FD

Convert a GEM handle to a DMA-BUF FD.

Description

User-space sets drm_prime_handle.handle with the GEM handle to export and drm_prime_handle.flags, and gets back a DMA-BUF file descriptor in drm_prime_handle.fd.

The export can fail for any driver-specific reason, e.g. because export is not supported for this specific GEM handle (but might be for others).

Support for exporting DMA-BUFs is advertised via DRM_PRIME_CAP_EXPORT.

DRM_IOCTL_PRIME_FD_TO_HANDLE¶

DRM_IOCTL_PRIME_FD_TO_HANDLE

Convert a DMA-BUF FD to a GEM handle.

Description

User-space sets drm_prime_handle.fd with a DMA-BUF file descriptor to import, and gets back a GEM handle in drm_prime_handle.handle. drm_prime_handle.flags is unused.

If an existing GEM handle refers to the memory object backing the DMA-BUF, that GEM handle is returned. Therefore user-space which needs to handle arbitrary DMA-BUFs must have a user-space lookup data structure to manually reference-count duplicated GEM handles. For more information see DRM_IOCTL_GEM_CLOSE.

The import can fail for any driver-specific reason, e.g. because import is only supported for DMA-BUFs allocated on this DRM device.

Support for importing DMA-BUFs is advertised via DRM_PRIME_CAP_IMPORT.

DRM_IOCTL_MODE_RMFB¶

DRM_IOCTL_MODE_RMFB

Remove a framebuffer.

Description

This removes a framebuffer previously added via ADDFB/ADDFB2. The IOCTL argument is a framebuffer object ID.

Warning: removing a framebuffer currently in-use on an enabled plane will disable that plane. The CRTC the plane is linked to may also be disabled (depending on driver capabilities).

DRM_IOCTL_MODE_CREATE_DUMB¶

DRM_IOCTL_MODE_CREATE_DUMB

Create a new dumb buffer object.

Description

KMS dumb buffers provide a very primitive way to allocate a buffer object suitable for scanout and map it for software rendering. KMS dumb buffers are not suitable for hardware-accelerated rendering nor video decoding. KMS dumb buffers are not suitable to be displayed on any other device than the KMS device where they were allocated from. Also see Dumb Buffer Objects.

The IOCTL argument is a struct drm_mode_create_dumb.

User-space is expected to create a KMS dumb buffer via this IOCTL, then add it as a KMS framebuffer via DRM_IOCTL_MODE_ADDFB and map it via DRM_IOCTL_MODE_MAP_DUMB.

DRM_CAP_DUMB_BUFFER indicates whether this IOCTL is supported. DRM_CAP_DUMB_PREFERRED_DEPTH and DRM_CAP_DUMB_PREFER_SHADOW indicate driver preferences for dumb buffers.

DRM_IOCTL_MODE_GETFB2¶

DRM_IOCTL_MODE_GETFB2

Get framebuffer metadata.

Description

This queries metadata about a framebuffer. User-space fills drm_mode_fb_cmd2.fb_id as the input, and the kernels fills the rest of the struct as the output.

If the client is DRM master or has CAP_SYS_ADMIN, drm_mode_fb_cmd2.handles will be filled with GEM buffer handles. Fresh new GEM handles are always returned, even if another GEM handle referring to the same memory object already exists on the DRM file description. The caller is responsible for removing the new handles, e.g. via the DRM_IOCTL_GEM_CLOSE IOCTL. The same new handle will be returned for multiple planes in case they use the same memory object. Planes are valid until one has a zero handle -- this can be used to compute the number of planes.

Otherwise, drm_mode_fb_cmd2.handles will be zeroed and planes are valid until one has a zero drm_mode_fb_cmd2.pitches.

If the framebuffer has a format modifier, DRM_MODE_FB_MODIFIERS will be set in drm_mode_fb_cmd2.flags and drm_mode_fb_cmd2.modifier will contain the modifier. Otherwise, user-space must ignore drm_mode_fb_cmd2.modifier.

To obtain DMA-BUF FDs for each plane without leaking GEM handles, user-space can export each handle via DRM_IOCTL_PRIME_HANDLE_TO_FD, then immediately close each unique handle via DRM_IOCTL_GEM_CLOSE, making sure to not double-close handles which are specified multiple times in the array.

DRM_IOCTL_SYNCOBJ_EVENTFD¶

DRM_IOCTL_SYNCOBJ_EVENTFD

Register an eventfd to be signalled by a syncobj.

Description

This can be used to integrate a syncobj in an event loop.

The IOCTL argument is a struct drm_syncobj_eventfd.

DRM_IOCTL_MODE_CLOSEFB¶

DRM_IOCTL_MODE_CLOSEFB

Close a framebuffer.

Description

This closes a framebuffer previously added via ADDFB/ADDFB2. The IOCTL argument is a framebuffer object ID.

This IOCTL is similar to DRM_IOCTL_MODE_RMFB, except it doesn’t disable planes and CRTCs. As long as the framebuffer is used by a plane, it’s kept alive. When the plane no longer uses the framebuffer (because the framebuffer is replaced with another one, or the plane is disabled), the framebuffer is cleaned up.

This is useful to implement flicker-free transitions between two processes.

Depending on the threat model, user-space may want to ensure that the framebuffer doesn’t expose any sensitive user information: closed framebuffers attached to a plane can be read back by the next DRM master.

DRM_IOCTL_SET_CLIENT_NAME¶

DRM_IOCTL_SET_CLIENT_NAME

Attach a name to a drm_file

Description

Having a name allows for easier tracking and debugging. The length of the name (without null ending char) must be <= DRM_CLIENT_NAME_MAX_LEN. The call will fail if the name contains whitespaces or non-printable chars.

DRM_IOCTL_GEM_CHANGE_HANDLE¶

DRM_IOCTL_GEM_CHANGE_HANDLE

Move an object to a different handle

Description

Some applications (notably CRIU) need objects to have specific gem handles. This ioctl changes the object at one gem handle to use a new gem handle.

struct drm_event¶

Header for DRM events

struct drm_event {
    __u32 type;
    __u32 length;
};

Description

This struct is a header for events written back to user-space on the DRM FD. A read on the DRM FD will always only return complete events: e.g. if the read buffer is 100 bytes large and there are two 64 byte events pending, only one will be returned.

Event types 0 - 0x7fffffff are generic DRM events, 0x80000000 and up are chipset specific. Generic DRM events include DRM_EVENT_VBLANK, DRM_EVENT_FLIP_COMPLETE and DRM_EVENT_CRTC_SEQUENCE.

DRM_EVENT_VBLANK¶

DRM_EVENT_VBLANK

vertical blanking event

Description

This event is sent in response to DRM_IOCTL_WAIT_VBLANK with the _DRM_VBLANK_EVENT flag set.

The event payload is a struct drm_event_vblank.

DRM_EVENT_FLIP_COMPLETE¶

DRM_EVENT_FLIP_COMPLETE

page-flip completion event

Description

This event is sent in response to an atomic commit or legacy page-flip with the DRM_MODE_PAGE_FLIP_EVENT flag set.

The event payload is a struct drm_event_vblank.

DRM_EVENT_CRTC_SEQUENCE¶

DRM_EVENT_CRTC_SEQUENCE

CRTC sequence event

Description

This event is sent in response to DRM_IOCTL_CRTC_QUEUE_SEQUENCE.

The event payload is a struct drm_event_crtc_sequence.

struct drm_mode_modeinfo¶

Display mode information.

struct drm_mode_modeinfo {
    __u32 clock;
    __u16 hdisplay;
    __u16 hsync_start;
    __u16 hsync_end;
    __u16 htotal;
    __u16 hskew;
    __u16 vdisplay;
    __u16 vsync_start;
    __u16 vsync_end;
    __u16 vtotal;
    __u16 vscan;
    __u32 vrefresh;
    __u32 flags;
    __u32 type;
    char name[DRM_DISPLAY_MODE_LEN];
};

Description

This is the user-space API display mode information structure. For the kernel version see struct drm_display_mode.

struct drm_mode_get_plane¶

Get plane metadata.

struct drm_mode_get_plane {
    __u32 plane_id;
    __u32 crtc_id;
    __u32 fb_id;
    __u32 possible_crtcs;
    __u32 gamma_size;
    __u32 count_format_types;
    __u64 format_type_ptr;
};

Description

Userspace can perform a GETPLANE ioctl to retrieve information about a plane.

To retrieve the number of formats supported, set count_format_types to zero and call the ioctl. count_format_types will be updated with the value.

To retrieve these formats, allocate an array with the memory needed to store count_format_types formats. Point format_type_ptr to this array and call the ioctl again (with count_format_types still set to the value returned in the first ioctl call).

struct drm_mode_get_connector¶

Get connector metadata.

struct drm_mode_get_connector {
    __u64 encoders_ptr;
    __u64 modes_ptr;
    __u64 props_ptr;
    __u64 prop_values_ptr;
    __u32 count_modes;
    __u32 count_props;
    __u32 count_encoders;
    __u32 encoder_id;
    __u32 connector_id;
    __u32 connector_type;
    __u32 connector_type_id;
    __u32 connection;
    __u32 mm_width;
    __u32 mm_height;
    __u32 subpixel;
    __u32 pad;
};

Description

User-space can perform a GETCONNECTOR ioctl to retrieve information about a connector. User-space is expected to retrieve encoders, modes and properties by performing this ioctl at least twice: the first time to retrieve the number of elements, the second time to retrieve the elements themselves.

To retrieve the number of elements, set count_props and count_encoders to zero, set count_modes to 1, and set modes_ptr to a temporary struct drm_mode_modeinfo element.

To retrieve the elements, allocate arrays for encoders_ptr, modes_ptr, props_ptr and prop_values_ptr, then set count_modes, count_props and count_encoders to their capacity.

Performing the ioctl only twice may be racy: the number of elements may have changed with a hotplug event in-between the two ioctls. User-space is expected to retry the last ioctl until the number of elements stabilizes. The kernel won’t fill any array which doesn’t have the expected length.

Force-probing a connector

If the count_modes field is set to zero and the DRM client is the current DRM master, the kernel will perform a forced probe on the connector to refresh the connector status, modes and EDID. A forced-probe can be slow, might cause flickering and the ioctl will block.

User-space needs to force-probe connectors to ensure their metadata is up-to-date at startup and after receiving a hot-plug event. User-space may perform a forced-probe when the user explicitly requests it. User-space shouldn’t perform a forced-probe in other situations.

struct drm_mode_property_enum¶

Description for an enum/bitfield entry.

struct drm_mode_property_enum {
    __u64 value;
    char name[DRM_PROP_NAME_LEN];
};

Description

See struct drm_property_enum for details.

struct drm_mode_get_property¶

Get property metadata.

struct drm_mode_get_property {
    __u64 values_ptr;
    __u64 enum_blob_ptr;
    __u32 prop_id;
    __u32 flags;
    char name[DRM_PROP_NAME_LEN];
    __u32 count_values;
    __u32 count_enum_blobs;
};

Description

User-space can perform a GETPROPERTY ioctl to retrieve information about a property. The same property may be attached to multiple objects, see “Modeset Base Object Abstraction”.

The meaning of the values_ptr field changes depending on the property type. See drm_property.flags for more details.

The enum_blob_ptr and count_enum_blobs fields are only meaningful when the property has the type DRM_MODE_PROP_ENUM or DRM_MODE_PROP_BITMASK. For backwards compatibility, the kernel will always set count_enum_blobs to zero when the property has the type DRM_MODE_PROP_BLOB. User-space must ignore these two fields if the property has a different type.

User-space is expected to retrieve values and enums by performing this ioctl at least twice: the first time to retrieve the number of elements, the second time to retrieve the elements themselves.

To retrieve the number of elements, set count_values and count_enum_blobs to zero, then call the ioctl. count_values will be updated with the number of elements. If the property has the type DRM_MODE_PROP_ENUM or DRM_MODE_PROP_BITMASK, count_enum_blobs will be updated as well.

To retrieve the elements themselves, allocate an array for values_ptr and set count_values to its capacity. If the property has the type DRM_MODE_PROP_ENUM or DRM_MODE_PROP_BITMASK, allocate an array for enum_blob_ptr and set count_enum_blobs to its capacity. Calling the ioctl again will fill the arrays.

struct drm_mode_fb_cmd2¶

Frame-buffer metadata.

struct drm_mode_fb_cmd2 {
    __u32 fb_id;
    __u32 width;
    __u32 height;
    __u32 pixel_format;
    __u32 flags;
    __u32 handles[4];
    __u32 pitches[4];
    __u32 offsets[4];
    __u64 modifier[4];
};

Description

This struct holds frame-buffer metadata. There are two ways to use it:

• User-space can fill this struct and perform a DRM_IOCTL_MODE_ADDFB2 ioctl to register a new frame-buffer. The new frame-buffer object ID will be set by the kernel in fb_id.

• User-space can set fb_id and perform a DRM_IOCTL_MODE_GETFB2 ioctl to fetch metadata about an existing frame-buffer.

In case of planar formats, this struct allows up to 4 buffer objects with offsets and pitches per plane. The pitch and offset order are dictated by the format FourCC as defined by drm_fourcc.h, e.g. NV12 is described as:

YUV 4:2:0 image with a plane of 8-bit Y samples followed by an interleaved U/V plane containing 8-bit 2x2 subsampled colour difference samples.

So it would consist of a Y plane at offsets[0] and a UV plane at offsets[1].

To accommodate tiled, compressed, etc formats, a modifier can be specified. For more information see the “Format Modifiers” section. Note that even though it looks like we have a modifier per-plane, we in fact do not. The modifier for each plane must be identical. Thus all combinations of different data layouts for multi-plane formats must be enumerated as separate modifiers.

All of the entries in handles, pitches, offsets and modifier must be zero when unused. Warning, for offsets and modifier zero can’t be used to figure out whether the entry is used or not since it’s a valid value (a zero offset is common, and a zero modifier is DRM_FORMAT_MOD_LINEAR).

enum drm_colorop_type¶

Type of color operation

Description

drm_colorops can be of many different types. Each type behaves differently and defines a different set of properties. This enum defines all types and gives a high-level description.

enum drm_colorop_lut3d_interpolation_type¶

type of 3DLUT interpolation

enum drm_colorop_lut1d_interpolation_type¶

type of interpolation for 1D LUTs

struct drm_plane_size_hint¶

Plane size hints

struct drm_plane_size_hint {
    __u16 width;
    __u16 height;
};

Description

The plane SIZE_HINTS property blob contains an array of struct drm_plane_size_hint.

struct hdr_metadata_infoframe¶

HDR Metadata Infoframe Data.

struct hdr_metadata_infoframe {
    __u8 eotf;
    __u8 metadata_type;
    struct {
        __u16 x, y;
    } display_primaries[3];
    struct {
        __u16 x, y;
    } white_point;
    __u16 max_display_mastering_luminance;
    __u16 min_display_mastering_luminance;
    __u16 max_cll;
    __u16 max_fall;
};

Description

HDR Metadata Infoframe as per CTA 861.G spec. This is expected to match exactly with the spec.

Userspace is expected to pass the metadata information as per the format described in this structure.

struct hdr_output_metadata¶

HDR output metadata

struct hdr_output_metadata {
    __u32 metadata_type;
    union {
        struct hdr_metadata_infoframe hdmi_metadata_type1;
    };
};

Description

Metadata Information to be passed from userspace

DRM_MODE_PAGE_FLIP_EVENT¶

DRM_MODE_PAGE_FLIP_EVENT

Description

Request that the kernel sends back a vblank event (see struct drm_event_vblank) with the DRM_EVENT_FLIP_COMPLETE type when the page-flip is done.

When used with atomic uAPI, one event will be delivered per CRTC included in the atomic commit. A CRTC is included in an atomic commit if one of its properties is set, or if a property is set on a connector or plane linked via the CRTC_ID property to the CRTC. At least one CRTC must be included, and all pulled in CRTCs must be either previously or newly powered on (in other words, a powered off CRTC which stays off cannot be included in the atomic commit).

DRM_MODE_PAGE_FLIP_ASYNC¶

DRM_MODE_PAGE_FLIP_ASYNC

Description

Request that the page-flip is performed as soon as possible, ie. with no delay due to waiting for vblank. This may cause tearing to be visible on the screen.

When used with atomic uAPI, the driver will return an error if the hardware doesn’t support performing an asynchronous page-flip for this update. User-space should handle this, e.g. by falling back to a regular page-flip.

Note, some hardware might need to perform one last synchronous page-flip before being able to switch to asynchronous page-flips. As an exception, the driver will return success even though that first page-flip is not asynchronous.

DRM_MODE_PAGE_FLIP_FLAGS¶

DRM_MODE_PAGE_FLIP_FLAGS

Description

Bitmask of flags suitable for drm_mode_crtc_page_flip_target.flags.

struct drm_mode_create_dumb¶

Create a KMS dumb buffer for scanout.

struct drm_mode_create_dumb {
    __u32 height;
    __u32 width;
    __u32 bpp;
    __u32 flags;
    __u32 handle;
    __u32 pitch;
    __u64 size;
};

Description

User-space fills height, width, bpp and flags. If the IOCTL succeeds, the kernel fills handle, pitch and size.

The value of bpp is a color-mode number describing a specific format or a variant thereof. The value often corresponds to the number of bits per pixel for most modes, although there are exceptions. Each color mode maps to a DRM format plus a number of modes with similar pixel layout. Framebuffer layout is always linear.

Support for all modes and formats is optional. Even if dumb-buffer creation with a certain color mode succeeds, it is not guaranteed that the DRM driver supports any of the related formats. Most drivers support a color mode of 32 with a format of DRM_FORMAT_XRGB8888 on their primary plane.

Color modes of 10, 12, 15, 30 and 64 are only supported for use by legacy user space. Please don’t use them in new code. Other modes are not support.

Do not attempt to allocate anything but linear framebuffer memory with single-plane RGB data. Allocation of other framebuffer layouts requires dedicated ioctls in the respective DRM driver.

DRM_MODE_ATOMIC_TEST_ONLY¶

DRM_MODE_ATOMIC_TEST_ONLY

Description

Do not apply the atomic commit, instead check whether the hardware supports this configuration.

See drm_mode_config_funcs.atomic_check for more details on test-only commits.

DRM_MODE_ATOMIC_NONBLOCK¶

DRM_MODE_ATOMIC_NONBLOCK

Description

Do not block while applying the atomic commit. The DRM_IOCTL_MODE_ATOMIC IOCTL returns immediately instead of waiting for the changes to be applied in hardware. Note, the driver will still check that the update can be applied before retuning.

DRM_MODE_ATOMIC_ALLOW_MODESET¶

DRM_MODE_ATOMIC_ALLOW_MODESET

Description

Allow the update to result in temporary or transient visible artifacts while the update is being applied. Applying the update may also take significantly more time than a page flip. All visual artifacts will disappear by the time the update is completed, as signalled through the vblank event’s timestamp (see struct drm_event_vblank).

This flag must be set when the KMS update might cause visible artifacts. Without this flag such KMS update will return a EINVAL error. What kind of update may cause visible artifacts depends on the driver and the hardware. User-space that needs to know beforehand if an update might cause visible artifacts can use DRM_MODE_ATOMIC_TEST_ONLY without DRM_MODE_ATOMIC_ALLOW_MODESET to see if it fails.

To the best of the driver’s knowledge, visual artifacts are guaranteed to not appear when this flag is not set. Some sinks might display visual artifacts outside of the driver’s control.

DRM_MODE_ATOMIC_FLAGS¶

DRM_MODE_ATOMIC_FLAGS

Description

Bitfield of flags accepted by the DRM_IOCTL_MODE_ATOMIC IOCTL in drm_mode_atomic.flags.

struct drm_mode_create_blob¶

Create New blob property

struct drm_mode_create_blob {
    __u64 data;
    __u32 length;
    __u32 blob_id;
};

Description

Create a new ‘blob’ data property, copying length bytes from data pointer, and returning new blob ID.

struct drm_mode_destroy_blob¶

Destroy user blob

struct drm_mode_destroy_blob {
    __u32 blob_id;
};

Description

Destroy a user-created blob property.

User-space can release blobs as soon as they do not need to refer to them by their blob object ID. For instance, if you are using a MODE_ID blob in an atomic commit and you will not make another commit re-using the same ID, you can destroy the blob as soon as the commit has been issued, without waiting for it to complete.

struct drm_mode_create_lease¶

Create lease

struct drm_mode_create_lease {
    __u64 object_ids;
    __u32 object_count;
    __u32 flags;
    __u32 lessee_id;
    __u32 fd;
};

Description

Lease mode resources, creating another drm_master.

The object_ids array must reference at least one CRTC, one connector and one plane if DRM_CLIENT_CAP_UNIVERSAL_PLANES is enabled. Alternatively, the lease can be completely empty.

struct drm_mode_list_lessees¶

List lessees

struct drm_mode_list_lessees {
    __u32 count_lessees;
    __u32 pad;
    __u64 lessees_ptr;
};

Description

List lesses from a drm_master.

struct drm_mode_get_lease¶

Get Lease

struct drm_mode_get_lease {
    __u32 count_objects;
    __u32 pad;
    __u64 objects_ptr;
};

Description

Get leased objects.

struct drm_mode_revoke_lease¶

Revoke lease

struct drm_mode_revoke_lease {
    __u32 lessee_id;
};

struct drm_mode_rect¶

Two dimensional rectangle.

struct drm_mode_rect {
    __s32 x1;
    __s32 y1;
    __s32 x2;
    __s32 y2;
};

Description

With drm subsystem using struct drm_rect to manage rectangular area this export it to user-space.

Currently used by drm_mode_atomic blob property FB_DAMAGE_CLIPS.

struct drm_mode_closefb¶

struct drm_mode_closefb {
    __u32 fb_id;
    __u32 pad;
};

Stable uAPI events¶

From drivers/gpu/drm/scheduler/gpu_scheduler_trace.h

drm_sched_job_queue, drm_sched_job_run, drm_sched_job_add_dep, drm_sched_job_done and drm_sched_job_unschedulable are considered stable uAPI.

Common trace events attributes:

• dev - the dev_name() of the device running the job.

• ring - the hardware ring running the job. Together with dev it uniquely identifies where the job is going to be executed.

• fence - the struct dma_fence.context and the struct dma_fence.seqno of struct drm_sched_fence.finished

All the events depends on drm_sched_job_arm() having been called already for the job because they use struct drm_sched_job.sched or struct drm_sched_job.s_fence.