Lines Matching +full:machine +full:- +full:mode +full:- +full:visible
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
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
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
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
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
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
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
188 used, and expects that the very least the machine does not crash. Any
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()
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 ----------------------------
277 dmabuf which might be mapped to other devices (cross-device dmabuf
304 Kernel Mode Driver
305 ------------------
329 User Mode Driver
330 ----------------
340 ----------
347 userspace that doesn't support robust interfaces (like a non-robust
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
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
481 virtual machine without display, simplifying the validation of some of the
486 install it in the target machine. VKMS can be run in a Virtual Machine
490 It's possible to run the IGT-tests in a VM in two ways:
493 2. Use IGT from the host machine and write the results in a shared directory.
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.