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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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




[Index of Archives]     [Linux DRI Users]     [Linux Intel Graphics]     [Linux USB Devel]     [Video for Linux]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]     [XFree86]     [Linux USB Devel]     [Video for Linux]     [Linux Audio Users]     [Linux Kernel]     [Linux SCSI]     [XFree86]
  Powered by Linux