linux-toradex.git/drivers/gpu/drm/drm_ioctl.c, branch v6.19

drm/colorop: Introduce DRM_CLIENT_CAP_PLANE_COLOR_PIPELINE

2025-11-26T22:03:32+00:00

With the introduction of the pre-blending color pipeline we
can no longer have color operations that don't have a clear
position in the color pipeline. We deprecate all existing
plane properties. For upstream drivers those are:
 - COLOR_ENCODING
 - COLOR_RANGE

Drivers are expected to ignore these properties when
programming the HW. DRM clients that register with
DRM_CLIENT_CAP_PLANE_COLOR_PIPELINE will not be allowed to
set the COLOR_ENCODING and COLOR_RANGE properties.

Setting of the COLOR_PIPELINE plane property or drm_colorop
properties is only allowed for userspace that sets this
client cap.

Reviewed-by: Simon Ser 
Signed-off-by: Alex Hung 
Signed-off-by: Harry Wentland 
Reviewed-by: Daniel Stone 
Reviewed-by: Melissa Wen 
Reviewed-by: Sebastian Wick 
Signed-off-by: Simon Ser 
Link: https://patch.msgid.link/20251115000237.3561250-12-alex.hung@amd.com

drm: Add DRM prime interface to reassign GEM handle

2025-07-18T06:59:24+00:00

CRIU restore of drm buffer objects requires the ability to create
or import a buffer object with a specific gem handle.

Add new drm ioctl DRM_IOCTL_GEM_CHANGE_HANDLE, which takes
the gem handle of an object and moves that object to a
specified new gem handle.

This ioctl needs to call drm_prime_remove_buf_handle,
but that function acquires the prime lock, which the ioctl
needs to hold for other purposes.

Make drm_prime_remove_buf_handle not acquire the prime lock,
and change its other caller to reflect this.

The rest of the kernel patches required to enable CRIU can be
found at
https://lore.kernel.org/dri-devel/20250617194536.538681-1-David.Francis@amd.com/

v2 - Move documentation to UAPI headers
v3 - Always return 0 on success

Signed-off-by: David Francis 
Acked-by: Felix Kuehling 
Reviewed-by: Christian König 
Signed-off-by: Christian König 
Link: https://lore.kernel.org/r/20250717143556.857893-2-David.Francis@amd.com

drm: add DRM_SET_CLIENT_NAME ioctl

2024-10-08T08:00:30+00:00

Giving the opportunity to userspace to associate a free-form
name with a drm_file struct is helpful for tracking and debugging.

This is similar to the existing DMA_BUF_SET_NAME ioctl.

Access to client_name is protected by a mutex, and the 'clients' debugfs
file has been updated to print it.

Userspace MR to use this ioctl:
   https://gitlab.freedesktop.org/virgl/virglrenderer/-/merge_requests/1428

If the string passed by userspace contains chars that would mess up output
when it's going to be printed (in dmesg, fdinfo, etc), -EINVAL is returned.

A 0-length string is a valid use, and clears the existing name.

Reviewed-by: Tvrtko Ursulin 
Reviewed-by: Dmitry Osipenko 
Signed-off-by: Pierre-Eric Pelloux-Prayer 
Link: https://patchwork.freedesktop.org/patch/msgid/20241003124506.470931-2-pierre-eric.pelloux-prayer@amd.com
Reviewed-by: Christian König 
Signed-off-by: Christian König

drm: use "0" instead of "" for deprecated driver date

2024-05-10T17:56:12+00:00

libdrm does not like the empty string for driver date. Use "0" instead,
which has been used by virtio previously.

Reported-by: Steven Price 
Closes: https://lore.kernel.org/r/9d0cff47-308e-4b11-a9f3-4157dc26b6fa@arm.com
Fixes: 7fb8af6798e8 ("drm: deprecate driver date")
Signed-off-by: Jani Nikula 
Signed-off-by: Ville Syrjälä 
Link: https://patchwork.freedesktop.org/patch/msgid/20240510090951.3398882-1-jani.nikula@intel.com
Reviewed-by: Javier Martinez Canillas 
Tested-by: Steven Price 
Reviewed-by: Simon Ser

drm: deprecate driver date

2024-05-08T12:31:58+00:00

The driver date serves no useful purpose, because it's hardly ever
updated. The information is misleading at best.

As described in Documentation/gpu/drm-internals.rst:

  The driver date, formatted as YYYYMMDD, is meant to identify the date
  of the latest modification to the driver. However, as most drivers
  fail to update it, its value is mostly useless. The DRM core prints it
  to the kernel log at initialization time and passes it to userspace
  through the DRM_IOCTL_VERSION ioctl.

Stop printing the driver date at init, and start returning the empty
string "" as driver date through the DRM_IOCTL_VERSION ioctl.

The driver date initialization in drivers and the struct drm_driver date
member can be removed in follow-up.

