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

Mon May 8 10:47:55 UTC 2017

On Fri, 05 May 2017 07:25:14 -0700
Keith Packard <keithp at keithp.com> 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.

Hi Keith,

I would want to, but unfortunately I have barely enough time for
this fly-by commenting currently. However, I do have a fairly clear
idea of how all this talked about so far would be implemented in a
Wayland server, except for potential window management issues in case a
VR app connects both directly for a normal window and via a VR
compositor.

I forget if I mentioned this to you personally yet:
https://gist.github.com/ppaalanen/e0d2744ff71188e9a294726a37ca83c2

I wrote that before I knew about your DRM leasing work, which means
it is well outdated. The biggest difference is that instead of
flipping through the Wayland compositor, one would use DRM leases.

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

Right.

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

I believe my proposal at the end of the email solves this question
both ways.

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

Indeed for the future. In the worst case, users will need to match
their devices by serial number or some other individual way one by
one.

Thinking again, I believe we have to have a way to override
database entries somehow. If we ship catch-all entries for, say,
all Sony TVs, we are bound to get some assignment wrong for
someone who then wants to make a correction without breaking
everyone else.

We are moving away from configuring outputs in a display server by the
connector name and towards configuring outputs based the actual output
device identity and type.

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

That sounds perfect and future-proof to me.

I would like the output database to strictly describe the hardware, not
set up any policy or usage patterns. It would be something like udev
rules adding tags that you can then use in the display server
configuration for matching, except for outputs which cannot be handled
by udev.

I believe we should not have the user poke around in the output device
database unless he has a piece of equipment that is either not
recognized at all or is recognized or tagged wrong. Seems we are in
agreement here.

The policy to deal with output categories and individual outputs would
be in the display server configuration. Something like:

Section "OutputClass"
	...

	MatchType "HMD"
	Option "HideFromRandR" "true"
	Option "DPMS" "off"
EndSection

Heh, I wasn't even aware there actually was OutputClass already, with
only MatchDriver. Wouldn't that be a good fit for static policy
configuration in Xorg?

Thanks,
pq
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 833 bytes
Desc: OpenPGP digital signature
URL: <https://lists.x.org/archives/xorg-devel/attachments/20170508/8797fa79/attachment-0001.sig>