[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
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |