Lines Matching refs:userspace

7 addition, drivers export device-specific interfaces for use by userspace
42 what the userspace side for new uAPI needs to look like. This section here
46 open-sourced userspace patches, and those patches must be reviewed and ready for
50 hardware, with userspace and kernel by necessity having to work together really
54 infeasible to differentiate between behaviour that's required by userspace, and
58 Without access to the full source code of all userspace users that means it
59 becomes impossible to change the implementation details, since userspace could
65   open-source userspace of the DRM subsystem. DRM developers are perfectly fine
66   if closed-source blob drivers in userspace use the same uAPI as the open
71 - Any new userspace interface must have an open-source implementation as
74 The other reason for requiring open-source userspace is uAPI review. Since the
75 kernel and userspace parts of a GFX stack must work together so closely, code
80 - The open-source userspace must not be a toy/test application, but the real
85 - The userspace side must be fully reviewed and tested to the standards of that
86   userspace project. For e.g. mesa this means piglit testcases and review on the
90 - The userspace patches must be against the canonical upstream, not some vendor
95   but it **must** be merged **before** the userspace patches land. uAPI always flows
103 Linux kernel's guarantee to keep existing userspace running for 10+ years this
119 userspace. With KMS, the control node was introduced. However, the
208         DRM drivers assume that userspace restarts all IOCTLs. Any DRM IOCTL can