>>> On 27.01.17 at 09:11, wrote:
> BTW, what do you think about adding FB functionality into DISPLIF protocol?
>
> Of course it will duplicate FB, but allow future extensions
I have no particular opinion here, other than my general dislike of
duplication / redundancy.
Jan
BTW, what do you think about adding FB functionality into DISPLIF protocol?
Of course it will duplicate FB, but allow future extensions
On 01/27/2017 09:56 AM, Jan Beulich wrote:
On 26.01.17 at 19:39, wrote:
Does the below answer your question?
I think that's fine, once added to the actual
>>> On 26.01.17 at 19:39, 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, wrote:
On 01/05/
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, wrote:
On 01/05/2017 05:45 PM, Jan Beulich wrote:
On 22.12.16 at 09:12, wrote:
Other than that the pr
As agreed on PV call PFA pahole results
On 12/22/2016 10:12 AM, Oleksandr Andrushchenko wrote:
From: Oleksandr Andrushchenko
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 supp
On 01/05/2017 06:12 PM, Jan Beulich wrote:
On 05.01.17 at 17:03, wrote:
On 01/05/2017 05:45 PM, Jan Beulich wrote:
On 22.12.16 at 09:12, 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 t
>>> On 05.01.17 at 17:03, wrote:
> On 01/05/2017 05:45 PM, Jan Beulich wrote:
> On 22.12.16 at 09:12, 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
On 01/05/2017 05:45 PM, Jan Beulich wrote:
On 22.12.16 at 09:12, 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;
+
>>> On 22.12.16 at 09:12, 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];
.
Bug fix
On 12/22/2016 10:12 AM, Oleksandr Andrushchenko wrote:
From: Oleksandr Andrushchenko
This is the ABI for the two halves of a para-virtualized
display driver.
Changes since initial:
* DRM changed to DISPL, protocol made generic
* major re-work addressing issues raised for sndif
Sig
From: Oleksandr Andrushchenko
This is the ABI for the two halves of a para-virtualized
display driver.
Changes since initial:
* DRM changed to DISPL, protocol made generic
* major re-work addressing issues raised for sndif
Signed-off-by: Oleksandr Andrushchenko
Signed-off-by: Oleksandr Gryts
From: Oleksandr Andrushchenko
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 buf
12 matches
Mail list logo