Lines Matching +full:has +full:- +full:legacy +full:- +full:mode
9 addition, drivers export device-specific interfaces for use by userspace
10 drivers & device-aware applications through ioctls and sysfs files.
16 Cover generic ioctls and sysfs layout here. We only need high-level
22 .. kernel-doc:: drivers/gpu/drm/drm_ioctl.c
31 .. kernel-doc:: drivers/gpu/drm/drm_auth.c
34 .. kernel-doc:: drivers/gpu/drm/drm_auth.c
37 .. kernel-doc:: include/drm/drm_auth.h
46 .. kernel-doc:: drivers/gpu/drm/drm_lease.c
49 Open-Source Userspace Requirements
52 The DRM subsystem has stricter requirements than most other kernel subsystems on
57 open-sourced userspace patches, and those patches must be reviewed and ready for
75 - The Linux kernel's "no regression" policy holds in practice only for
76 open-source userspace of the DRM subsystem. DRM developers are perfectly fine
77 if closed-source blob drivers in userspace use the same uAPI as the open
79 Creative (ab)use of the interfaces will, and in the past routinely has, lead
82 - Any new userspace interface must have an open-source implementation as
85 The other reason for requiring open-source userspace is uAPI review. Since the
88 both sides. Making sure that the interface indeed covers the use-case fully
91 - The open-source userspace must not be a toy/test application, but the real
96 - The userspace side must be fully reviewed and tested to the standards of that
99 job done. The userspace-side reviewer should also provide an Acked-by on the
103 - The userspace patches must be against the canonical upstream, not some vendor
107 - The kernel patch can only be merged after all the above requirements are met,
108 but it **must** be merged to either drm-next or drm-misc-next **before** the
118 for the same thing co-existing. If we add a few more complete mistakes into the
126 DRM core provides multiple character-devices for user-space to use.
127 Depending on which device is opened, user-space can perform a different
131 legacy operations and historically was the only interface used by
133 planned KMS control interface has never been written and so the control
139 authenticate to a DRM-Master prior to getting GPU access. To avoid this
143 Only non-global rendering commands are allowed. If a driver supports
146 clients together with the legacy drmAuth authentication procedure.
150 per device. No ioctls except PRIME-related ioctls will be allowed on
152 complete list of driver-independent ioctls that can be used on render
154 nodes are designed to avoid the buffer-leaks, which occur if clients
155 guess the flink names or mmap offsets on the legacy interface.
157 driver-dependent render-only ioctls as DRM_RENDER_ALLOW so render
161 With render nodes, user-space can now control access to the render node
162 via basic file-system access-modes. A running graphics server which
163 authenticates clients on the privileged primary/legacy node is no longer
166 via PRIME. FLINK from render node to legacy node is not supported. New
170 DRM-Master concept. There is no reason to associate render clients with
171 a DRM-Master as they are independent of any graphics server. Besides,
175 visible to user-space and accessible beyond open-file boundaries, they
178 Device Hot-Unplug
187 user is able to hot-unplug this kind of devices while they are being
189 damage from hot-unplugging a DRM device needs to be limited as much as
204 (or driver-specific ioctls returning driver-specific things), or open()
207 Only after userspace has closed all relevant DRM device and dmabuf file
222 -------------------------
224 - KMS connectors must change their status to disconnected.
226 - Legacy modesets and pageflips, and atomic commits, both real and
230 - Pending non-blocking KMS operations deliver the DRM events userspace
233 - open() on a device node whose underlying device has disappeared will
236 - Attempting to create a DRM lease on a disappeared DRM device will
240 Requirements for Render and Cross-Device UAPI
241 ---------------------------------------------
243 - All GPU jobs that can no longer run must have their fences
244 force-signalled to avoid inflicting hangs on userspace.
247 - Some userspace APIs already define what should happen when the device
251 driver-specific ioctls and handling those in userspace drivers, or
254 - dmabuf which point to memory that has disappeared will either fail to
259 - Attempting to import a dmabuf to a disappeared device will either fail
263 - open() on a device node whose underlying device has disappeared will
270 ----------------------------
273 and maps created after the device has disappeared. If the underlying
277 dmabuf which might be mapped to other devices (cross-device dmabuf
304 Kernel Mode Driver
305 ------------------
310 Propagation of errors to userspace has proven to be tricky since it goes in
329 User Mode Driver
330 ----------------
340 ----------
347 userspace that doesn't support robust interfaces (like a non-robust
358 interface tells if a reset has happened, and if so, all the context state is
366 This error code means, among other things, that a device reset has happened and
370 --------------------------
383 .. kernel-doc:: drivers/gpu/drm/drm_ioctl.c
387 -------------------------------
410 E.g. root-only or much more common, DRM master-only operations return
422 when the exporting driver of a shared dma-buf or fence doesn't support a
436 Catch-all for anything that is an invalid argument combination which
441 DRM specific patterns. Note that ENOTTY has the slightly unintuitive meaning of
444 .. kernel-doc:: include/drm/drm_ioctl.h
447 .. kernel-doc:: drivers/gpu/drm/drm_ioctl.c
450 .. kernel-doc:: drivers/gpu/drm/drm_ioc32.c
457 --------------------------------------
459 New cross-driver userspace interface extensions, like new IOCTL, new KMS
461 should have driver-agnostic testcases in IGT for that feature, if such a test
465 ---------------------------
471 https://gitlab.freedesktop.org/drm/igt-gpu-tools/.
474 --------------------------
476 VKMS is a software-only model of a KMS driver that is useful for testing
490 It's possible to run the IGT-tests in a VM in two ways:
496 the host machine to run igt-tests. This example uses virtme::
498 $ virtme-run --rwdir /path/for/shared_dir --kdir=path/for/kernel/directory --mods=auto
500 Run the igt-tests in the guest machine. This example runs the 'kms_flip'
503 $ /path/for/igt-gpu-tools/scripts/run-tests.sh -p -s -t "kms_flip.*" -v
506 (-p option). It creates an HTML summary of the test results and saves
507 them in the folder "igt-gpu-tools/results". It executes only the igt-tests
508 matching the -t option.
511 -------------------
513 .. kernel-doc:: drivers/gpu/drm/drm_debugfs_crc.c
516 .. kernel-doc:: drivers/gpu/drm/drm_debugfs_crc.c
520 ---------------
522 .. kernel-doc:: include/drm/drm_debugfs.h
525 .. kernel-doc:: drivers/gpu/drm/drm_debugfs.c
531 .. kernel-doc:: drivers/gpu/drm/drm_sysfs.c
534 .. kernel-doc:: drivers/gpu/drm/drm_sysfs.c
549 This was only used for user-mode-settind drivers around modesetting
551 mode setting, since on many devices the vertical blank counter is
553 call this any more since with kernel mode setting it is a no-op.
558 .. kernel-doc:: include/uapi/drm/drm_mode.h
564 ----------
574 .. kernel-doc:: include/uapi/drm/drm.h
577 .. kernel-doc:: include/uapi/drm/drm_mode.h
581 dma-buf interoperability
584 Please see Documentation/userspace-api/dma-buf-alloc-exchange.rst for
585 information on how dma-buf is integrated and exposed within DRM.