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

From: Oleksandr Andrushchenko <andr2000@gmail.com>
To: Jan Beulich <JBeulich@suse.com>
Cc: "Lars Kurth" <lars.kurth@citrix.com>,
	"Iurii Konovalenko" <iurii.konovalenko@globallogic.com>,
	xen-devel@lists.xensource.com,
	"Volodymyr Babchuk" <vlad.babchuk@gmail.com>,
	"Tim Deegan" <tim@xen.org>,
	"Dario Faggioli" <dario.faggioli@citrix.com>,
	ian.jackson@eu.citrix.com, "Грицов Олександр" <al1img@gmail.com>,
	"Andrii Anisov" <andrii.anisov@gmail.com>,
	"Oleksandr Tyshchenko" <olekstysh@gmail.com>,
	embedded-pv-devel <embedded-pv-devel@lists.xenproject.org>,
	"Julien Grall" <julien.grall@arm.com>,
	"David Vrabel" <david.vrabel@citrix.com>,
	"Oleksandr Dmytryshyn" <oleksandr.dmytryshyn@globallogic.com>,
	"Mygaiev Artem" <joculator@gmail.com>
Subject: Re: [Embedded-pv-devel] [PATCH] drmif: add ABI for para-virtual DRM/KMS
Date: Thu, 24 Nov 2016 20:31:34 +0200	[thread overview]
Message-ID: <CANY+8ddjf3cL_1hkfODVZBNUhuq=wiZtzA=Yuso-9xBHTquVzA@mail.gmail.com> (raw)
In-Reply-To: <58371E120200007800121E08@prv-mh.provo.novell.com>

>>>  One thing which I think you should have clarified up front is why
>>> the existing fbfront is neither sufficient nor possible to extend
>>> suitably.
>> Framebuffer device is rather outdated way for Linux user-space
>> to draw. All modern software expects DRM/KMS drivers and as
>> a fallback *may* use fbdev. For that reason, there is a demand
>> on DRM support for guests. So, it doesn't replace fbdev, but rather extend
>>> Which gets me to a second aspect: The chosen name is
>>> rather Linux centric - DRM has quite different a meaning in the
>>> Windows world afaik.
>>>
>> Well, that was my intent: define ABI for *Linux DRM/KMS* protocol
>> That said, it is still possible to implement back or front on Windows
>> with this protocol if need be
>
> 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.
>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.
> Jan
>
Best regards,
Oleksandr Andrushchenko

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