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

["Jan Beulich" <JBeulich@xxxxxxxx>]

>>> 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