Pekka Paalanen <ppaala...@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.
