On 04/04/2017 06:48 PM, Keith Packard wrote:
Daniel Vetter <daniel@xxxxxxxx> writes:
Yeah I think that's a pretty neat idea to reduce the lease complexity even
more. If the VR compositor is unhappy and wants a different mode, it can
simply nuke the lease and as for a new one. Forgot to say that :-)
Not sure it changes the lease complexity, but it reduces the potential
interference with the X server after the lease is created.
Hrm. Thinking about the impact on X a bit more, this seems hard - you
can't just display the root window in the HMD, so you need a frame
buffer to use. The VR compositor can construct this knowing the planned
X mode, but, we then have to wire it through the whole X mode set
infrastructure, which is not exactly set up to do that.
I'll go look at the code in more detail, but I suspect the easiest
plan will be to have the VR compositor set its own mode. That may fail
if X is consuming too many display resources, but that doesn't seem
significantly different from having the lease fail.
This doesn't change the kernel API at all, so we can figure out the X
bits separately from the kernel bits.
Hi,
as input from a highly interested future user of such api's:
An additional use case beyond VR compositors, at least highly valuable
for my kind of apps (= neuroscience / vision science / medical research
toolkits) would be to get fullscreen exclusive control over regular
outputs / displays. My use cases run about 98% of the time in fullscreen
exclusive mode and want as little interference from the windowing system
/ desktop environment as possible, with as much low level control as
possible. It still needs windowed mode for same cases and needs a
windowing system up and running.
Atm. under X i have to hope that fullscreen unredirection works to get
me page flipping for single display monoscopic stimulation and
dual-display stereoscopic stuff. And then there's the popular "Regular
desktop GUI for interaction" + separate displays for "fullscreen + page
flipping for controlled presentation" case.
Atm. i have to use custom xorg.confs + dual/multi-x-screen +
ZaphodHeads, a static configuration with all the logout/login dance / no
display hotplug for configuration change. Workable under X (minus the
occasional ZaphodHeads corner case bugs), but somewhat clunky.
So if this would give me a plug & play dynamic replacement for
ZaphodHeads and xorg.conf fiddling that would be _very_ valuable.
The RRCreateLease requests looks as if i could get that for regular
non-HMD video outputs as well?
And the RRCreateOutputGrab would be mostly to avoid flicker when
plugging HMD's or other special purpose devices, but wouldn't be
strictly needed for a regular X-client to get a lease on a set of outputs?
As far as controllable properties on a lease go, i'd find it very useful
if i could have control over framebuffer formats, e.g., being able to
select 10 bit scanout formats would be very useful, but is afaik
something that X currently doesn't expose with most drivers, especially
not for regular desktop mode.
Set/Get Gamma tables, dithering properties, other output properties,
modesetting would be also important. On X i can do that via RandR, but
in the Wayland world, much of this stuff is afaik often restricted to
privileged clients or proprietary per-compositor protocols. That's a big
upcoming problem for me in the Wayland world, and lease support could be
a very good solution for me.
If the underlying DRM leases allow me to control this stuff, and Wayland
would gain similar extensions to lease outputs for fullscreen exclusive
control, i could have one drm/kms backend that can be mostly agnostic of
X vs. Wayland / different Wayland compositor flavors.
Basically my vote to expose as much flexility in modesetting /
properties for the exposed leases as possible on the kernel and X side.
thanks,
-mario
_______________________________________________
xorg-devel@xxxxxxxxxxx: X.Org development
Archives: http://lists.x.org/archives/xorg-devel
Info: https://lists.x.org/mailman/listinfo/xorg-devel
_______________________________________________
dri-devel mailing list
dri-devel@xxxxxxxxxxxxxxxxxxxxx
https://lists.freedesktop.org/mailman/listinfo/dri-devel
