On Mon, 2018-02-05 at 12:39 -0800, Keith Packard wrote: > randrproto.pc.in | 2 +-
Please be sure to bump the pc version in meson.build too. (If there's a more convenient way to only bump things once, great, let's do that instead.) > +7.6. Extension Requests added in version 1.6 of the extension. > + > +┌─── > + RRCreateLease > + window : WINDOW > + lid: LEASE > + crtcs: LISTofCRTC > + outputs: LISTofOUTPUT > + ▶ > + nfd: CARD8 > + lease: FD > +└─── > + Errors: IdChoice, Window, Access, Value, CRTC, Output > + > + Creates a new Lease called 'lid' for the specified crtcs and > + outputs from the screen defined by 'window'. Returns a KMS/DRM > + file descriptor which can control the leased objects directly > + through the kernel. While leased, all resources will appear to > + be 'useless' to clients other than the leasing client as > + follows: > + > + • Crtcs are reported as having no 'possible-outputs' and all > + other values reported as if the crtc were disabled. > + > + • Outputs are reported as having no crtcs they can be > + connected to, no clones they can share a crtc with, will > + report a connection status of Disconnected, and will show > + the current crtc as if it were disabled. > + > + The lease remains in effect until the file descriptor is > + closed, even if the client holding the lease disconnects from > + the X server. > + > + Returns an Access error if any of the named resources are > + already leased to another client. This should throw something if it's not possible to pass fds to the client (presumably because it's non-local). BadAccess or BadMatch seem like good ideas. Also I'm a little nervous about just returning a file descriptor without any way to describe what kind of operations you can do with it; if we ever develop an output setup API we hate less than KMS we'll have painted ourselves into a corner. Should this fd come with an atom naming an ioctl protocol? Should we apply that atom to the crtc[s] as well so the client can know the protocol in advance? - ajax _______________________________________________ xorg-devel@lists.x.org: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: https://lists.x.org/mailman/listinfo/xorg-devel
