Re: [Embedded-pv-devel] [PATCH] drmif: add ABI for para-virtual DRM/KMS

[Dario Faggioli <dario.faggioli@citrix.com>]

[-- Attachment #1.1: Type: text/plain, Size: 2024 bytes --]

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.
> > 
> 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
-- 
<<This happens because I choose it to happen!>> (Raistlin Majere)
-----------------------------------------------------------------
Dario Faggioli, Ph.D, http://about.me/dario.faggioli
Senior Software Engineer, Citrix Systems R&D Ltd., Cambridge (UK)

[-- Attachment #1.2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 819 bytes --]

[-- Attachment #2: Type: text/plain, Size: 127 bytes --]

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel