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. > 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
Attachment:
signature.asc
Description: PGP signature
_______________________________________________ dri-devel mailing list dri-devel@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/dri-devel
