Re: Proposal for RandR version 1.6, Leases and EDID-based output grabs

[Keith Packard <keithp@keithp.com>]

[-- Attachment #1.1: Type: text/plain, Size: 2247 bytes --]

Alex Deucher <alexdeucher@gmail.com> writes:

> I think there is a definite use case there.

I agree. What we're missing right now is someone interested in driving
an implementation of that use case to help define the right
interfaces. Lacking that, we're not likely to come up with a good
solution on our own. I think that's what Daniel is concerned about --
specifying something in the absence of an implementation using it.

I took a stab at this and added the ability to change leases on the fly,
and to create 'sub-leases' from an existing lease. He's pushing back on
those features, and I think his reasons are sound.

> Why do we need to make X aware of the lease stuff? What about having
> some pre-X configuration that decides how to split up the display
> resources.

For multi-user, this makes a lot of sense; you'd want the system to
allocate resources between users to allow them to operate fairly
independently.

For single-user with a hot-plugged HMD, I'd suggest that having X
involved makes a lot of sense -- you may have to interact with the user
to reduce resource consumption so that the HMD can be driven
successfully, and that will involve poking at the X configuration.

> It could be user defined static or dynamic based on what is attached.
> You can just start X on the device nodes with whatever resources they
> are assigned.  In the multi-user case, you can statically assign
> resources to each node; in the VR case, you can detect the HMD and
> automatically assign it's resources to a separate node or override if
> necessary.

I don't think we've precluded this for a multi-user environment, and I
think it's a good plan in the abstract.

I will, however, suggest that asking for VR applications to wait for the
desktop environment to be re-architected so that display resources can
be centrally allocated by a new 'display resource manager' seems like a
rather steep requirement.

What I do want to ensure is that these two use cases can both be
supported by the kernel interfaces we define, and that we can work in
user space on either design going forward.

If you'd like to start exploring the design of such a central service,
that'd be awesome.

-- 
-keith

[-- Attachment #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 832 bytes --]

[-- Attachment #2: Type: text/plain, Size: 160 bytes --]

_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel