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
190 possible and userspace must be given the chance to handle it if it wants
193 graphics stack: from kernel and userspace drivers, through display
200 In other words, from userspace perspective everything needs to keep on
201 working more or less, until userspace stops using the disappeared DRM
202 device and closes it completely. Userspace will learn of the device
207 Only after userspace has closed all relevant DRM device and dmabuf file
230 - Pending non-blocking KMS operations deliver the DRM events userspace
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
276 This applies to both userspace mmap()'d memory and memory pointed to by
280 Raising SIGBUS is not an option, because userspace cannot realistically
336         DRM drivers assume that userspace restarts all IOCTLs. Any DRM IOCTL can
366 Testing Requirements for userspace API
369 New cross-driver userspace interface extensions, like new IOCTL, new KMS
465 Userspace API Structures