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 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
signature.asc
Description: PGP signature
_______________________________________________ [email protected]: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: https://lists.x.org/mailman/listinfo/xorg-devel
