From mboxrd@z Thu Jan 1 00:00:00 1970 From: Dario Faggioli Subject: Re: [Embedded-pv-devel] [PATCH] drmif: add ABI for para-virtual DRM/KMS Date: Thu, 24 Nov 2016 23:14:26 +0100 Message-ID: <1480025666.2712.155.camel@citrix.com> References: <1479987046-7226-1-git-send-email-andr2000@gmail.com> <1479987046-7226-2-git-send-email-andr2000@gmail.com> <492fa128-f60b-16ee-f650-29a05e4d0cbc@arm.com> <583710640200007800121CD1@prv-mh.provo.novell.com> <58371E120200007800121E08@prv-mh.provo.novell.com> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="===============5825101229438842533==" Return-path: In-Reply-To: List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xen.org Sender: "Xen-devel" To: Oleksandr Andrushchenko , Jan Beulich Cc: Lars Kurth , Iurii Konovalenko , xen-devel@lists.xensource.com, Volodymyr Babchuk , Tim Deegan , Oleksandr Dmytryshyn , ian.jackson@eu.citrix.com, =?UTF-8?Q?=D0=93=D1=80=D0=B8=D1=86=D0=BE=D0=B2_?= =?UTF-8?Q?=D0=9E=D0=BB=D0=B5=D0=BA=D1=81=D0=B0=D0=BD=D0=B4=D1=80?= , Andrii Anisov , Oleksandr Tyshchenko , embedded-pv-devel , Julien Grall , David Vrabel , Mygaiev Artem List-Id: xen-devel@lists.xenproject.org --===============5825101229438842533== Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="=-lFumkBchQnLEyAEsPQur" --=-lFumkBchQnLEyAEsPQur Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Thu, 2016-11-24 at 20:31 +0200, Oleksandr Andrushchenko wrote: > > Hmm, I think you want a PV Linux DRM/KMS driver, but that doesn't > > mean you want/need a protocol by that name. The interface has > > to describe virtual hardware, and I don't think you'd call a > > graphics > > card "DRM/KMS card"? > Good point, then I would suggest we name it dspl for display (PV > display), > e.g. vdspl, not vdrm. > What about DISPL / vDISPL, which is a little easier to pronounce, remember, and map back to 'display' (while dspl sounds to me a lot like the name of one of those obscure ACPI tables, or something like that! :-P). Or, if you want it to be consonant only, how about GFX / vGFX, for 'graphics' ('graphix'). Just my 2 cents. > > Hence also the question whether the existing > > fbfront protocol couldn't be extended - after all modern graphics > > (3D) cards have also evolved from simple frame buffer (2D) ones. > >=20 > The proposed protocol is almost totally diferent from what > existing framebuffer offers. So that was the reason to create a > new one which better fits modern graphics and doesn't alter fbif. > What is more, real DRM drivers usually support framebuffer > emulation, so I was thinking of some flexible solution: > 1. If FB is not needed then only DRM/DSPL is in use > 2. If also FB is needed then we use existing protocol > to add this functionality to guest along with DSPL > Nothing tells me that these couldn't be different > back and front drivers/applications for even better flexibility. > FWIW, this seems to me something that could be nice to have. But I'm no expert in this, and I still have to look closely at the patch and at the protocol and fully make up my mind. Regards, Dario --=20 <> (Raistlin Majere) ----------------------------------------------------------------- Dario Faggioli, Ph.D, http://about.me/dario.faggioli Senior Software Engineer, Citrix Systems R&D Ltd., Cambridge (UK) --=-lFumkBchQnLEyAEsPQur Content-Type: application/pgp-signature; name="signature.asc" Content-Description: This is a digitally signed message part Content-Transfer-Encoding: 7bit -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIcBAABCAAGBQJYN2ZCAAoJEBZCeImluHPuImsQANp6dFUbf+RCr7U5lJxEeIN0 Rr89uT/TpfKGRzlSBDSHIHpJqtWG34pD2WzSRFZK0G8ZeLhqgK5uBynavafpL10o 53FkYtfVLYq+HN+eIjIjh3HEp3m/5Qlhx7T51b1/pWS55ZgsZJLwss9hfrG1U2JW uWanhiR5ZqKyiZKPN+uiGatKWbuf+hR5xOEFhJ0AOpB4t2rxW7WwvmGYBSRDJGms RcvbEYLBqEiXo6VdtsZM6BWkXAR5UQ7Z/hetDVPbOT+PqpZDwyV9KAM6RiPiJvOw vhjt3oT32H2IJFxU1tZteg6PTe3QV4CdEGPNtyml9gCtoaGTF1b8SkDXC+YSPXr9 JcHKWI84OoqnzwaezNWnFNQmdVVI+g87PinuHp5lsmJ43wpT7lAeEaiOP0fcOJ67 ILFnYhlhwlo+oSm2qjzEoJWOED2zU6S2TyBX0O5e8mNZK86deFXHhoybc1mSrqVS IEV3QMYhThaTWKI6so1aDX0nQi+BDMvmLdlO2NrMp48dLDrMKvGw8gJz+rbqrRqP UbXzV5ZQ4cfVsmtNcsZ3pKEN46kv1jlMgmUDj502AfPL1A+bPvF5H119N8YnJ9Iy anTNFKoyZY37yuQ/IcF2o8Z/FcILi1+k7BWI4zYxJfbXGHolbw9jJV8MR9Z/b7qN zjPUcSk43vOHBE4hGTsz =9ubs -----END PGP SIGNATURE----- --=-lFumkBchQnLEyAEsPQur-- --===============5825101229438842533== Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: base64 Content-Disposition: inline X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18KWGVuLWRldmVs IG1haWxpbmcgbGlzdApYZW4tZGV2ZWxAbGlzdHMueGVuLm9yZwpodHRwczovL2xpc3RzLnhlbi5v cmcveGVuLWRldmVsCg== --===============5825101229438842533==--