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

[Mario Kleiner]

On 04/10/2017 08:11 PM, Keith Packard wrote:
> 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.
>

Yes, and that will be an advantage for me as well, especially for some 
more exotic situations. That said, in my experience good old X is 
holding up rather well for page-flipped windows if one gets unredirected 
fullscreen with no DE interference. I have users which runs a 
1920x1080 at 240 Hz display at 240 fps stable update rates without skipping 
frames and proper frame accurate timing on AMD gfx with the open-source 
graphics stack on a standard Ubuntu 16.04 + Server 1.18 :)
In fact, it still beats current standard Wayland compositors by a large 
margin, mostly due to how display update scheduling is done in the 
current incarnations and because Wayland doesn't have a full DRI/Present 
or OML_sync_control equivalent yet.

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

Great! Haven't looked at your patches yet, only at this thread and your 
blog, but this sounds all very promising.

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

Yes, sounds like i could deal with that.
-mario