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

[Oleksandr Andrushchenko <andr2000@xxxxxxxxx>]

BTW, what do you think about adding FB functionality into DISPLIF protocol?

Of course it will duplicate FB, but allow future extensions


On 01/27/2017 09:56 AM, Jan Beulich wrote:
> > > > On 26.01.17 at 19:39, <andr2000@xxxxxxxxx> wrote:
> > Does the below answer your question?
> I think that's fine, once added to the actual patch description.
>
> Jan
>
> > 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