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

[Oleksandr Andrushchenko <andr2000@gmail.com>]

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