lkml.org 
[lkml]   [2017]   [Apr]   [7]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
SubjectRe: [Xen-devel] [For Linux 4/4] xen/displif: add ABI for para-virtual display
From
Date
On 07/04/17 10:30, Oleksandr Andrushchenko wrote:
> From: Oleksandr Andrushchenko <oleksandr_andrushchenko@epam.com>
>
> 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@oracle.com>
> Signed-off-by: Oleksandr Grytsov <oleksandr_grytsov@epam.com>
> Signed-off-by: Oleksandr Andrushchenko <oleksandr_andrushchenko@epam.com>

Acked-by: Juergen Gross <jgross@suse.com>


Juergen

\
 
 \ /
  Last update: 2017-04-07 13:33    [W:0.090 / U:0.224 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site