[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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



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

 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.