Lines Matching refs:userspace

9 addition, drivers export device-specific interfaces for use by userspace
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
52 hardware, with userspace and kernel by necessity having to work together really
56 infeasible to differentiate between behaviour that's required by userspace, and
60 Without access to the full source code of all userspace users that means it
61 becomes impossible to change the implementation details, since userspace could
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
77 kernel and userspace parts of a GFX stack must work together so closely, code
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
88   userspace project. For e.g. mesa this means piglit testcases and review on the
90   job done.  The userspace-side reviewer should also provide an Acked-by on the
92   sufficiently documented and validated for userspace's consumption.
94 - The userspace patches must be against the canonical upstream, not some vendor
100   userspace patches land. uAPI always flows from the kernel, doing things the
107 Linux kernel's guarantee to keep existing userspace running for 10+ years this
123 userspace. With KMS, the control node was introduced. However, the
179 possible and userspace must be given the chance to handle it if it wants
182 graphics stack: from kernel and userspace drivers, through display
189 In other words, from userspace perspective everything needs to keep on
190 working more or less, until userspace stops using the disappeared DRM
196 Only after userspace has closed all relevant DRM device and dmabuf file
219 - Pending non-blocking KMS operations deliver the DRM events userspace
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
265 This applies to both userspace mmap()'d memory and memory pointed to by
269 Raising SIGBUS is not an option, because userspace cannot realistically
325         DRM drivers assume that userspace restarts all IOCTLs. Any DRM IOCTL can
355 Testing Requirements for userspace API
358 New cross-driver userspace interface extensions, like new IOCTL, new KMS