On 01/05/2017 05:45 PM, Jan Beulich wrote:
On 22.12.16 at 09:12, <andr2...@gmail.com> wrote:+struct xendispl_pg_flip_evt { + uint64_t fb_cookie;Considering that apparently all operations have this cookie, I think it would better go ...+}; + +struct xendispl_req { + uint16_t id; + uint8_t operation; + uint8_t reserved[5];... here.
If someone adds another event which doesn't need it? IMO, this is ok to reside where it is.
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" I tried to evaluate what would it be like to extend existing fbif... It looks like having 2 different protocols in a single file. 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
Jan
_______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
