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

[Alex Deucher <alexdeucher-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>]

On Tue, Apr 4, 2017 at 3:02 AM, Daniel Vetter <daniel@ffwll.ch> wrote:
> On Mon, Apr 03, 2017 at 03:50:33PM -0700, Keith Packard wrote:
>> Daniel Vetter <daniel@ffwll.ch> writes:
>>
>> > Also if this confuses VR, then another reason why we want to make leases
>> > invariant and only allow pure revoke, not changing the list.
>>
>> I'm not sure why you want this to be asymmetrical, nor why you would
>> expect lessees to be any more competent at dealing with hotplug than the
>> lessor.
>>
>> One use case already proposed for this API was to allow for multi-seat,
>> where the lessee would be an existing window system, which we already
>> accept as being incompetent at dealing with resource hotplug. I imagine
>> that in this case, a newly plugged monitor would be detected by the
>> multi-seat manager (logind?) and added to one of the existing leases,
>> along with a suitable CRTC resource. For this to work, the lessee will
>> need to already know about those resources and only have their
>> connectivity status hidden.
>
> The multi-seat thing sounds like vapourware, I think we should care about
> the vr use-case for now, and only that one. And for that restricting stuff
> is perfectly fine. Of course we can design the entire thing in a way that
> doesn't draw us into a corner in the future right away, but that's mostly
> on the implementation side. For VR itself I'd go as far as saying that
> probably our "create lease" ioctl should have only the semantics we need
> to pass one crtc+primary plane for pageflipping in a VR compositor,
> expressed in a flag. All the details about additional corner cases are
> just so unclear to me (and there's not even a clear use case that will
> materialize) that I don't think having the uapi is worth it. Too close to
> the "I'll regret this immediately" bucket :-)
>

I don't know about vaprware.  There were a number of attempts to
provide static allocation if display resources over the years to solve
things like custom zaphod configs and users wanting to use multiple
heads for separate users (which currently ends up in various zephyr
hacks IRC).  Lots of patches were proposed, none landed.  I think
there is a definite use case there.  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.  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.

Alex
_______________________________________________
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