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

Sat May 6 11:34:44 UTC 2017

On 05/05/2017 04:25 PM, Keith Packard wrote:
> 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.
>

Just please make sure that one (user configurable/opt-in if necessary) 
policy from the beginning is to allow leasing out any output to 
applications, not just HMDs. My type of scientific/medical applications 
would benefit as soon as it has the option to get a drm lease for a 
given output on both X and Wayland based systems. That's not a 
theoretical future use case, but one i'd try to offer to my users as 
soon as a stable protocol/implementation is available in a regular Linux 
distribution. It wouldn't be fun for inexperienced users if they had to 
hack the database for every model of display they want to use, or if 
every untrusted user would have to have a root password to do so.

thanks,
-mario

>
>
> _______________________________________________
> dri-devel mailing list
> dri-devel at lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel
>