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

[Keith Packard]

Pekka Paalanen <ppaalanen at gmail.com> writes:

> I disagree on the details, more below.

> Such a RandR request is something I would not like to have to replicate
> on Wayland. The display server contains the policy, it should not just
> expose everything up for grabs. This is a fundamental difference
> between X11 and Wayland architectures, and I think the output
> information database should support both ways.

Sounds like a good idea; if you want to work on how this should appear
in Wayland, that would be great as it would provide two implementations,
rather than just one.

> I disagree. Wayland will likely have a special protocol extension
> exclusively for advertising HMDs, so the display server will need to
> know which ones are HMDs and which one are not, regardless whether the
> desktop is extended there or not. This extension could also offer the
> DRM leasing capabilities.

What I was thinking that a display which the window system cannot drive
natively should probably just be ignored entirely. An HMD which can
natively handle a desktop (such as the PSVR system) might well be
advertised as 'desktop capable', even though it is an HMD.

However, I also think you're right -- while the window system can't deal
with it *today*, that doesn't mean the window system won't be able to do
that in the future.

Hrm. I think the important distinction here is that the user installed
an application which is designed to talk directly to this display. From
that, we should probably infer that the user would like to use that
application with the display.

> Having the window manager know what is a HMD and which client is active
> on it will let it make better management decisions and even allow
> switching between VR apps, or temporarily switching from VR app to the
> desktop when supported, and back.

The window system will know when outputs are leased to another client,
so it can tell when to bring them back to the desktop. In the PSVR
instance, you'd list the device as 'desktop', but still allow
leasing. When no lease was active, the desktop could extend into the
PSVR environment. When the custom application started, it would request
a lease at which time the desktop would move off of the PSVR.

>> Thanks again; I'm sensing that a simple 'ignore this monitor for the
>> desktop' might suffice for now, but that we'll end up wanting something
>> more complicated in the future. I think the key is to try and avoid
>> making that harder by what we do now, but I don't think we should be
>> trying to implement a larger solution too soon.
>
> Yes, that I agree with.

I guess that's the question -- is a simple command to ignore a monitor
for purposes of the desktop sufficient for now? Or do we need to worry
about a possible future in which the window system implements native HMD
support?

> Ultimately I would envision an output device database describing
> what kind of a device it is (a normal monitor, a video projector, a
> HMD, a TV, ...) and then the software that implements the desktop or UI
> policy will decide how that will be used. Some policy examples:
>
> - A projector: do not extend desktop UI, but have the output normally
>   available, so one can put regular windows there (presentation
>   software). Turned on by default.
>
> - A HMD: Do not extend desktop, do not expose to normal apps, keep it
>   off until special request.
>
> - A HMD with cinematic mode support: Extend desktop, turn on by
>   default, allow special HMD requests.
>
> - A TV: Try to disable overscan or try to compensate for it by
> default.

Those all sound useful. I wonder how much we might be able to guess from
EDID info and whether we want to programmatically do some of this
(especially the TV thing; that's really annoying :-). In any case, a
problem for the future.

> I would suggest to have a "output device type" attribute in the
> database, and support only one value for now: "HMD". Then all display
> servers can encode the policy to hide all HMDs by default.
> Implementationwise it is no different from your idea, but separating
> device description from usage policy would be a good thing in my
> opinion. You can still document suggested policies in the spec if you
> wish, only the wording will be more of a recommendation than a
> requirement.

The only issue here is that now we're encoding policy in code, which is
hard to change for the average user, rather than in a configuration
file, which is easy to change. However, as we've defined it, these files
are installed by the system and it would be nice if they weren't
expected to be overridden by the user, so encoding policy there is
almost worse than in the code.

Hrm. How about we adopt your design and encode the device type in the
file, provide a fixed policy in the window system for now and consider
the possibility of changing the window system in the future to support
more advanced policy mechanisms. I don't think that shuts any doors
permanently.

-- 
-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/20170505/92c91867/attachment.sig>