Re: [Embedded-pv-devel] [Xen-devel] [PATCH v1] displif: add ABI for para-virtual display

[Oleksandr Andrushchenko <andr2000@xxxxxxxxx>]

Hi, Jan!

Does the below answer your question?

Thank you,
Oleksandr

On 01/05/2017 08:07 PM, Oleksandr Andrushchenko wrote:
> On 01/05/2017 06:12 PM, Jan Beulich wrote:
> > > > > On 05.01.17 at 17:03, <andr2000@xxxxxxxxx> wrote:
> > > On 01/05/2017 05:45 PM, Jan Beulich wrote:
> > > > > > > On 22.12.16 at 09:12, <andr2000@xxxxxxxxx> wrote:
> > > > Other than that the primary thing I'm missing (as I think I've
> > > > mentioned elsewhere already) is a rationale of why this new
> > > > protocol is needed (and the existing xenfb one can't be extended).
> > > "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"
> > Well, that's all stuff you had spelled out in the accompanying mail,
> > but that's all items which could be taken care of by a protocol
> > extension too.
> of course
> > > I tried to evaluate what would it be like to extend existing fbif...
> > > It looks like having 2 different protocols in a single file.
> > This is what I'd like you to expand on.
> To start with:
>
> 1. In/out event sizes
>  o fbif - 40 octets
>  o displif - 40 octets
> It fits now, but this is only the initial version of the displif protocol
> which means that there could be requests which will not fit
> (we are thinking of 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. This makes me believe if we extend fbif it is better
> to have separate structures/rings from the start.
>
> 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 I believe 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.
> BTW, I can add framebuffer's update and resize into displif, so
> it could  probably supersede fbif at some point
>
> > > What is more fbif can be used together with displif running at the
> > > same time, e.g. on Linux one provides framebuffer and another DRM
> > And this is certainly a valid argument (which hence should be
> > spelled out in the description).
> ok
> > Jan

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