From mboxrd@z Thu Jan 1 00:00:00 1970 From: Keith Packard Subject: Re: Proposal for RandR version 1.6, Leases and EDID-based output grabs Date: Mon, 10 Apr 2017 12:11:51 -0600 Message-ID: <86zifow2s8.fsf@hiro.keithp.com> References: <86fuhrka4t.fsf@hiro.keithp.com> <20170402154302.zd7nmqf7vtcvgssu@phenom.ffwll.local> <86y3viinti.fsf@hiro.keithp.com> <20170403074528.c7vwoi3mg7yeojdr@phenom.ffwll.local> <86d1ctigu9.fsf@hiro.keithp.com> <20170403220749.5ujhdzuy6dnikwry@phenom.ffwll.local> <86h925gl6u.fsf@hiro.keithp.com> <20170404070242.rphtgg4yopek2sf7@phenom.ffwll.local> <867f30gody.fsf@hiro.keithp.com> <20170404155923.wllkgop2fyj7wydt@phenom.ffwll.local> <864ly4glvd.fsf@hiro.keithp.com> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="===============0174714640==" Return-path: In-Reply-To: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dri-devel-bounces@lists.freedesktop.org Sender: "dri-devel" To: Mario Kleiner , Daniel Vetter Cc: xorg-devel@lists.freedesktop.org, dri-devel@lists.freedesktop.org List-Id: dri-devel@lists.freedesktop.org --===============0174714640== Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha256; protocol="application/pgp-signature" --=-=-= Content-Type: text/plain Content-Transfer-Encoding: quoted-printable Mario Kleiner 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=20 > exclusive mode and want as little interference from the windowing system= =20 > / desktop environment as possible, with as much low level control as=20 > possible. It still needs windowed mode for same cases and needs a=20 > 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=20 > me page flipping for single display monoscopic stimulation and=20 > dual-display stereoscopic stuff. And then there's the popular "Regular=20 > desktop GUI for interaction" + separate displays for "fullscreen + page=20 > 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=20 > 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=20 > plugging HMD's or other special purpose devices, but wouldn't be=20 > 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= =20 > if i could have control over framebuffer formats, e.g., being able to=20 > select 10 bit scanout formats would be very useful, but is afaik=20 > something that X currently doesn't expose with most drivers, especially=20 > 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= =20 > would gain similar extensions to lease outputs for fullscreen exclusive=20 > control, i could have one drm/kms backend that can be mostly agnostic of= =20 > X vs. Wayland / different Wayland compositor flavors. Right, that's another benefit here -- allowing HMD applications to be large= ly window system independent, except for acquiring the initial lease. > Basically my vote to expose as much flexility in modesetting /=20 > 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. =2D-=20 =2Dkeith --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAEBCAAdFiEEw4O3eCVWE9/bQJ2R2yIaaQAAABEFAljryucACgkQ2yIaaQAA ABE0eA//aAU1/TBvvJcHXQDRNux0SsUnQqSxwsjSfmkbVy7l0GbmsJ5irPqdKf8i PeiSfcpdlthhUPWVlnmkaK6bx53zdHuSheKduvJng9XoFbZipmXWW8wJM1KH5sOg dBhRP8ha8Znb8dye/rupHU3n7TbrNsQmtv1JbosS1hLt1EbzZTLlHQ1/ibDjcq6K feNfitjMc4lILDhNuHDXc17U1/ozhm/ojxWQE+EWt5avTJ4386L9ZwK7uvgovDzQ MZE+V7b8yO4T9ZgbNElCkMfuRCB5r+O+Z0Uibwjvd1QzugPig47ZxawGMgZUU20Q eODl1oTFMgID06DAkXlTFFEJi/cn/AgeTy8YFwX/29SkyrUCP+nJs3oktVJXy34M xy2lurFRkk2esGS0jmFnLYvCCEdd0wIE5H8mRknPtcjBzRl9+FFQuEmg1OrqPByg wBQ9gLXI1KlDN/2DqzFd1F/cnQ2lTnoWaQITWaModflqeofFaXlXtgziafU0w4K7 kH8NeM5JF+wKTfcUB+eGu1gAXL9p7KUl3UxtfDml+yH4SkBFMfCkoQxswA8rEkpt M8vIoRu8h2FdH9kiFF0dTEAu76gg1oqvjnpNQi1mBkp+YlVt2s/8agsp6k9Hc2TP 0rvBwfd0s8jnbDmjUnep6DogMFm8gRT6Dxp/c34G7HSr6uXuk5A= =IGkg -----END PGP SIGNATURE----- --=-=-=-- --===============0174714640== Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: base64 Content-Disposition: inline X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18KZHJpLWRldmVs IG1haWxpbmcgbGlzdApkcmktZGV2ZWxAbGlzdHMuZnJlZWRlc2t0b3Aub3JnCmh0dHBzOi8vbGlz dHMuZnJlZWRlc2t0b3Aub3JnL21haWxtYW4vbGlzdGluZm8vZHJpLWRldmVsCg== --===============0174714640==--