Reviewed-by: Hamza Mahfooz 
Acked-by: Simon Ser 
Reviewed-by: Javier Martinez Canillas 
Link: https://patchwork.freedesktop.org/patch/msgid/20240429164336.1406480-1-jani.nikula@intel.com
Signed-off-by: Jani Nikula

drm: Remove locking for legacy ioctls and DRM_UNLOCKED

2023-12-06T09:08:32+00:00

Modern DRM drivers acquire ioctl locks by themselves. Legacy ioctls
for user-space mode setting used to acquire drm_global_mutex. After
removing the ioctl entry points, also remove the locking code. The only
legacy ioctl without global locking was VBLANK_WAIT, which has been
removed as well. Hence remove the related DRM_UNLOCKED flag.

Signed-off-by: Thomas Zimmermann 
Reviewed-by: David Airlie 
Reviewed-by: Daniel Vetter 
Acked-by: Alex Deucher 
Link: https://patchwork.freedesktop.org/patch/msgid/20231122122449.11588-12-tzimmermann@suse.de

drm: Remove the legacy DRM_IOCTL_MODESET_CTL ioctl

2023-12-06T09:08:24+00:00

DRM drivers with user-space mode setting have been removed in Linux
v6.3. [1] Now remove the ioctl entry points for these drivers. Invoking
any of the ioctl ops will unconditionally return -EINVAL to user space.

Invoking DRM_IOCTL_MODESET_CTL is different from the other legacy
ioctl ops as it returns 0 even without CONFIG_DRM_LEGACY set. From the
original commit 29935554b384 ("drm: Disallow DRM_IOCTL_MODESET_CTL for
KMS drivers") it is not apparent how or why the operation differs from
the others. It is likely just an oversight in commit 61ae227032e7
("drm: allow removal of legacy codepaths (v4.1)"), which allowed
disabling leagacy ioctls in the first place. Still keep this removal
separate from the other ioctls to allow an easy revert, if necessary.

Signed-off-by: Thomas Zimmermann 
Link: https://patchwork.freedesktop.org/series/111602/ # [1]
Reviewed-by: David Airlie 
Reviewed-by: Daniel Vetter 
Acked-by: Alex Deucher 
Link: https://patchwork.freedesktop.org/patch/msgid/20231122122449.11588-10-tzimmermann@suse.de

drm: Remove entry points for legacy ioctls

2023-12-06T09:08:21+00:00

DRM drivers with user-space mode setting have been removed in Linux
v6.3. [1] Now remove the ioctl entry points for these drivers. Invoking
any of the ioctl ops will unconditionally return -EINVAL to user space.
This has already been the behavior for kernels without CONFIG_DRM_LEGACY
set.

Signed-off-by: Thomas Zimmermann 
Link: https://patchwork.freedesktop.org/series/111602/ # [1]
Reviewed-by: David Airlie 
Reviewed-by: Daniel Vetter 
Acked-by: Alex Deucher 
Link: https://patchwork.freedesktop.org/patch/msgid/20231122122449.11588-9-tzimmermann@suse.de

drm: Introduce DRM_CLIENT_CAP_CURSOR_PLANE_HOTSPOT

2023-11-24T10:58:03+00:00

Virtualized drivers place additional restrictions on the cursor plane
which breaks the contract of universal planes. To allow atomic
modesettings with virtualized drivers the clients need to advertise
that they're capable of dealing with those extra restrictions.

To do that introduce DRM_CLIENT_CAP_CURSOR_PLANE_HOTSPOT which
lets DRM know that the client is aware of and capable of dealing with
the extra restrictions on the virtual cursor plane.

Setting this option to true makes DRM expose the cursor plane on
virtualized drivers. The userspace is expected to set the hotspots
and handle mouse events on that plane.

Signed-off-by: Zack Rusin 
Cc: Maarten Lankhorst 
Cc: Maxime Ripard 
Cc: Thomas Zimmermann 
Cc: David Airlie 
Cc: Daniel Vetter 
Cc: dri-devel@lists.freedesktop.org
Acked-by: Pekka Paalanen 
Reviewed-by: Javier Martinez Canillas 
Signed-off-by: Javier Martinez Canillas 
Link: https://patchwork.freedesktop.org/patch/msgid/20231023074613.41327-9-aesteve@redhat.com

drm: introduce DRM_CAP_ATOMIC_ASYNC_PAGE_FLIP

2023-11-23T16:13:13+00:00

This new kernel capability indicates whether async page-flips are
supported via the atomic uAPI. DRM clients can use it to check
for support before feeding DRM_MODE_PAGE_FLIP_ASYNC to the kernel.

Make it clear that DRM_CAP_ASYNC_PAGE_FLIP is for legacy uAPI only.

Signed-off-by: Simon Ser 
Reviewed-by: André Almeida 
Reviewed-by: Alex Deucher 
Signed-off-by: André Almeida 
Signed-off-by: Simon Ser 
Link: https://patchwork.freedesktop.org/patch/msgid/20231122161941.320564-4-andrealmeid@igalia.com