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 <[email protected]> writes:
I think this makes sense. Comments below.
Reviewed-by: Aaron Plattner <[email protected]>
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.
_______________________________________________
[email protected]: X.Org development
Archives: http://lists.x.org/archives/xorg-devel
Info: https://lists.x.org/mailman/listinfo/xorg-devel
