Questions about experimental Spice compositor rebase

Yury Shvedov shved at
Mon Feb 29 15:01:40 UTC 2016

Unfortunately, it is bit complex for me, to understand what are you 
trying to do and why do you dancing with diff's instead of just simple 

Anyway, I gave you an edit-access to my repository. If you want, you can 
work with it directly on your own branch. I hope, this will make things 
simpler for you.

See answers in quote.

On 02/29/2016 03:32 PM, Fabio Fantoni wrote:
> Il 29/02/2016 12:26, Yury Shvedov ha scritto:
>> Hi, Fabio!
>> Take look at my latest commit It now merged with latest master 
>> version and successfully compiles with ./configure 
>> --enable-spice-compositor.
>> But unfortunately it doesn't work due to new spice API. I hope, this 
>> evening it will!.
> Thanks for your work about it.
> I make the new diff in other test branch:
> And I have some questions:
> - src/ was removed in newer weston and now unused, I suppose
> to be removed
Did I fogot to do it in my repo? Oh yes! My bad! I will!
> - missed monitor renderer additions, must be added or 
> monitor renderer is not
> needed anymore?
Its doesn't used by spice, so if there no monitor renderer additions in 
original weston repo, then it is not needed anymore.
> - src/compositor-rdp.c: I suppose is not needed and not related changes
> to be removed, right?
Why? It is just another part of weston. If you don't need it just don't 
pass --enable-rd-compositor to configure.
> - src/spice/ I suppose is unused now that thing are added in
>, to be removed, right?
Yes, the same as src/
> Can be the monitor renderer missed/incomplete the cause of "run test" 
> failed?
I didn't try tests, so can't answer. Will look at evening.
> About spice-server api I did't found good docs to make update simply 
> and fast but with a fast search I found this xspice (similar project 
> for xorg instead) commit that probably can be faster update some 
> deprecrated spice functions: 
> I don't have sufficent free time for try to change it and test 
> build/use today.
I spend much time for reading spice source code to understand its API 
far in 2013. To understand it you have to read sources as I. I remember 
that in fact spice protocol is - to say simple - drawing API. You can 
draw stuff from spice-server on spice-client's screen. Anyway we need to 
learn new api, reading example source code as I did.

I did simple example <> then to 
practice on spice API.
> After update to newer api I suppose will be good add also a required 
> spice-server version check in configure based on newer api, I found 
> this that seems will make fast see at what version was added any api: 
Yes of course we will!
> Another important note if you don't know it, spice-server recently is 
> under heavy changes, latest version (0.13.0) is like a "devel 
> snapshot". Latest stable version that I think is good to use also with 
> this project for now is 0.12.6.
Yes, I don't. Is it possible for you to assemble all documents and links 
on this topic, you found?
> Thanks for any reply and sorry for my bad english.
>> On 02/29/2016 12:22 PM, Daniel Stone wrote:
>>> Hi Fabio,
>>> On 27 February 2016 at 18:02, Fabio Fantoni <fabio.fantoni at> 
>>> wrote:
>>>> Hi, long time ago I saw an interesting project for weston, the spice
>>>> compositor:
>>>> It is now abandoned because the developer has been involved in another
>>>> project.
>>>> As no other has continued it, despite my low knowledge and time I 
>>>> would try
>>>> to update, test and possibly improve it.
>>> Great!
>>>> I did a new branch with only 2 commit on top of latest upstream 
>>>> commit:
>>>> and I tried to do a fast rebase on latest upstream commit (1.10) 
>>>> instead of
>>>> master (development branch) for decrease the risk regression on first
>>>> build/use tests:
>>>> Solving conflict about configure and makefile parts I have some 
>>>> doubts (as
>>>> also reported in the description of each commit):
>>>> About first commit (Add Spice compositor)
>>>> - in some changes seems strange, including LIBS and 
>>>> CFLAGS that
>>>> seems "double"
>>> I think this can be removed. Usually setting LIBS/CFLAGS and
>>> foo_save_LIBS/foo_save_CFLAGS is used for an AC_CHECK_* call, which
>>> relies on LIBS and CFLAGS already being set. I guess there may have
>>> been a call here which has since been removed.
>>>> About the second commit (Monitor renderer)
>>>> - Makefile things seems fully changed, tried to adapt them but I'm 
>>>> not sure
>>>> if I did it correct.
>>>> - Add -g to AM_CPPFLAGS in is really needed? not added 
>>>> for now
>>> No, this is a debugging feature only.
>>>> - add of "-Wl,--wrap=pixman_renderer_init" to LDFLAGS of many other 
>>>> backend
>>>> is really needed? not added for now, if needed is good understand 
>>>> why to add
>>>> it also to new things added since this start commit done 3 years ago
>>> This should be solved in a different way if required.
>>>> - src/compositor-rdp.c changes is really needed? if not I'll remove 
>>>> them
>>>> I also searched documentation about api and/or internal weston 
>>>> functions
>>>> changed any versions but I not found them.
>>> There is no documentation on the change, no.
>>> As you can see, several functions have changed:
>>>    - weston_output_finish_frame now takes a struct timespec rather than
>>> an integer number of milliseconds (trivial conversion)
>>>    - the output repaint function now returns an integer marking success
>>> or failure
>>>    - the compositor interface has now changed to weston_backend, and
>>> you can see examples of the changes required in commit 954f183e
>>> Hope this helps: just pick out the warnings and errors one by one, and
>>> try to figure them out - searching git commits for anything relevant
>>> always helps - until you get something that builds.
>>> Cheers,
>>> Daniel
>> -- Kind Regards, Yury Shvedov

-- Kind Regards, Yury Shvedov
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <>

More information about the wayland-devel mailing list