Re: [PATCH v1] displif: add ABI for para-virtual display

[Oleksandr Andrushchenko <andr2000@gmail.com>]

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@gmail.com> wrote:
>>> On 01/05/2017 05:45 PM, Jan Beulich wrote:
>>>>>>> On 22.12.16 at 09:12, <andr2000@gmail.com> 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
>>
>


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel