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

[Keith Packard]

Pekka Paalanen <ppaalanen at gmail.com> writes:

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

Well, it's more out of a sense of fear than future planning. If all we
ever use it for is as a list of monitors that the desktop should ignore,
that'd be fine.

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

I don't think so. Presumably the VR system will have a known list of
HMDs it works with, and so it will probably have a list of EDID
information; I expect that's where the data for monitors-to-ignore will
come from in many cases. After all, the goal is to prevent the desktop
From shifting onto a display only to get kicked off as the VR app takes
over the HMD.

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

Yeah, one can imagine an application designed to manage that. One can
also imagine having an additional database which the desktop itself
would read on behalf of the user; I'd hate to have the user directly
providing data for the window system server...

> I think your idea is the better one.

Thanks, it seems simpler and more predictable to me as well.

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

All that the database needs to do today is to hide entries from the
desktop; with that, the VR app can go find the monitors and hook them up
without needing additional data.

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

I think all we'd do is offer a new RandR request which listed "all"
monitors, including those hidden from the desktop, and expect that the
monitor-specific applications would use that to detect the presence of
their magic outputs and use them. For an HMD, you'll also have other
devices connected, so we just need some way of positively associating
the various input devices with the specific monitor (in case there is
more than one).

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

I don't think the window system needs to know that the displays are HMD,
only that it shouldn't present them as part of the desktop. Everything
else about them can be left outside of this spec.

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

Sounds like it might be worth exploring how those work, and whether we
might want to provide some additional RandR protocol to make a specific
monitor 'visible' so that the desktop would extend onto it with a
command from a client. I think we can safely ignore this for now and
plan on coming up with a solution that extends on this basic work.

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

Hard to imagine this being relevant for the Linux desktop at least...

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

Seems like a safe assumption. Once you install a VR app and the
associated 'ignore this monitor' files for the window system, I'd expect
that to be the primary use case.

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.

-- 
-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/20170504/d042bdfc/attachment.sig>