Lines Matching full:userspace

9 addition, drivers export device-specific interfaces for use by userspace
49 Open-Source Userspace Requirements
53 what the userspace side for new uAPI needs to look like. This section here
57 open-sourced userspace patches, and those patches must be reviewed and ready for
61 hardware, with userspace and kernel by necessity having to work together really
65 infeasible to differentiate between behaviour that's required by userspace, and
69 Without access to the full source code of all userspace users that means it
70 becomes impossible to change the implementation details, since userspace could
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
86 kernel and userspace parts of a GFX stack must work together so closely, code
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
97   userspace project. For e.g. mesa this means piglit testcases and review on the
99   job done.  The userspace-side reviewer should also provide an Acked-by on the
101   sufficiently documented and validated for userspace's consumption.
103 - The userspace patches must be against the canonical upstream, not some vendor
109   userspace patches land. uAPI always flows from the kernel, doing things the
116 Linux kernel's guarantee to keep existing userspace running for 10+ years this
132 userspace. With KMS, the control node was introduced. However, the
188 possible and userspace must be given the chance to handle it if it wants
191 graphics stack: from kernel and userspace drivers, through display
198 In other words, from userspace perspective everything needs to keep on
199 working more or less, until userspace stops using the disappeared DRM
200 device and closes it completely. Userspace will learn of the device
205 Only after userspace has closed all relevant DRM device and dmabuf file
228 - Pending non-blocking KMS operations deliver the DRM events userspace
242   force-signalled to avoid inflicting hangs on userspace.
245 - Some userspace APIs already define what should happen when the device
249   driver-specific ioctls and handling those in userspace drivers, or
274 This applies to both userspace mmap()'d memory and memory pointed to by
278 Raising SIGBUS is not an option, because userspace cannot realistically
334         DRM drivers assume that userspace restarts all IOCTLs. Any DRM IOCTL can
364 Testing Requirements for userspace API
367 New cross-driver userspace interface extensions, like new IOCTL, new KMS
463 Userspace API Structures