Lines Matching +full:master +full:- +full:side
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
28 Primary Nodes, DRM Master and Authentication
31 .. kernel-doc:: drivers/gpu/drm/drm_auth.c
32 :doc: master and authentication
34 .. kernel-doc:: drivers/gpu/drm/drm_auth.c
37 .. kernel-doc:: include/drm/drm_auth.h
40 Open-Source Userspace Requirements
44 what the userspace side for new uAPI needs to look like. This section here
48 open-sourced userspace patches, and those patches must be reviewed and ready for
51 GFX devices (both display and render/GPU side) are really complex bits of
66 - The Linux kernel's "no regression" policy holds in practice only for
67 open-source userspace of the DRM subsystem. DRM developers are perfectly fine
68 if closed-source blob drivers in userspace use the same uAPI as the open
73 - Any new userspace interface must have an open-source implementation as
76 The other reason for requiring open-source userspace is uAPI review. Since the
79 both sides. Making sure that the interface indeed covers the use-case fully
82 - The open-source userspace must not be a toy/test application, but the real
87 - The userspace side must be fully reviewed and tested to the standards of that
90 job done. The userspace-side reviewer should also provide an Acked-by on the
94 - The userspace patches must be against the canonical upstream, not some vendor
98 - The kernel patch can only be merged after all the above requirements are met,
99 but it **must** be merged to either drm-next or drm-misc-next **before** the
109 for the same thing co-existing. If we add a few more complete mistakes into the
117 DRM core provides multiple character-devices for user-space to use.
118 Depending on which device is opened, user-space can perform a different
130 authenticate to a DRM-Master prior to getting GPU access. To avoid this
134 Only non-global rendering commands are allowed. If a driver supports
141 per device. No ioctls except PRIME-related ioctls will be allowed on
143 nodes are designed to avoid the buffer-leaks, which occur if clients
146 driver-dependent render-only ioctls as DRM_RENDER_ALLOW so render
150 With render nodes, user-space can now control access to the render node
151 via basic file-system access-modes. A running graphics server which
159 DRM-Master concept. There is no reason to associate render clients with
160 a DRM-Master as they are independent of any graphics server. Besides,
161 they must work without any running master, anyway. Drivers must be able
162 to run without a master object if they support render nodes. If, on the
164 visible to user-space and accessible beyond open-file boundaries, they
167 Device Hot-Unplug
176 user is able to hot-unplug this kind of devices while they are being
178 damage from hot-unplugging a DRM device needs to be limited as much as
193 (or driver-specific ioctls returning driver-specific things), or open()
211 -------------------------
213 - KMS connectors must change their status to disconnected.
215 - Legacy modesets and pageflips, and atomic commits, both real and
219 - Pending non-blocking KMS operations deliver the DRM events userspace
222 - open() on a device node whose underlying device has disappeared will
225 - Attempting to create a DRM lease on a disappeared DRM device will
229 Requirements for Render and Cross-Device UAPI
230 ---------------------------------------------
232 - All GPU jobs that can no longer run must have their fences
233 force-signalled to avoid inflicting hangs on userspace.
236 - Some userspace APIs already define what should happen when the device
240 driver-specific ioctls and handling those in userspace drivers, or
243 - dmabuf which point to memory that has disappeared will either fail to
248 - Attempting to import a dmabuf to a disappeared device will either fail
252 - open() on a device node whose underlying device has disappeared will
259 ----------------------------
266 dmabuf which might be mapped to other devices (cross-device dmabuf
282 .. kernel-doc:: drivers/gpu/drm/drm_ioctl.c
286 -------------------------------
309 E.g. root-only or much more common, DRM master-only operations return
321 when the exporting driver of a shared dma-buf or fence doesn't support a
335 Catch-all for anything that is an invalid argument combination which
343 .. kernel-doc:: include/drm/drm_ioctl.h
346 .. kernel-doc:: drivers/gpu/drm/drm_ioctl.c
349 .. kernel-doc:: drivers/gpu/drm/drm_ioc32.c
356 --------------------------------------
358 New cross-driver userspace interface extensions, like new IOCTL, new KMS
360 should have driver-agnostic testcases in IGT for that feature, if such a test
364 ---------------------------
370 https://gitlab.freedesktop.org/drm/igt-gpu-tools/.
373 --------------------------
375 VKMS is a software-only model of a KMS driver that is useful for testing
389 It's possible to run the IGT-tests in a VM in two ways:
395 the host machine to run igt-tests. As an example it's used virtme::
397 $ virtme-run --rwdir /path/for/shared_dir --kdir=path/for/kernel/directory --mods=auto
399 Run the igt-tests in the guest machine, as example it's ran the 'kms_flip'
402 $ /path/for/igt-gpu-tools/scripts/run-tests.sh -p -s -t "kms_flip.*" -v
405 (-p option); it's created html summary of the tests results and it's saved
406 in the folder "igt-gpu-tools/results"; it's executed only the igt-tests
407 matching the -t option.
410 -------------------
412 .. kernel-doc:: drivers/gpu/drm/drm_debugfs_crc.c
415 .. kernel-doc:: drivers/gpu/drm/drm_debugfs_crc.c
419 ---------------
421 .. kernel-doc:: include/drm/drm_debugfs.h
424 .. kernel-doc:: drivers/gpu/drm/drm_debugfs.c
430 .. kernel-doc:: drivers/gpu/drm/drm_sysfs.c
433 .. kernel-doc:: drivers/gpu/drm/drm_sysfs.c
448 This was only used for user-mode-settind drivers around modesetting
452 call this any more since with kernel mode setting it is a no-op.
457 .. kernel-doc:: include/uapi/drm/drm_mode.h
460 .. kernel-doc:: include/uapi/drm/drm_mode.h