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

[Mario Kleiner <mario.kleiner.de-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>]

On 04/04/2017 06:48 PM, Keith Packard wrote:
> Daniel Vetter <daniel@ffwll.ch> 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@lists.x.org: X.Org development
> Archives: http://lists.x.org/archives/xorg-devel
> Info: https://lists.x.org/mailman/listinfo/xorg-devel
>
_______________________________________________
xorg-devel@lists.x.org: X.Org development
Archives: http://lists.x.org/archives/xorg-devel
Info: https://lists.x.org/mailman/listinfo/xorg-devel