[PATCH] Add NonDesktop output property and behaviors.

[Keith Packard]

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

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?

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

-- 
-keith
-------------- 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/20171020/40a06475/attachment.sig>