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

[Dario Faggioli <dario.faggioli@xxxxxxxxxx>]

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: signature.asc
Description: This is a digitally signed message part

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