Re: RFC: XSpice shift to an 'x11spice' approach

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

 



Il 28/03/2016 16:19, Jeremy White ha scritto:
> Hi folks,
>
> As you know, I've done a lot of work on XSpice over the past few years.
>  I plan to take a new approach by following the model of the excellent
> 'x11vnc' client.

Thanks for your work with spice projects.
Even if good x11vnc I think that too limited and has made me unable to
switch from windows to linux on a part of users/computers where
something like spice full features instead would be good or optimal.

>
> That is, instead of having our own X server and capturing the output, I
> plan to instead use an xdummy style server with a frame buffer which
> then runs an x11spice client to push the display via the Spice protocol.
>
> This should have a number of benefits.  First, it should create a new
> capability - the ability to share an existing desktop via Spice.

This seems the same goal I'm trying to reach(screen share is an
important thing on what I need but in xspice missed).
I looked Xspice but I thinked that basing on obsolete display server is
not a good idea on medium/long time, I saw a spice compositor for
wayland in development time ago, the initial developer don't have time
for it but looking rdp compositor and screen share plugin already
upstream, and with wayland and weston seems to have more potential (from
what I've seen in theory, but I have not yet studied thoroughly).
I started to give a small help to it in a free time, unfortunately for
now I can't do something of signifier, seems I have to understand many
things about spice and wayland before.
Someone with experience can tell me if trying to reach this goal with
wayland is a good idea or not?

>
> Second, it should allow the x11spice process to run entirely as a non
> privileged user.  This should simplify some of the existing Xspice
> management headaches.  (Full candor note: it simplifies some of the
> private use cases I have for Xspice, where security and process
> isolation is vital).
>
> Third, it should allow for some simplification by removing the need to
> have our own X server.  That simplification does come with a cost - we
> now have the expanded complexity of intercepting X events and managing
> that at an application level, instead of at a driver level, so that's
> arguably a wash.

This seems better and simple to do with wayland, or I'm wrong? (I don't
have knowledge to be sure I take only a fast look trying to understand
if was possible to "add screen share" to xspice before trying to help
spice compositor project)

I guess another thing I think that is very important for project like
this is efficiency, I have enough knowledge to make a reliable
assessment, it will be efficient and with a quite negligible latency?

Thanks for any reply and sorry for my bad english.

>
> Finally, I'm hoping that I may be able to do some thoughtful analysis of
> the approach taken by Xpra, and either incorporate Xpra directly, or at
> least leave a path open for it, so that we could have 'rootless' or
> seamless applications as an option.
>
> What do others think?  What am I over looking?
>
> Cheers,
>
> Jeremy
> _______________________________________________
> Spice-devel mailing list
> Spice-devel@xxxxxxxxxxxxxxxxxxxxx
> https://lists.freedesktop.org/mailman/listinfo/spice-devel
>
>


Attachment: smime.p7s
Description: Firma crittografica S/MIME

_______________________________________________
Spice-devel mailing list
Spice-devel@xxxxxxxxxxxxxxxxxxxxx
https://lists.freedesktop.org/mailman/listinfo/spice-devel

[Index of Archives]     [Linux ARM Kernel]     [Linux ARM]     [Linux Omap]     [Fedora ARM]     [IETF Annouce]     [Security]     [Bugtraq]     [Linux]     [Linux OMAP]     [Linux MIPS]     [ECOS]     [Asterisk Internet PBX]     [Linux API]     [Monitors]