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

[Pekka Paalanen]

On Wed, 03 May 2017 19:04:38 -0700
Keith Packard <keithp at keithp.com> wrote:

> Pekka Paalanen <ppaalanen at gmail.com> writes:
> 
> > do you mean to list all kinds of display devices in the database? I was
> > assuming it would list only HMDs, so not in database would imply it's a
> > normal display and good for extending the desktop to.  
> 
> I intended for it to be a general database to which we could add almost
> anything; you can imagine using this to replace broken EDID values,
> configure alternate preferred modes or whatever.

Ooh, a much much larger scope than I assumed. Nice.

That means you need an explicit key to denote HMDs. More below.

We could probably use it to recognize projectors and such, too.... which
makes me think that there should probably be an easy way to add more
entries: you plug in a projector, it's not recognized as such, you tell
your DE it is a projector, the DE goes and saves the match in the
database. Should be pretty easy with the directory full of files
approach you had in mind, if there just is write access.

> The 'desktop' boolean says whether the desktop should be expected to use
> the device or not; that's all I need for the HMD case.
> 
> > Or did you mean it for exceptions? As in, define a range of HMDs, but
> > the vendor put a few normal displays in the middle of the range, so one
> > needs to be able to exclude those?  
> 
> Oh, that's a great thought; I hadn't considered what we would do with
> conflicting entries that mapped the same device. I'd like to make that
> invalid, and potentially spit out a warning message somewhere...

I'm not sure... disfavouring overlapping entries at least would save us
from inventing heuristics on which one of the overlapping entries
should be picked for a device. And if those heuristics would need to be
implemented in each display server, more room for inconsistent
behaviour.

I think your idea is the better one.

> > The reason I mentioned "virtual 2D display" was that I recall hearing
> > that actually exists in some HMD hardware. If you don't do anything to
> > enable a 3D mode, the HMD will process the signal to produce a virtual
> > 2D display in front the user. In such case, there is no need for a VR
> > compositor, the plain old 2D image signal will be shown correctly on a
> > plane in the virtual space by the HMD hardware itself.  
> 
> Oh, cool! That doesn't help as it means the user will want to pick if
> this happens or not. Maybe just don't include it in the database and let
> the VR application turn off the X output before creating a lease?

Or, list it in the database as both "desktop" and "HMD" for the same
effect?

That way the desktop would extend there automatically, but it would
also be advertised as a HMD to clients. If it's not listed at all,
would it be possible to advertise it as a HMD and DRM-leased out etc.?

At least for Wayland, I'd like to not advertise "everything" as
possible HMDs but only those that really are.

> > Mind the note towards the bottom: you don't actually need a PS4 to use
> > it - so it must be something built into the HMD. However, reading more
> > details from
> > https://blog.us.playstation.com/2016/10/03/playstation-vr-the-ultimate-faq/
> > reveals that there is actually a separate processor box providing the
> > cinematic mode. Sounds like it's your VR compositor as a middle-man
> > hardware device rather than just a program. :-)  
> 
> Interesting. I guess it's a way to make it work without hacking the
> desktop environment at all?

It seems it should be capable of displaying the desktop out of the box,
but I don't think there is a separate HDMI-in for actual VR content, so
you'd still need to cooperate with the display server to turn it to
VR mode and feed the VR video stream.

I also read some discussions about 3D TV modes, but couldn't really get
a conclusion if they are supposed to render like if you were in a 3D
cinema theatre or not. Apparently that was enabled in a firmware
upgrade and maybe had some extra requirements.

I would guess the real purpose behind the cinematic mode is to get more
content workable on the HMD earlier, as it allows you to play almost
all existing games and movies that were not made for VR/HMD to begin
with.

> Thanks for your suggestions; I hope we're getting closer to some kind of
> prototype at least...
> 

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/20170504/892f85ff/attachment-0001.sig>