Pekka Paalanen <ppaalanen@xxxxxxxxx> 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
Attachment:
signature.asc
Description: PGP signature
_______________________________________________ dri-devel mailing list dri-devel@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/dri-devel
