Adam Jackson <[email protected]> writes: > 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.)
Thanks, I didn't catch that. Annoying that this version is in two places... >> +7.6. Extension Requests added in version 1.6 of the extension. >> + >> +┌─── >> + RRCreateLease > 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. It returns BadAlloc, just like ShmCreateSegment does. That seems like a inappropriate error to return, although I'm not sure the precise error code actually matters? > 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. Well, Linux ain't going to be changing the interface on /dev/dri/card* anytime soon; existing applications will have to continue to work. > 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? I'd suggest that we burn that bridge when we come to it. If the old DRM interface isn't available at all, this call can certainly fail. If we do create a new kernel interface, we'll have to update the kernel, X server and clients to use it, so I don't see a lot of use in having this interface usable with a new interface. -- -keith
signature.asc
Description: PGP signature
_______________________________________________ [email protected]: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: https://lists.x.org/mailman/listinfo/xorg-devel
