On 04/10/2017 08:11 PM, Keith Packard wrote:
Mario Kleiner <mario.kleiner.de@xxxxxxxxx> 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@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
_______________________________________________
dri-devel mailing list
dri-devel@xxxxxxxxxxxxxxxxxxxxx
https://lists.freedesktop.org/mailman/listinfo/dri-devel
