[PATCH xorgproto 1/2] randr: Add Leases. [v4]

Keith Packard keithp at keithp.com
Mon Feb 5 23:51:42 UTC 2018

Adam Jackson <ajax at nwnk.net> 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

>> +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.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 832 bytes
Desc: not available
URL: <https://lists.x.org/archives/xorg-devel/attachments/20180205/d6a800bd/attachment.sig>

More information about the xorg-devel mailing list