[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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



>>> On 24.11.16 at 16:44, <andr2000@xxxxxxxxx> wrote:
>>  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"? 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.

Jan


_______________________________________________
Embedded-pv-devel mailing list
Embedded-pv-devel@xxxxxxxxxxxxxxxxxxxx
https://lists.xenproject.org/cgi-bin/mailman/listinfo/embedded-pv-devel

 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.