[PATCH] Add NonDesktop output property and behaviors.

[Aaron Plattner]

Sorry for the extremely slow reply. I started writing this and then 
forgot about it when I went on vacation. I've been out of the loop since 
I got back so I apologize if the discussion has moved on and the 
responses below are stale.

On 10/20/2017 12:53 PM, Keith Packard wrote:
> Aaron Plattner <aplattner at nvidia.com> writes:
> 
>> I think this makes sense. Comments below.
>>
>> Reviewed-by: Aaron Plattner <aplattner at nvidia.com>
> 
> Thanks, Aaron. Have you also looked at the leasing changes on the same
> branch? I'd like to know what you think of that plan for implementing
> the Vulkan acquire Xlib display extension. I've got code which uses it,
> but I'd like to know if that's something you might also be able to
> implement in your environment. With those two pieces, I'd be able to
> finish version 1.6.

I didn't look at it in a lot of detail, but the plan sounds mostly
alright to me, although I'm concerned about which pieces applications
are going to try to use directly.

The big issue for us is that we have to support systems that don't have
DRM or this new RandR interface. We have a permission model similar to
DRM leases, and use NV-GLX to pass the relevant file descriptors to the
client. The Vulkan interface is layered on top of that.

I'd hoped that the RandR-based protocol for getting DRM lease file
descriptors would likewise be an implementation detail opaque to Vulkan
clients. As long as we're treating them that way, the changes to the
Vulkan API sounded okay to me, but James and Damien are the experts there.


For actually supporting the DRM lease / RandR interface:

Our nvidia-modeset.ko has the concept of a "modeset owner" that's pretty
similar to DRM's master concept. When nvidia-drm.ko is loaded with the
"modeset=1" parameter, the DRM master becomes the nvidia-modeset owner
and all of DRM's normal permission model should apply. However, our X
driver currently closes the DRM master fd if we get one and talks to
nvidia-modeset directly. I don't know if we'll be able to handle DRM
leasing and nvidia-modeset permissions at the same time with our X
driver -- we would need to wrap nvidia-modeset permission tokens in DRM 
lease file descriptors somehow.

>> I don't think a separate NonDesktop connection state property is
>> needed.  I agree that you can infer that from the presence of an EDID
>> and modes.
> 
> To take the other side of this argument, in reviewing the contents of an
> RRGetOutputInfo reply, I don't think any of those values are 100%
> reliable in telling whether something is connected or not. You can
> create and assign modes to a disconnected output, and there are no
> properties guaranteed to be set.

Hmm, I suppose clients can create and write to the EDID property as
well. But if you manually write modes and an HMD EDID property to an
output, it seems reasonable to me for a desktop environment to treat it
as one. That actually seems like a good way to test this infrastructure
without needing to have a real HMD attached.

> Of course, it's rare these days for people to create their own modes and
> assign them. We still have many cases where monitors fail to provide
> EDID data, and I wonder if that won't be more common for some things
> that we do want to hide from the normal desktop? Hrm. Now I'm thinking
> that just having a property which gets set wouldn't be a terrible plan.
> 
> Thoughts?

How would the driver know to set NonDesktop without an EDID? Some kind
of devicetree entry or platform-specific hardcode? Without a specific
example of such a device this feels like overengineering to me, but I'm
not opposed to adding the extra property if it's just a boolean.

-- Aaron

>> Add a period at the end of this sentence (and a couple below), maybe?
> 
> Thanks, just a cut&paste error.
> 
>> Giuseppe, I'm not sure I understand your suggestion about "attached" and 
>> "detached" modes here. I.e. what exactly would a driver do in response 
>> to a client writing this property? If you just want to switch between 
>> being part of the desktop and not, you can do that by attaching or 
>> detaching it from a crtc.
> 
> I think the goal was to have it controlled through the X server, but not
> play a part of the larger desktop.
> 
>> The motivation here is that a client would use this output through some 
>> other non-X API. Specifically Vulkan direct-to-display for virtual 
>> reality. So X wouldn't be configured to drive this output with a crtc. 
>> Instead, it would lease the output and a crtc to the client for its 
>> direct use.
> 
> That's certainly our current motivation; we need to be careful to not
> design-out other possible uses, while at the same time not
> over-designing the solution. Nothing in this proposal makes it
> impossible for an application to use X to drive this extra output, it's
> just not the motivation at present.
> 
> And, I agree that there's no particular need to write this property to
> get the output to not appear in the desktop; the existing 'Monitor'
> mechanism is sufficient for this.
> 
> Having it writable opens a huge question of how you would revert back to
> device control from user control; we'd have to add *another* boolean
> that would flip the value from 'device controlled' to 'user
> overridden'. And that's more complexity than we should be doing at this
> point; it's pretty obvious to me that we can do this in the future if it
> becomes necessary.
>