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

[Keith Packard]

Mario Kleiner <mario.kleiner.de at gmail.com> writes:

> as input from a highly interested future user of such api's:

Thanks much for taking a look at this.

> 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.

The new APIs can give you exclusive access to the display resources,
bypassing the window system entirely.

> 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.

You're still depending on the window system server for timely page flips
though; the main reason we're doing the leasing work is to get that
variable out of the equation, eliminating any window system scheduling
jitter from the regular screen updates on the HMD.

> The RRCreateLease requests looks as if i could get that for regular 
> non-HMD video outputs as well?

Yes, there's almost no way we could restrict it even if we wanted
to. I'm doing testing with two standard monitors, but any hardware at
all will work.

> 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?

Yes, just to avoid having the desktop extend itself onto the HMD, even
briefly. The two components of the RandR changes are logically separate,
but should be useful in combination when using HMD displays.

> 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.

You have the full KMS api at your disposal; do whatever you like :-)

> 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.

Right, that's another benefit here -- allowing HMD applications to be largely
window system independent, except for acquiring the initial lease.

> Basically my vote to expose as much flexility in modesetting / 
> properties for the exposed leases as possible on the kernel and X
> side.

I'll have a second cut of the kernel API changes ready in another day or
so; that will eliminate the ability to change an existing lease, so
you'll have to acquire all of the resources you need all at
once. Otherwise, it will look quite similar at the user API level.

The RandR protocol changes will also need another spin; it sounds like
we want to configure the set of 'special' monitors and have those never
reported as connected via the current API. I don't think that will
affect your use case at all, and the other part of the protocol for
creating a lease won't change.

-- 
-keith
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 832 bytes
Desc: not available
URL: <https://lists.x.org/archives/xorg-devel/attachments/20170410/825e3beb/attachment.sig>