[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [Xen-devel] [For Linux 4/4] xen/displif: add ABI for para-virtual display
On 07/04/17 10:30, Oleksandr Andrushchenko wrote: > From: Oleksandr Andrushchenko <oleksandr_andrushchenko@xxxxxxxx> > > This is the ABI for the two halves of a para-virtualized > display driver. > > This protocol aims to provide a unified protocol which fits more > sophisticated use-cases than a framebuffer device can handle. At the > moment basic functionality is supported with the intention to extend: > o multiple dynamically allocated/destroyed framebuffers > o buffers of arbitrary sizes > o better configuration options including multiple display support > > Note: existing fbif can be used together with displif running at the > same time, e.g. on Linux one provides framebuffer and another DRM/KMS > > Future extensions to the existing protocol may include: > o allow display/connector cloning > o allow allocating objects other than display buffers > o add planes/overlays support > o support scaling > o support rotation > > Note, that this protocol doesn't use ring macros for > bi-directional exchange (PV calls/9pfs) bacause: > o it statically defines the use of a single page > for the ring buffer > o it uses direct memory access to ring's contents > w/o memory copying > o re-uses the same idea that kbdif/fbif use > which for this use-case seems to be appropriate > > ================================================== > Rationale for introducing this protocol instead of > using the existing fbif: > ================================================== > > 1. In/out event sizes > o fbif - 40 octets > o displif - 40 octets > This is only the initial version of the displif protocol > which means that there could be requests which will not fit > (WRT introducing some GPU related functionality > later on). In that case we cannot alter fbif sizes as we need to > be backward compatible an will be forced to handle those > apart of fbif. > > 2. Shared page > Displif doesn't use anything like struct xenfb_page, but > DEFINE_RING_TYPES(xen_displif, struct xendispl_req, struct > xendispl_resp) which is a better and more common way. > Output events use a shared page which only has in_cons and in_prod > and all the rest is used for incoming events. Here struct xenfb_page > could probably be used as is despite the fact that it only has a half > of a page for incoming events which is only 50 events. (consider > something like 60Hz display) > > 3. Amount of changes. > fbif only provides XENFB_TYPE_UPDATE and XENFB_TYPE_RESIZE > events, so it looks like it is easier to get fb support into displif > than vice versa. displif at the moment has 6 requests and 1 event, > multiple connector support, etc. > > Reviewed-by: Konrad Rzeszutek Wilk <konrad.wilk@xxxxxxxxxx> > Signed-off-by: Oleksandr Grytsov <oleksandr_grytsov@xxxxxxxx> > Signed-off-by: Oleksandr Andrushchenko <oleksandr_andrushchenko@xxxxxxxx> Acked-by: Juergen Gross <jgross@xxxxxxxx> Juergen _______________________________________________ Xen-devel mailing list Xen-devel@xxxxxxxxxxxxx https://lists.xen.org/xen-devel
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |