[Spice-devel] developer assistance
Alon Levy
alevy at redhat.com
Thu Jan 26 02:11:27 PST 2012
On Wed, Jan 25, 2012 at 01:34:17PM -0500, William F Rotach wrote:
> Hello Alon,
> The whole spice project is interesting to me. The passing of 3D commands
> (openGL, directX or open CL) across the interface is of particular
> interest, but I am not certain if there is more foundation work needed
> prior to resolving this feature.
> I am willing to work on what is needed, and a little direction would be
> appreciated.
> Thank you for your time,
> Regards,
> Will Rotach
Hi William,
Sorry for not answering earlier, on list is better then private. There
are quite a lot of things that can be done. 3D for instance - I'm the
only one working on it right now and it's proceeding slowly, more
details at the end of the email. There are lower fruit to pick, you
should look at the FutureFeatures page, I guess you already did,
although it is not kept totally up to date it is mostly there. Some
things off the top of my head:
- OPUS usage instead of CELT051. This looked simple at the beginning,
it's probably still relatively simple, but it is a little
complicated by the fact that OPUS uses 48000 Hz sampling rate
and CELT051 uses 44100 Hz. The idea is to add another supported
encoding, add a capability flag for it, but it gets a little more
complicated becuase we shouldn't require any resampling done at qemu
or spice server if possible.
- video passthrough with gstreamer. This would go:
<new gstreamer sink> - <virtio serial port> - <spicevmc char dev> -
<spicevmc channel> - <new client processing>
The main problem, that I'm not sure how to solve exactly, would be
correct rendering wrt overlapping windows. But except for that it's
relatively straight forward and requires just a new guest component
and client component. The rest need no or very little change.
- autotest-kvm spice support. I will file tickets for the various
issues we have that are keeping us from using autotest to check
spice performance and regressions, today I hope. If this is
interesting to you I can
elaborate or just point you at the tickets once I open them.
A little harder:
- filesystem passthrough
Probably harder:
- complete the multiple client support. This requires major
understanding of the spice server. Specifically the current main
limitation wrt multiple concurrent client support is that the
implementation assumes the same messages are sent to all clients.
For different bandwidth clients (think local and on WAN client) this
doesn't work, the pipe to one of the clients grows unbounded, and
eventually the server aborts when the drawables run out. There are
many things that are wrong here: the way we account for the pipe
size is by number of messages, not number of bytes those messages
require. The hard limit on the number of drawables is also wrong
since they are also not equal exactly. But the main problem is
needing to reduce the size of a pipe to the slow (lower bandwidth)
client. I think rewriting the pending messages in that pipe would
do that, that would require tracking the number of bytes in them in
the first place.
- Back to 3D: I'm pursuing a gallium based solution. I have a drm
driver that's close to working for the existing xf86-video-qxl
driver, both repositories are at:
git://anongit.freedesktop.org/~alon/linux qxl
git://people.freedesktop.org/~alon/xf86-video-qxl drm
After that I intend to start working on the mesa parts, and server
side only rendering. I'd love to have some help so if you are
interested it would be great.
Some other things:
- Xspice related. Getting it to work with a second driver at the same
time. Haven't tried yet.
- Spice for Wayland. Actually not sure how hard this would be at all.
So anyway there are a ton of things to do. Playing with different
compressions is probably also relatively easy and possibly very
rewarding. Qemu only or mostly work, like launching the spice agent via
qemu-ga, or the generic mouse and generic copy paste support in qemu
instead of only in spice (and thus usable for vnc as well) that was
discussed. Sorry for not providing links, I did say off the top of my
head :) (both of these are mentioned on qemu-devel, mouse related Gerd
Hoffman did a few iterations of a spec already, but I think he is doing
other things right now so maybe he wouldn't mind if someone worked - not
really sure)
Alon
>
> On Tue, Jan 24, 2012 at 4:22 AM, Alon Levy <[1]alevy at redhat.com> wrote:
>
> On Mon, Jan 23, 2012 at 01:03:21PM -0500, William F Rotach wrote:
> > To spice-devel team:
> > ן߽ I am interested in assisting with the Spice project.ן߽ One of
> the list of
> > "todo"s, Single Device Multiple Monitors
> > [[1][2]http://www.spice-space.org/page/Features/PCIMultipleOutput],
> looks
> > interesting to me.
> > ן߽ I have examined some of the QXL code, and read up on the
> description of
> > the problem.ן߽ I would like some interaction and perhaps a bit of
> support
> > prior to contributing code changes.
> > ן߽ Thank you for your time.
>
> Hi William,
>
> That feature is planned to be fixed in the next few months by me, so
> thanks for the offer but I'd suggest you look for another issue you
> care about :/
>
> Alon
>
> >
> >
> ,Regards ן߽
> > WIll
> Rotach ן߽
> >
> > References
> >
> > Visible links
> > 1. [3]http://www.spice-space.org/page/Features/PCIMultipleOutput
>
> > _______________________________________________
> > Spice-devel mailing list
> > [4]Spice-devel at lists.freedesktop.org
> > [5]http://lists.freedesktop.org/mailman/listinfo/spice-devel
>
> References
>
> Visible links
> 1. mailto:alevy at redhat.com
> 2. http://www.spice-space.org/page/Features/PCIMultipleOutput
> 3. http://www.spice-space.org/page/Features/PCIMultipleOutput
> 4. mailto:Spice-devel at lists.freedesktop.org
> 5. http://lists.freedesktop.org/mailman/listinfo/spice-devel
> _______________________________________________
> Spice-devel mailing list
> Spice-devel at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/spice-devel
More information about the Spice-devel
mailing list