Re: [Spice-devel] 回复： spice client migrate to Android & IOS plateform

[Attila Sukosd]

There has been some efforts to have an Android spice client:

http://code.google.com/p/spice-client-android/

I think the project has been abandoned though...


On Fri, Mar 8, 2013 at 12:42 PM, Dunrong Huang  wrote:

> On Fri, Mar 8, 2013 at 6:37 PM, 李彪  wrote:
> >
> >
> >
> > -- 原始邮件 --
> > 发件人: "Dunrong Huang";
> > 发送时间: 2013年3月8日(星期五) 晚上6:24
> > 收件人: "李彪";
> > 抄送: "spice-devel";
> > 主题: Re: [Spice-devel] spice client migrate to Android & IOS plateform
> >
> > Hi,
> >
> > Sounds great if spice client can be ported to android or ios.
> >
> > On Fri, Mar 8, 2013 at 4:39 PM, 李彪  wrote:
> >> hi, all
> >>
> >> Is there any dev plan to migrate spice client to Android or IOS
> plateform
> >> ?
> >>
> >> Is there any known technical difficulties in this migration ? I know
> that
> >> spice-server is designed for 64bit env, can not be migrated to 32bit env
> >> without greate effort. am I right ?
> >>
> > If you want to write spice client(android or ios), you will not need
> > to care about spice server too much. Furthermore, as far as I know,
> > spice server can run on 32-bit machine
> >
> > [thomas] are you sure spice-server can run on 32bit machine ? I cannot
> even
> > compile under 32bit env without code change.
> Yes, I am sure. You should use newer server version.
> > by the way, the available spice clients are spicy, spicec, and one for
> > html5. based on email archive search, I find that spicec is not good
> > candidate, spicy maybe better.
> >
> Note that spicy is just a test app, and spicec has been a dead end.
> The spice client spice team mainly support is spice-gtk(remote-view).
> >
> >> Can some one let me konw how much effort it would cost, respectively in
> >> Android or IOS ? if NOT such official dev plan, I'd like to initiate
> one.
> >>
>
> --
> Best Regards,
>
> Dunrong Huang
> ___
> Spice-devel mailing list
> Spice-devel@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/spice-devel
>
___
Spice-devel mailing list
Spice-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/spice-devel

Re: [Spice-devel] improving spice-html5 performance

[Attila Sukosd]

I would also be interested in helping out improving it possibly :)

Attila

On Wed, Feb 20, 2013 at 10:14 AM, Erfane Arwani wrote:

> Hello Jeremy,
>
> We'd like to know more about your code.
> +Have you generated the javascript? Automatically? In the Wiki you talk
> about C compiler producing JS.
> +What are the implemented features compared to the Spicy client?
> +Are there some areas you would definitely rewrite?
> +Is the image cache feature implemented?
> +How do you manage the different keyboards?
>
> Some other questions:
> +What optimisations could we perform to speed up the client?
> +Do you think it's possible to go on UDP ? (webRTC)
>
> Cheers,
>
> Erfane
>
> On Feb 19, 2013, at 5:45 PM, Jeremy White  wrote:
>
> > On 02/19/2013 10:42 AM, Erfane Arwani wrote:
> >> Hi,
> >>
> >> Is there currently someone in charge of the HTML5 client? Who developed
> the first version?
> >
> > I developed it initially, and I imagine that I'm considered the primary
> > maintainer as well.
> >
> > Cheers,
> >
> > Jeremy
>
> ___
> Spice-devel mailing list
> Spice-devel@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/spice-devel
>
___
Spice-devel mailing list
Spice-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/spice-devel

Re: [Spice-devel] Spice arm port 2D rendering/requirements

[Attila Sukosd]

Hi,

We have been testing a number of thin clients lately, but I have to say
that we haven't met one which did not have an X driver :)
These include everything from HP thinclients to raspberry pis, trimslice
etc.

I think pixman does a pretty good job basic draw operations, but for video
playback it could make sense to codec pass-through (
http://spice-space.org/page/Features/CodecPassthrough) to let the graphics
driver decode it,
instead of the overhead of encoding then decoding MJPEG.


/Attila

On Sat, Nov 10, 2012 at 9:39 AM, Alon Levy  wrote:

> >
> >
> > Hello,
> >
> > I have come to know that GNU/Linux Arm ports for various arm
> > platforms out there usually dont have a working X server. The GPUs
> > usually lack a dedicated X server driver. That being the case arm
> > platforms usually support OpenGLES/OpenVG libraries. spice-gtk arm
> > port is 2D operations intensive. I believe to use an arm board as a
> > thinclient for SPICE we need proper 2D rendering on the board.
> > Without accelerated X server, can i use openvg? please elaborate i
> > am not even sure what i said earlier is totally correct.
> >
> > To custom build a spice thinclient what should i look for in a
> > embedded system?
> > according to openthinclient.org i need a x86 proc+ working X.org+
> > 128MB ram. Is it possible to get spice-gtk arm perform well without
> > a hardware/GPU accelerated X server.
>
> spice-gtk doesn't use GPU acceleration directly, it uses pixman, which
> doesn't use that either. pixman does make use of NEON and, SIMD, IWMMXT and
> IWMMXT2 instructions on arm - this is just copied from ./configure --help
> of pixman's tip, no idea which of these are packaged.
>
> If it turns out this is not enough on your cpu you will have some work cut
> out for you. I know there is at least one intel project that does 2d
> rendering via OpenGL or maybe GLES (glamour I think).
>
> >
> >
> >
> >
> > ___
> > Spice-devel mailing list
> > Spice-devel@lists.freedesktop.org
> > http://lists.freedesktop.org/mailman/listinfo/spice-devel
> >
> ___
> Spice-devel mailing list
> Spice-devel@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/spice-devel
>
___
Spice-devel mailing list
Spice-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/spice-devel

Re: [Spice-devel] Announcing the first version of spice-html5

[Attila Sukosd]

Hi guys,

I just gave the html5 client a go, but I'm unable to connect to a RHEV 3
server with SSL. I've started websockify with the ca crt and gave the
client and websockify the secure port.

After turning debugging on I'm getting the following:

>> WebSockets.onopen
spiceconn.js:67 id
0; type 1
 spiceconn.js:232 1:
Connected
 spiceconn.js:317 <<
hdr main type 1 size undefined
 spiceconn.js:379
WARNING:
1: Unknown message type 1!

Am I missing something? :)

Thanks!

Attila

-
DTU Computing Center - www.cc.dtu.dk
att...@cc.dtu.dk, gba...@student.dtu.dk, s070...@student.dtu.dk




On Wed, Jun 6, 2012 at 4:43 PM, Yaniv Kaul  wrote:

> - Original Message -
> > >> *blush*  Yes, sorry, the keyboard code is truly awful.  It's a
> > >> matter of
> > >> translating web key codes into scan codes; I didn't find a good
> > >> way to
> > >> do it, and just used a brute force hack. If you're at all a
> > >> programmer,
> > >> it would be easy to extend the hack and fix the key codes for
> > >> yourself;
> > >> that code is in utils.js.
> > >
> > > No escape to get the scancode from the browser? have to wait for
> > > html6?
> >
> > None that I found (which is not necessarily !== none ).  All I
> > could find were faqs that said key codes in general are a mess and
> > not
> > standardized (they apparently vary by browser), and certainly nothing
> > to
> > go from key codes to scan codes.
>
> I agree - and this is why I did not implement the translation in the
> Wireshark dissector for the protocol.
> If you do find something sane, I'll try and adopt it too.
> Y.
>
> >
> > My thought was to later explore some of the third party libraries
> > that
> > try to mitigate these issues, and see if riffing off one of those
> > leads
> > to a slightly less ugly solution.
> >
> > There are also some tricky issues around keyboard handling I didn't
> > even
> > begin to think about (e.g. tab, escape, alt-tab, and so on).
> >
> > Cheers,
> >
> > Jeremy
> > ___
> > Spice-devel mailing list
> > Spice-devel@lists.freedesktop.org
> > http://lists.freedesktop.org/mailman/listinfo/spice-devel
> >
> ___
> Spice-devel mailing list
> Spice-devel@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/spice-devel
>
___
Spice-devel mailing list
Spice-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/spice-devel

Re: [Spice-devel] Student Project around Spice

[Attila Sukosd]

Hi,

How about some POC work on the html5 client? In case they would like to do
some JS :)


Best Regards,

Attila


-
DTU Computing Center - www.cc.dtu.dk
att...@cc.dtu.dk, gba...@student.dtu.dk, s070...@student.dtu.dk




On Wed, Jun 20, 2012 at 12:07 PM, Yaniv Kaul  wrote:

> Hi,
>
> I'm trying to get students to develop something for Spice as a project for
> their university.
> It should take 60-120 hours, though, and while they have basic C/C++
> knowledge, I would not assume anything more.
> Any ideas?
> For example, do you estimate it's feasible to develop a POC for Opus audio
> channel encoding ? Even if incomplete, not having the negotiation, the
> #ifdef'ing, whatever - just a POC to show a way and basic results?
> Anything else? (yes, I'm already thinking on protocol optimizations).
>
> TIA,
> Y.
> __**_
> Spice-devel mailing list
> Spice-devel@lists.freedesktop.**org 
> http://lists.freedesktop.org/**mailman/listinfo/spice-devel
>
___
Spice-devel mailing list
Spice-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/spice-devel

Re: [Spice-devel] xf86-video-qxl performance

[Attila Sukosd]

Low latency (and relatively low bandwidth) video streaming can be done with
x264 and xvid (low enough for a 3d game to be playable over the net)
However, it introduces licensing issues and high-ish CPU usage on the host
side :(


On Mon, May 28, 2012 at 11:19 AM, Alon Levy  wrote:

> On Thu, May 24, 2012 at 01:24:05PM -0500, Jeremy White wrote:
> > > Actually, for WAN, we require ACK for 40 messages, but we allow sending
> > > up to 80, without getting an ack for the first 40.
> > > From my experience with Windows guest, it sounds like the DRAW_FILL
> > > commands might be related to anti aliasing, and maybe the future RENDER
> > > support that Alon mentioned will indeed help with this. Meanwhile I
> > > would also try to disable off-screen surfaces, as was also mentioned in
> > > a previous reply,
> >
> > Ah, yes, sorry; I knew 20 was imprecise.   But (500 / 80) * 80 ms is
> > still a good bit of delay.
> >
> > Increasing the ack window (and pipe size) by a factor of 10 makes the
> > first apparent problem vanish.
> >
> > Disabling off screen surfaces has the same user visible effect.
> >
> > Note, though, that I have the luxury of focusing on a long term agenda,
> > so I'd rather pursue the 'best' solution (at least for now).
> >
> >
> > > What OS your client has? When spice-server identifies WAN, it
> > > automatically turn on Nagle's for the display channel (turns off
> > > TCP_NODELAY), which should aggregate small tcp messages. However, it
> has
> > > bad interaction with the delayed acks on the client side (especially in
> > > Windows clients, where the default delayed ack timeout is 200ms iirc),
> > > and overall it can lead to bigger latency between operations. We are
> > > planning to get read of this, and aggregate the messages on the
> > > application layer instead.
> >
> > I'm currently testing with Debian testing, although our eventual
> > deployment platform will be a heavily modified RHEL 6 system.  The
> > pointer to TCP_NODELAY is also a good one; I'll play with that and see
> > what effect it has.
> >
> > > Just to clarify, we currently don't condense messages in spice-server,
> > > though it is another item in our TODO.
> >
> > Ah, okay, that's helpful (although there is some very limited pruning in
> > red_worker.c, no?)
> >
> > Is that todo on anyone’s immediate radar?  I'm certainly not qualified,
> > but it seems like that could have an major impact on what we're trying
> > to achieve (regular Office applications hosted on a pure Linux server
> > across a WAN).  So perhaps I need to become qualified :-/.
>
> I have a patchset that didn't seem to do anything so I let it go, but if
> you'd like I can find it (that's the hard part) and put it somewhere you
> can have a look. It aggregates packets at the application layer
> (server/red_channel.c)
>
> >
> > Cheers,
> >
> > Jeremy
> > ___
> > Spice-devel mailing list
> > Spice-devel@lists.freedesktop.org
> > http://lists.freedesktop.org/mailman/listinfo/spice-devel
> ___
> Spice-devel mailing list
> Spice-devel@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/spice-devel
>
___
Spice-devel mailing list
Spice-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/spice-devel

Re: [Spice-devel] Thin client vendors supporting Spice

[Attila Sukosd]

Hi,

As someone already mentioned, Sunrays use their own proprietary protocol
for the thin client <-> terminal server communication, and running SPICE on
top of that would not make too much sense in terms of performance.

Although I have not tried Sunray 3, we have been using Sunray 1 & 2s for
quite a while, and we have not been too impressed by their performance or
support either.

But thats just my 2 cents. :)

Attila



On Fri, Apr 13, 2012 at 6:32 AM, Lubos Kocman  wrote:

> Hi
>
> RAYDESK with KIOSK mode used to be tuned fluxbox with X11 on whatever
> target the sun ray was connecting to (on Sun Ray 2).
>
>
> Sun ray takes target directly from DHCP macro so there is connection to
> target immediately after dhcp lease (unless you're not using vpn that takes
> an extra step).
>
> So in your scenario you'd use their protocol to connect to a physical
> target (or virtualbox target) and then launch SPICE there?
>
> That exactly like these advertisements for new televisions "See how
> beautiful colours has it" which are being played on your TV.
>
>
> Use gtranslate for more information:
> http://www.abclinuxu.cz/clanky/pr/virtualni-desktop-stickfish-raydesk(Czech)
>
>
> Lubos
>
> - Original Message -
> From: "Anthony James" 
> To: "Lubos Kocman" , "Scott Glazier" <
> s.glaz...@fugro.com>
> Cc: spice-devel@lists.freedesktop.org, "Jacek Skowronek" <
> jacek_skowro...@hotmail.com>
> Sent: Thursday, April 12, 2012 2:54:40 PM
> Subject: RE: [Spice-devel] Thin client vendors supporting Spice
>
> Not sure if this helps or not but at a previous employer they were working
> on setting up the Sun Ray clients in kiosk mode which I believe starts an X
> session from the Sun Ray Server where the SPICE client would be installed.
>
> The project was never finished and my understanding of how Sun Ray works
> is limited.
>
> 
> From: 
> spice-devel-bounces+anthony.james=cintriq@lists.freedesktop.org[spice-devel-bounces+anthony.james=
> cintriq@lists.freedesktop.org] on behalf of Lubos Kocman [
> lkoc...@redhat.com]
> Sent: Thursday, April 12, 2012 7:58 AM
> To: Scott Glazier
> Cc: spice-devel@lists.freedesktop.org; Jacek Skowronek
> Subject: Re: [Spice-devel] Thin client vendors supporting Spice
>
> :-) I'm sure that Sun Ray 3 does not support SPICE. It has just some basic
> firmware which is launching their client.
>
> (I have Sun Ray 2 at home)
>
> Lubos
>
> - Original Message -
> From: "Scott Glazier" 
> To: "Jacek Skowronek" ,
> spice-devel@lists.freedesktop.org
> Sent: Thursday, April 12, 2012 6:33:49 AM
> Subject: Re: [Spice-devel] Thin client vendors supporting Spice
>
>
>
>
>
> Jacek,
>
>
>
> While this is not an out of the box thin client suggestion, if you wanted
> to have a customizable environment you could perhaps look at the Zotac Zbox
> which does do 2560x1600, has a DVI and HDMI port, and can mount on the back
> of a screen. I purchased a few of these without HDD and setup them to PXE
> boot a CentOS image which contains the SPICE client, and a script to
> automatically connected to the relevant VM. The setup is nothing special
> but it works, and we use SPICE to permanently display a Windows 7 VM at
> 2650x1600 (amongst others).
>
>
>
> Cheers,
>
>
>
> Scott
>
>
>
>
>
> From: spice-devel-bounces+s.glazier=fugro@lists.freedesktop.org[mailto:
> spice-devel-bounces+s.glazier=fugro@lists.freedesktop.org] On Behalf
> Of Jacek Skowronek
> Sent: Wednesday, April 11, 2012 2:23 PM
> To: spice-devel@lists.freedesktop.org
> Subject: Re: [Spice-devel] Thin client vendors supporting Spice
>
>
> Dave and others,
>
> Thanks for info on SPICE support in thin client vendors. After some
> digging this is the status:
> IGEL has a thin client called UD5 which supports 2560x1600 and supports
> SPICE
> The same for Wyse, e.g. for the Z90S7 client.
>
> However, both of those do that through DisplayPort and not DVI.
>
> 10Zig 6000 series clients appears to support Spice with max 1920x1080
> resolution.
>
> Oracle is an interesting case. Their Sun Ray 3 client appears to support
> 2560x1600 through DVI.
> Does anybody know if it supports Spice? It appears to have a somewhat
> different software architecture
> (no Linux or Windows as OS, but their own Sun Ray client software).
>
> I would appreciate any help and will report back the results of this quest.
>
> As noted before we intend to do a hands-on eval of Spice on one of those
> clients next. This scan is
> meant to give us the right choice for the test.
>
> Cheers,
>
> Jacek
>
>
> Hi Jacek, this is the reply I got from people who know more than me about
> the subject. > Hi David, > > Currently, IGEL supports SPICE client on both
> their Windows and Linux > platforms and of course, SPICE is supported on
> any other WES7, XPe > Windows-based platform. Wyse will be supporting on
> their Linux > platform in the near future. > > Specifically for
> hi-resolution, RHEV 3 supports up to 2560x1600 > resolution. Howe

Re: [Spice-devel] Alternate platform exploration

[Attila Sukosd]

Hi Guys,

I've also been contemplating an alternative html5/js client, and as far as
I remember, Alon proposed an extension to spice-server to actually contain
a http server to serve the content to the browser.
But it seems like a too big project to take on alone :)


Best Regards,

Attila


-
DTU Computing Center - www.cc.dtu.dk
att...@cc.dtu.dk, gba...@student.dtu.dk, s070...@student.dtu.dk




On Wed, Mar 28, 2012 at 7:05 PM, Jeremy White wrote:

> I, like many before me, am interested in seeing a spice client on other
> platforms.  Things like Mac OS X, iOS, Android, HTML5, and so on.
>
> I've spent a bit of time researching what has gone before, and thought
> I'd try to summarize what I've found.  Mostly that will show my
> ignorance and hopefully smarter people than I will rush to correct me
> and I'll learn something .
>
> I gather that the primary focus of Spice development is around the spice
> gtk client.  That currently provides clients for *nix and Windows
> systems.  Spice-xpi lets you launch the client from a web browser so you
> get some modicum of browser integration.  libvirt integration lets you
> launch the client from vm managers, and related systems.
>
> Spice-gtk and spice-common is where all the action is.  The interesting
> spice implementations are all in c code.
>
> A proof of concept Mac implementation with Gtk has already been done. In
> theory, that's a straight forward, if potentially unsatisfying, solution
> for the Mac.  iOS and Android pose a much more substantial challenge,
> however.
>
> I didn't see any evidence of active work on alternate platforms - if I
> missed that, please both accept my apologies and fill me in.
>
> So, as I look around for ways forward, I've considered the following
> options:
>
>  1.  Native versions for all
>
>  This is probably the most satisfying option, but requires fairly
>  meaty work for Mac, iOS, and Android.  It also doesn't satisfy
>  the zero-installation I-want-it-in-my-browser people.  It also
>  imposes a long term maintenance challenge.
>
>
>  2.  HTML5 to rule them all
>
>  This, afaict, requires a complete SPICE client written in
>  Javascript.  This is no small task, and creates a fairly serious
>  maintenance challenge.  The client is still evolving
>  fairly rapidly, and synchronizing two code bases will be tricky.
>
>  It's also not clear if HTML5 can deliver the kind of performance
>  we all crave.
>
>  But, if a functional client could be implemented, it
>  would effectively solve all the alternate platform issues, right?
>
>
>  3.  Chrome / Pepper / Native Client
>
>  This approach would reuse the spice-common code, presumably,
>  and is a bit of hybrid.  It would be part Javascript, part
>  C code.  It would have similar, if more modest, maintenance
>  issues.  It would also only support Chrome (afaik, no
>  other browser has adopted the Native Client vision).
>
>  I saw one person on the mailing list propose this, but I saw no
>  actual action on it.
>
>
>  4.  Use gtk/Broadway
>
>  On the face of it, this would appear to be a compelling option.
>  Just rebuild the client to use the broadway backend, do some
>  server side footwork, and you have a solution similar to the
>  HTML5 vision.  But you have one code base.
>
>  But then I realized that having broadway working on a remote
>  server just recreates the problem that spice is meant to solve,
>  once again serving to remind me of my own stupidity :-/.
>
>  I can't find any reference to this being considered in the
>  mailing list archives, and a broader search finds me lots
>  of spicy restaurants on Broadway Ave :-).
>
>  I can't help but feel that there may yet be something clever
>  that could be done with broadway; I'm probably wrong, but it
>  feels like a string I should tug on.
>
>
>
> I did discard the concept of a Flash client; I feel that's not really a
> good long term solution.
>
> So all that leads me to conclude that the best path forward would be a
> Javascript / HTML5 client implementation.
>
> So now, please bring out the clue bats!
>
> Did I miss some implication of the libvirt connection?  Can an alternate
> client solution be leveraged instead?
>
> Other thoughts?
>
> Thanks,
>
> Jeremy
> ___
> Spice-devel mailing list
> Spice-devel@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/spice-devel
>
___
Spice-devel mailing list
Spice-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/spice-devel

Re: [Spice-devel] Interested in Contributing to SPICE

[Attila Sukosd]

Hi,

On Mon, Oct 3, 2011 at 11:07 AM, Alon Levy  wrote:

> On Sun, Oct 02, 2011 at 03:30:23PM +0200, Attila Sukosd wrote:
> >Hi,
> >
> >I would be interested in contributing to the java client :)
> >
> >I've written a proof of concept python client so I have at least some
> >idea of what goes on behind the scenes :)
>
> Is it based on the marshalling/demarshalling code generation?
>
>
No it's not.

But I guess the java one should be as it would be easier to keep up with
protocol changes.


>  >
> >Best Regards,
> >Attila Sukosd
> >-
> >DTU Computing Center - [1]www.cc.dtu.dk
> >[2]att...@cc.dtu.dk, [3]gba...@student.dtu.dk,
> >[4]s070...@student.dtu.dk
> >On Sun, Oct 2, 2011 at 3:15 PM, Timothy Sparg
> ><[5]timothy.sp...@gmail.com> wrote:
> >
> >  Hi all
> >  I'm interested in the possibilty of contributing a Java based client
> >  to the SPICE project.
> >  My long term goal would be to create a reusable viewer component -
> >  the same component could then be used to create an applet based
> >  viewer or a viewer embedded in a java application.
> >  I'm currently just perusing the SPICE protocol, but i suspect that
> >  it will take me a while to start getting my head around it.
> >  What are your views and thoughts as the SPICE developers, would you
> >  be interested in somebody working towards the goal of a java based
> >  client? Where should I get started learning the basics of the SPICE
> >  project?
> >  Regards
> >  Tim Sparg
> >  ___
> >  Spice-devel mailing list
> >  [6]Spice-devel@lists.freedesktop.org
> >  [7]http://lists.freedesktop.org/mailman/listinfo/spice-devel
> >
> > References
> >
> >1. http://www.cc.dtu.dk/
> >2. mailto:att...@cc.dtu.dk
> >3. mailto:gba...@student.dtu.dk
> >4. mailto:s070...@student.dtu.dk
> >5. mailto:timothy.sp...@gmail.com
> >6. mailto:Spice-devel@lists.freedesktop.org
> >7. http://lists.freedesktop.org/mailman/listinfo/spice-devel
>
> > ___
> > Spice-devel mailing list
> > Spice-devel@lists.freedesktop.org
> > http://lists.freedesktop.org/mailman/listinfo/spice-devel
>
>
___
Spice-devel mailing list
Spice-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/spice-devel

Re: [Spice-devel] Interested in Contributing to SPICE

[Attila Sukosd]

Hi,

I would be interested in contributing to the java client :)

I've written a proof of concept python client so I have at least some idea
of what goes on behind the scenes :)


Best Regards,

Attila Sukosd

-
DTU Computing Center - www.cc.dtu.dk
att...@cc.dtu.dk, gba...@student.dtu.dk, s070...@student.dtu.dk




On Sun, Oct 2, 2011 at 3:15 PM, Timothy Sparg wrote:

> Hi all
>
> I'm interested in the possibilty of contributing a Java based client to the
> SPICE project.
>
> My long term goal would be to create a reusable viewer component - the same
> component could then be used to create an applet based viewer or a viewer
> embedded in a java application.
>
> I'm currently just perusing the SPICE protocol, but i suspect that it will
> take me a while to start getting my head around it.
>
> What are your views and thoughts as the SPICE developers, would you be
> interested in somebody working towards the goal of a java based client?
> Where should I get started learning the basics of the SPICE project?
>
> Regards
> Tim Sparg
>
>
> ___
> Spice-devel mailing list
> Spice-devel@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/spice-devel
>
>
___
Spice-devel mailing list
Spice-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/spice-devel

Re: [Spice-devel] Spice-iOS

[Attila Sukosd]

Hi,

Wouldn't an idea be to get the OpenGL version (+ glut?) in a usable
shape? I would guess transitioning it to OpenGL ES shouldn't be too
difficult either for android/ios..

Best Regards,
Attila Sukosd

-
DTU Computing Center - www.cc.dtu.dk
att...@cc.dtu.dk, gba...@student.dtu.dk, s070...@student.dtu.dk




On Fri, Jul 8, 2011 at 9:35 AM, Christophe Fergeau  wrote:
> Hi Cliff,
>
> On Thu, Jul 07, 2011 at 06:12:07PM -0500, Cliff Sharp wrote:
>> I would like to ask a question to extract a fairly detailed response from
>> those who are most familiar with the spice architecture.
>>
>> What (in some detail) would be needed, as far as architecture and
>> software development, to maybe start with the spice-protocol (i.e. as
>> little as possible) and build a command line spice client to run on a
>> platform?
>
> Your best bet might be to look at what spice-glib does, it's part of
> spice-gtk, but it doesn't have any GUI-related dependency, so it should be
> pretty light on deps, and it handles most of the low-level protocol
> interactions with a spice-server. Marc-André might be able to give a more
> detailed description of what this provides.
>
> Christophe
>
> ___
> Spice-devel mailing list
> Spice-devel@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/spice-devel
>
>
___
Spice-devel mailing list
Spice-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/spice-devel

Re: [Spice-devel] Current status of XSpice driver

[Attila Sukosd]

Yes, you do.

The concept is similar to the Xvnc server in the way it works, where
you can spawn any X11 apps by setting the DISPLAY var to the correct X
server.

I'm not sure about extension support though? (Xrandr etc) I guess
since its using Xorg and it is "just" another display driver, all the
other standard Xorg stuff should also be there?

Attila

On Sat, Jun 25, 2011 at 10:02 PM, John A. Sullivan III
 wrote:
> On Sat, 2011-06-25 at 20:38 +0200, Alon Levy wrote:
>> On Sat, Jun 25, 2011 at 06:01:27PM +0200, Sebastian Hesselbarth wrote:
>> > Hi,
>> >
>> > I'd like to ask about the current and future status of the XSpice driver 
>> > for
>> > Xorg. I am very interested in virtualizing desktops for a bunch of users 
>> > without
>> It is in active development, no stable release yet. It's meant to allow 
>> using spice
>> clients to connect to an X server directly, never mind if it is running in a 
>> vm or not.
>> It reuses the X driver, so it has the same features (and lacks the same 
>> features).
>>
>> > the need of a full-blown virtual machine. I once compiled the driver from 
>> > git
>> > but without luck of connecting a client to it (errors were about server and
>> > client disagree about modes AFAIR).
>> >
>> If you used master branch please pull and try again. I have no such 
>> problems, so
>> I'd like to know why it isn't working for you. I'm using master 
>> spice+spice-protocl
>> and just standard X clients. I am compiling against X master, so perhaps 
>> that's the
>> problem. (or maybe I neglected to pull something and I'm actually using an 
>> old version
>> of one of the protos).
>>
>> > Can someone please clarify the requirements for compiling the current 
>> > XSpice
>> > driver. I really like to help improve the driver with debugging, coding, 
>> > and
>> > suggestions.
>> I mainly test it with everything needed built from git. Also, I've just 
>> updated
>> master (forced), but generally the most uptodate right now is the xspice.vN 
>> (N=5 atm).
>>
>> Everything means xserver and other dependencies needed at runtime (xkbcomp 
>> etc.).
>> I haven't documented everything yet, but see README.xspice:
>>  http://cgit.freedesktop.org/~alon/xspice/tree/README.xspice
>>
> 
> Oh wow - I wasn't even aware this existed.  Just to make sure I'm not
> reading something into this which it isn't and to make sure I'm not
> confused by the terminology (e.g., X server and client, SPICE server and
> client) even after reading everything I could find about it, let me see
> if I understand how this works.
>
> We start an X Server on any kind of Linux system - bare metal, lxc
> container, etc.  We can run any kind of X client on that Linux system
> such as kdm or kdesktop and it will use the SPICE enabled X Server as a
> regular X Server.  We then connect a remote SPICE client to the SPICE
> server on that system and are able to see that desktop remotely with all
> the efficiencies of SPICE as if it was running inside of KVM.  Do I
> understand that correctly? Thanks - John
>
> ___
> Spice-devel mailing list
> Spice-devel@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/spice-devel
>
___
Spice-devel mailing list
Spice-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/spice-devel

Re: [Spice-devel] spice-gtk build error - no debug symbols in executable

[Attila Sukosd]

Hi Cliff,

I've hit the same problem, it seems like its the problem with
introspection in MacPorts.

Adding --enable-introspection=no seemed to have solved this issue.
I'm hitting another with vala though:

make  all-recursive
Making all in common
Making all in win
Making all in my_getopt-1.5
make[4]: Nothing to be done for `all'.
make[4]: Nothing to be done for `all-am'.
make[3]: Nothing to be done for `all-am'.
Making all in gtk
make  all-recursive
Making all in controller
make  all-am
make[5]: *** No rule to make target `menu.c', needed by `menu.lo'.  Stop.
make[4]: *** [all] Error 2
make[3]: *** [all-recursive] Error 1
make[2]: *** [all] Error 2
make[1]: *** [all-recursive] Error 1
make: *** [all] Error 2

Anyone has any ideas on this?

Best Regards,
Attila Sukosd

-
DTU Computing Center - www.cc.dtu.dk
att...@cc.dtu.dk, gba...@student.dtu.dk, s070...@student.dtu.dk




On Thu, Jun 23, 2011 at 8:43 PM, Cliff Sharp  wrote:
> I thought I had seen this in a previous email but could not find it. S…
>
>
>
> When attempting to make spice-gtk against the gtk-osx project after
> executing:
>
> ./autogen.sh --with-audio=gstreamer --without-python
> --with-coroutine=gthread --with-gtk=2.0 --enable-smartcard=no
>
>
>
> I get the following error:
>
>
>
>
>
> configure:
>
>
>
>     Spice-Gtk 0.6.111-c275-dirty
>
>     ==
>
>
>
>     prefix:   /Users/gtkosx/gtk/inst
>
>     c compiler:       /usr/bin/gcc-4.2 -std=gnu99
>
>
>
>     Coroutine:    gthread
>
>     Audio:    gstreamer
>
>     Target:   Unix
>
>     SASL support: yes
>
>     Smartcard support:    no
>
>     Gtk:  2.0
>
>
>
>     Now type 'make' to build spice-gtk
>
>
>
>
>
> bash-3.2$ make
>
> make  all-recursive
>
> Making all in common
>
> Making all in win
>
> Making all in my_getopt-1.5
>
> make[4]: Nothing to be done for `all'.
>
> make[4]: Nothing to be done for `all-am'.
>
> make[3]: Nothing to be done for `all-am'.
>
> Making all in gtk
>
>   GEN    spice-marshal.c
>
>   GEN    spice-marshal.h
>
>   GEN    generated_demarshallers.c
>
> Wrote generated_demarshallers.c
>
>   GEN    generated_demarshallers1.c
>
> Wrote generated_demarshallers1.c
>
>   GEN    generated_marshallers.c
>
> Wrote generated_marshallers.c
>
>   GEN    generated_marshallers1.c
>
> Wrote generated_marshallers1.c
>
>   GEN    spice-glib-enums.c
>
>   GEN    spice-glib-enums.h
>
>   GEN    spice-widget-enums.c
>
>   GEN    spice-widget-enums.h
>
>   CC spice-audio.lo
>
>   CC spice-util.lo
>
>   CC spice-session.lo
>
>   CC spice-channel.lo
>
>   CC spice-glib-enums.lo
>
>   CC spice-marshal.lo
>
>   CC generated_demarshallers.lo
>
>   CC generated_demarshallers1.lo
>
>   CC generated_marshallers.lo
>
>   CC generated_marshallers1.lo
>
>   CC gio-coroutine.lo
>
>   CC channel-base.lo
>
>   CC channel-cursor.lo
>
>   CC channel-display.lo
>
>   CC channel-display-mjpeg.lo
>
>   CC channel-inputs.lo
>
>   CC channel-main.lo
>
>   CC channel-playback.lo
>
>   CC channel-record.lo
>
>   CC decode-glz.lo
>
>   CC decode-jpeg.lo
>
>   CC decode-zlib.lo
>
>   CC mem.lo
>
>   CC marshaller.lo
>
>   CC canvas_utils.lo
>
>   CC sw_canvas.lo
>
>   CC pixman_utils.lo
>
>   CC lines.lo
>
>   CC rop3.lo
>
>   CC quic.lo
>
>   CC lz.lo
>
>   CC region.lo
>
>   CC ssl_verify.lo
>
>   CC spice-gstaudio.lo
>
>   CC coroutine_gthread.lo
>
>   CCLD   libspice-client-glib-2.0.la
>
> warning: no debug symbols in executable (-arch i386)
>
>   GISCAN SpiceClientGLib-2.0.gir
>
> g-ir-scanner: SpiceClientGLib: warning: 12 warnings suppressed (use
> --warn-all to see them)
>
>   CC spice-widget.lo
>
>   CC spice-widget-enums.lo
>
>   CC vncdisplaykeymap.lo
>
>   CC spice-grabsequence.lo
>
>   CC spice-widget-cairo.lo
>
>   CCLD   libspice-client-gtk-2.0.la
>
> warning: no debug symbols in executable (-arch i386)
>
>   GISCAN SpiceClientGtk-2.0.gir
>
> Couldn't find include 'Gtk-2.0.gir' (search path: ['.',
> '/Users/gtkosx/gtk/inst/share/gir-1.0',
> '/Users/gtkosx/gtk/inst/share/gir-1.0', '/usr/share/gir-1.0',
> '/Users/gtkosx/gtk/inst/share/gir-1.0'])
>
> make[2]: *** [SpiceClientGtk-2.0.gir] Error 1
>
> make[1]: *** [all-recursive] Error 1
>
> make: *** [all] Error 2
>
>
>
> Can anyone provide some insight.
>
> Thanks
>
>
>
>
>
> ___
> Spice-devel mailing list
> Spice-devel@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/spice-devel
>
>
___
Spice-devel mailing list
Spice-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/spice-devel

Re: [Spice-devel] Streaming video performance concepts

[Attila Sukosd]

How about WebM?
http://www.webmproject.org/

Sounds like it could be useful :)

Best Regards,
Attila Sukosd

-
DTU Computing Center - www.cc.dtu.dk
att...@cc.dtu.dk, gba...@student.dtu.dk, s070...@student.dtu.dk




On Thu, Jun 23, 2011 at 1:58 AM, John A. Sullivan III
 wrote:
> On Wed, 2011-06-22 at 23:49 +0200, Alon Levy wrote:
>> On Wed, Jun 22, 2011 at 03:44:40PM -0400, John A. Sullivan III wrote:
>> > On Wed, 2011-06-22 at 17:01 +0200, Alon Levy wrote:
>> > > On Wed, Jun 22, 2011 at 09:56:28AM -0400, John A. Sullivan III wrote:
>> > > > On Wed, 2011-06-22 at 11:27 +0200, Alon Levy wrote:
>> > > > > > Thank you very much for the explanation.  It's pretty much 
>> > > > > what I
>> > > > > > expected - that the codec is different, trading CPU efficiency for
>> > > > > > bandwidth inefficiency and I certainly understand the reasons why.
>> > > > > >
>> > > > > > Is there any thought or plan to make the codec configurable for 
>> > > > > > those
>> > > > > > who are willing to sacrifice CPU for bandwidth, e.g., VP8, Theora, 
>> > > > > > or
>> > > > > > H.264?
>> > > > > >
>> > > > >
>> > > > > I haven't done any testing on this but I think the cpu requirements 
>> > > > > are large.
>> > > > > maybe with hardware doing the encoding this would work well enough. 
>> > > > > Technically
>> > > > > just dropping in a different codec and extending the protocol 
>> > > > > doesn't sound like
>> > > > > a lot of work. Patches welcome?
>> > > > 
>> > > > I wish I had the skill set to help in that way! Thanks - John
>> > > >
>> > > Would you be able to provide some benchmarks (choose some pc you have) 
>> > > for:
>> > >  encoding speed of
>> > >   VP8, Theora, H.264
>> > >  for various bitdepths and resolutions (you choose, maybe just one - 
>> > > take the resolutions
>> > >  of a normal youtube window and a fullscreen of your choice).
>> > > ?
>> > >
>> > > Alon
>> > >
>> > I would be delighted to do so if it will help.  I don't have a clue how
>> > to.  If you have a link or reference you can point me to, that would be
>> > appreciated. Otherwise, it will be off to the world of Internet
>> > research.  Thanks - John
>>
>> It's been pointed to me off list that my suggestion was very inaccurate, and 
>> that perhaps
>> we have other considerations, like prefering an open (source, no patents) 
>> codec like
>> Theora even if it is worse then H.264 / VP8. Yaniv gave a link to an already 
>> old but
>> interesting comparison: http://keyj.emphy.de/video-encoder-comparison/
>>
>> >
> I believe H.264 is heavily patent encumbered even though free but I also
> thought that VP8 was now not patent encumbered and as readily usable as
> theora. It would seem to be the ideal candidate if using it as a real
> time codec is feasible.  Again, I'm way out of my depth and merely
> spewing a couple of hours of Internet research.  Thanks - John
>
> ___
> Spice-devel mailing list
> Spice-devel@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/spice-devel
>
___
Spice-devel mailing list
Spice-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/spice-devel

Re: [Spice-devel] spice does not want to connect to the server when using the external ip address

[Attila Sukosd]

Hi Stephen,

Based on your ifconfig it seems like your trying to access the
physical host behind a NAT?

Did you by any chance forgot to you forward port 5900 to the machine?


Best Regards,
Attila Sukosd

-
DTU Computing Center - www.cc.dtu.dk
att...@cc.dtu.dk, gba...@student.dtu.dk, s070...@student.dtu.dk




On Wed, Jun 22, 2011 at 8:34 AM, Stephen Duse-Anthony
 wrote:
> Hi,
> I'm new at using qemu and spicec.
> I was able to generate two virtual  machine. When I'm inside my network I
> can view the virtual machine with spicec using the internal IP address.
> When I try to  use the external IP address I have connection actively
> refused.
> I'm sure I'm missing something when I run qemu or in the configuration file.
> Can anybody help?
> Below some details of what I have:
>
> 1/ [root@fedora15 .spicec]# ifconfig
> lo    Link encap:Local Loopback
>   inet addr:127.0.0.1  Mask:255.0.0.0
>   inet6 addr: ::1/128 Scope:Host
>   UP LOOPBACK RUNNING  MTU:16436  Metric:1
>   RX packets:381 errors:0 dropped:0 overruns:0 frame:0
>   TX packets:381 errors:0 dropped:0 overruns:0 carrier:0
>   collisions:0 txqueuelen:0
>   RX bytes:28226 (27.5 KiB)  TX bytes:28226 (27.5 KiB)
>    &nbs
> p;
> p3p1  Link encap:Ethernet  HWaddr BC:AE:C5:EA:AB:84
>   inet addr:192.168.1.100  Bcast:192.168.1.255
> Mask:255.255.255.0
>   inet6 addr: fe80::beae:c5ff:feea:ab84/64 Scope:Link
>   UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
>   RX packets:24037 errors:0 dropped:0 overruns:0
> frame:0
>   TX packets:19904 errors:0 dropped:0 overruns:0 carrier:0
>   collisions:0
> txqueuelen:1000
>   RX bytes:11861145 (11.3 MiB)  TX bytes:5163210 (4.9 MiB)
>   Interrupt:46 Base address:0x6000
>
> virbr0    Link encap:Ethernet  HWaddr
> FE:54:00:42:9A:13
>   inet addr:192.168.122.1  Bcast:192.168.122.255
> Mask:255.255.255.0
>   UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
>   RX packets:57 errors:0 dropped:0 overruns:0 frame:0
>   TX packets:909 errors:0 dropped:0 overruns:0 carrier:0
>   collisions:0 txqueuelen:0
>   RX bytes:10492 (10.2 KiB)  TX bytes:48313 (47.1 KiB)
>
> vnet0 Link encap:Ethernet  HWaddr FE:54:00:42:9A:13
>   inet6 addr: fe80::fc54:ff:fe42:9a13/64 Scope:Link
>   UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
>   RX packets:30 errors:0 dropped:0 overruns:0 frame:0
>   TX packets:239 errors:0 dropped:0 overruns:0 carrier:0
>   collisions:0 txqueuelen:500
>   RX bytes:5654 (5.5 KiB)  TX bytes:17686 (17.2 KiB)
>
> vnet1 Link encap:Ethernet  HWaddr FE:54:00:EB:40:73
>   inet6 addr: fe80::fc54:ff:feeb:4073/64 Scope:Link
>   UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
>   RX packets:31 errors:0 dropped:0 overruns:0 frame:0
>   TX packets:236 errors:0 dropped:0 overruns:0 carrier:0
>   collisions:0 txqueuelen:500
>   RX bytes:5996 (5.8 KiB)  TX bytes:17526 (17.1 KiB)
>
>
> 2/ ps -elf | grep qemu
> 6 S qemu 15226 1  6  80   0 - 619025 poll_s 23:00 ?   00:00:27
> /usr/bin/qemu-kvm -S -M pc-0.14 -enable-kvm -m 2000 -smp
> 2,sockets=2,cores=1,threads=1 -name vm0_fed15 -uuid
> b3cf1b4b-f9ed-f7bd-2bcf-6f59aee90f09 -nodefconfig -nodefaults -chardev
> socket,id=charmonitor,path=/var/lib/libvirt/qemu/vm0_fed15.monitor,server,nowait
> -mon chardev=charmonitor,id=monitor,mode=control -rtc base=utc -boot c
> -device virtio-serial-pci,id=virtio-serial0,bus=pci.0,addr=0x6 -drive
> file=/var/lib/libvirt/images/vm0_fed15.img,if=none,id=drive-ide0-0-0,format=raw
> -device ide-drive,bus=ide.0,unit=0,drive=drive-ide0-0-0,id=ide0-0-0 -drive
> if=none,media=cdrom,id=drive-ide0-1-0,readonly=on,format=raw -device
> ide-drive,bus=ide.1,unit=0,drive=drive-ide0-1-0,id=ide0-1-0 -netdev
> tap,fd=21,id=hostnet0 -device
> rtl8139,netdev=hostnet0,id=net0,mac=52:54:00:42:9a:13,bus=pci.0,addr=0x3
> -chardev pty,id=charserial0 -device
> isa-serial,chardev=charserial0,id=serial0 -chardev
> spicevmc,id=charchannel0,name=vdagent -device
> virtserialport,bus=virtio-serial0.0,nr=1,chardev=charchannel0,id=channel0,name=com.redhat.spice.0
> -usb -spice port=5900,addr=0.0.0.0,disable-ticketing -vga cirrus -device
> intel-hda,id=sound0,bus=pci.0,addr=0x4 -device
> hda-duplex,id=sound0-codec0,bus=sound0.0,cad=0 -device
> virtio-balloon-pci,id=balloon0,bus=pci.0,addr=0x5
> 6 S qemu 15239 1  5  8

Re: [Spice-devel] Video buffering

[Attila Sukosd]

Hi John,

Did you check the guest cpu usage while playing back youtube?

We have noticed that the bad video playback performance with flash was
due to it using up all of the guest CPU, and of course it does not
improve a lot by giving the VM more cores either... (ok this was on a
12 core AMD, where the cpu speed isn't as high per core as for other
cpus)

Switching to HTML5 playback on youtube gave about the same video
performance as playing it with VLC, and we could play back 720p over a
15mbit DSL line with an acceptable overall performance.


Best Regards,
Attila Sukosd

-
DTU Computing Center - www.cc.dtu.dk
att...@cc.dtu.dk, gba...@student.dtu.dk, s070...@student.dtu.dk




On Sat, Jun 18, 2011 at 8:17 PM, John A. Sullivan III
 wrote:
> Hello, all.  We spent some time testing audio and video performance with
> SPICE today with mixed results.  Talking heads and some movement were
> reasonably acceptable.  However we tried some music and ballet videos to
> get lots of movement and the results were unusable - Rite of Spring was
> more like Frozen Ice of Winter.  These were not full screen - simple
> YouTube type video using an cable Internet connection - several Mbps
> download, a couple upload.
>
> We are thus thinking of pursuing our plans to wrap SPICE inside X2Go so
> we can use the new mimebox facility and offer users the choice of either
> the streaming SPICE video approach or the more Citrix like download and
> play locally approach.
>
> I'm guessing the problem is buffering.  If the pipe isn't big enough, it
> just isn't going to get through in a usable way - stuttering and
> starting all over the place.  Are there any plans to build some sort of
> buffering into SPICE when it detects a video stream?
>
> I'm sure many are thinking likewise but we are looking at video as not
> just a technology shift but a huge long term cultural shift almost as
> large as the printing press so we see any VDI solution which does not
> address video despite the huge technical hurdles as inadequate.
>
> We have already been told by some schools that they could not use our
> X2Go VDI model because of their need for video.  Likewise, adoption has
> been delayed by some large PR / Communications companies because of a
> lack of video support.  As we look at consumerization of VDI for
> potential service to lower income users, video is a potential show
> stopper.
>
> Enough of teaching Grandma to suck eggs but this is why we are so
> enthusiastic about SPICE - at least it has a fighting chance with video.
> So we look forward to integrating with X2Go and would love to know if
> there is a plan (or even an existing way) to implement buffering in
> SPICE.  Thanks - John
>
> ___
> Spice-devel mailing list
> Spice-devel@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/spice-devel
>
___
Spice-devel mailing list
Spice-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/spice-devel

Re: [Spice-devel] Spice connection bandwidth utilization

[Attila Sukosd]

Hi

We are getting around 10-15Mbps for 720p full screen at 1280x1024.
This is with the 0.8 client and 0.4 on the server.

Best Regards,
Attila Sukosd

-
DTU Computing Center - www.cc.dtu.dk
att...@cc.dtu.dk


On Wed, Jun 15, 2011 at 5:07 AM, Bitman Zhou  wrote:
> Hi,
>
> You can use etherape (linux platform) to watch the bandwidth utilization
> of a spice connection. My case is 30~50Mbps when playing full screen
> video.
>
> BR
> Bitman Zhou
>
> 在 2011-06-15三的 10:16 +0800，Binbin Wang写道：
>> Hi Spice-devel,
>>
>> I am testing the spice connection bandwidth utilization.
>>
>> For example, if play a video (overall bps = 255) via spice connection
>> (100Mb/s networking environment), how much bandwidth it will take?
>>
>> Are there any testing experience or data before?
>>
>> Regards & Thanks!
>> Binbin
>>
>>
>> --
>> Wang.bupt
>> ___
>> Spice-devel mailing list
>> Spice-devel@lists.freedesktop.org
>> http://lists.freedesktop.org/mailman/listinfo/spice-devel
>
>
> ___
> Spice-devel mailing list
> Spice-devel@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/spice-devel
>
___
Spice-devel mailing list
Spice-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/spice-devel

Re: [Spice-devel] Android Emulator

[Attila Sukosd]

I guess he wants to run the spice client using the opengl canvas.


On Wed, May 11, 2011 at 9:21 PM, Alon Levy  wrote:

> On Mon, May 09, 2011 at 10:48:55PM +1200, Thomas Lynch wrote:
> > Hi there, is it possible to put the virtual GPU into the Android
> > Emulator to get it to do some simple OpenGL output?
> > Regards
>
> Spice's virtual GPU doesn't support OpenGL yet so it won't help you.
>
> > ___
> > Spice-devel mailing list
> > Spice-devel@lists.freedesktop.org
> > http://lists.freedesktop.org/mailman/listinfo/spice-devel
> ___
> Spice-devel mailing list
> Spice-devel@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/spice-devel
>
___
Spice-devel mailing list
Spice-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/spice-devel

Re: [Spice-devel] spicec and spice-gtk

[Attila Sukosd]

There is only an alsa implementation for the *nix side of spicec.

I've got a playback only implementation for PortAudio which is available
from OSX. I haven't tried it against the latest git though...


On Thu, Apr 28, 2011 at 10:57 PM, Cliff Sharp  wrote:

> I have spice-gtk built and running on OSX. It has some issues but it does
> connect. I am in the process of testing this now.
>
> I am trying to build the spice cient spicec (spice-0.8.1) on OSX.
> I am having major troubles with the alsa package.
> It is not in MacPorts.
> Does anyone know if there is a OSX port for alsa yet?
> OR
> Is there a way of specifying the use of an alternative package when
> building (i.e. gstreamer)?
> With spice-gtk you can specify on the configure command line
> --with-audio=gstreamer but this does not seem to work with spice-0.8.1?
>
> Thanks
>
> On Apr 28, 2011, at 7:08 AM, Kai Mosebach wrote:
>
> # find / -name "libglib*"
> /Applications/Adium.app/Contents/Frameworks/libglib.framework
> /Applications/Adium.app/Contents/Frameworks/libglib.framework/libglib
> /Applications/Adium.app/Contents/Frameworks/libglib.framework/Versions/2.0.
> 0/libglib
> /opt/local/lib/libglib-2.0.0.dylib
> /opt/local/lib/libglib-2.0.a
> /opt/local/lib/libglib-2.0.dylib
> /opt/local/lib/libglib-2.0.la
>
>
> $ which spicy
> /usr/local/bin/spicy
> $ otool -L /usr/local/bin/spicy|grep glib
>/usr/local/lib/libspice-client-glib-2.0.2.dylib (compatibility
> version 3.0.0, current version 3.1.0)
>/opt/local/lib/libglib-2.0.0.dylib (compatibility version
> 2801.0.0, current version 2801.5.0)
>
>
> $ locate glib.h
> /opt/local/include/glib-2.0/glib.h
>
>
> Well hope that¹s prove enough ;-)
>
> Were are all these #define's defined anyway? Couldn¹t we ask if #ifdef
> __MACOSX__ or similar at this point?
>
> On 4/28/11 10:37 AM, "Christophe Fergeau"  wrote:
>
> Until proven otherwise, I'll assume it's a mismatch between several glibs
>
> :) To figure it out, looking at make V=1, checking which versions of glib
>
> are available on the system (find / -name "libglib*"), maybe looking at
>
> what ldd say, ... would be helpful
>
>
> Christophe
>
>
>
>
>
> 
>
> *Cliff Sharp* | *csh...@vbridges.com*
>
>
>
>
>
>
>
>
> ___
> Spice-devel mailing list
> Spice-devel@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/spice-devel
>
>
___
Spice-devel mailing list
Spice-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/spice-devel

Re: [Spice-devel] OSX spice-gtk and pyparsing

[Attila Sukosd]

Thats how far I got too :)

On Wed, Apr 27, 2011 at 7:47 PM, Kai Mosebach  wrote:

>
>
> >On Wed, Apr 27, 2011 at 06:36:24PM +0200, Kai Mosebach wrote:
> >>and why the bandwidth increases by ~70% compared to the spicec.exe from
> >> windows?
> >
> >The bandwidth thing is just a result of using a different client? that is
> >very bizzarre, since it's all server->client and there is no negotiation
> >that could affect the compression scheme.
>
> Its a different client (spicec.exe 0.8.0 (windows) vs. spice-gtk-0.5 (OSX)
>
> >Sound wise - is gstreamer working standalone (gst-launch audiotestsrc !
> >autoaudiosink,
> >should hear a pure tone)? that's what spice-gtk should be using I think.
>
> To get a valid audiosink for OSX one has to install the macport
> gst-plugins-good
>
> Now it segfaults though :-( im looking into it.
>
>
>
___
Spice-devel mailing list
Spice-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/spice-devel

Re: [Spice-devel] OSX spice-gtk and pyparsing

[Attila Sukosd]

Yea, you can even just take the pyparsing.py from the .tgz and put it in the
source base dir. (where you run make from)

Best Regards,

Attila Sukosd

-
DTU Computing Center - www.cc.dtu.dk
att...@cc.dtu.dk, gba...@student.dtu.dk, s070...@student.dtu.dk




On Wed, Apr 27, 2011 at 6:28 PM, Alon Levy  wrote:

> On Wed, Apr 27, 2011 at 11:07:55AM -0500, Cliff Sharp wrote:
> > When building spice-gtk after loading tons of MacPorts dependencies -- I
> was getting the following error.
>
> To build from git (not from source tar balls) you need pyparsing. I think
> it's pure python, so should pose
> absolutely no problem to install even if no MacPort exists. I don't have a
> mac so I can't check.
>
> http://pyparsing.wikispaces.com/
>
> >
> > make  all-recursive
> > Making all in common
> > Making all in win
> > Making all in my_getopt-1.5
> > make[4]: Nothing to be done for `all'.
> > make[4]: Nothing to be done for `all-am'.
> > make[3]: Nothing to be done for `all-am'.
> > Making all in gtk
> >   GENspice-marshal.c
> >   GENspice-marshal.h
> >   GENgenerated_demarshallers.c
> > Traceback (most recent call last):
> >   File "../spice_codegen.py", line 7, in 
> > from python_modules import spice_parser
> >   File
> "/Users/csharp/src/spice-gtk/spice-gtk-0.5/python_modules/spice_parser.py",
> line 1, in 
> > from pyparsing import Literal, CaselessLiteral, Word, OneOrMore,
> ZeroOrMore, \
> > ImportError: No module named pyparsing
> > make[2]: *** [generated_demarshallers.c] Error 1
> > make[1]: *** [all-recursive] Error 1
> > make: *** [all] Error 2
> >
> > I could not find pyparsing in MacPorts via the port list command. I did
> find and load
> > py-parsing @1.5.1  python/py-parsing
> > py25-parsing   @1.5.1  python/py25-parsing
> > py26-parsing   @1.5.2  python/py26-parsing
> > py27-parsing   @1.5.5  python/py27-parsing
> >
> > But none of these resolved the issue.
> >
> > So I downloaded pyparsing-1.5.5.tar.gz from
> http://distfiles.macports.org/python/
> > and installed it via "python setup.py install" which resolved the issue.
> >
> >
> > 
> >
> > Cliff Sharp | csh...@vbridges.com
> >
> >
> >
> >
> >
> >
> >
>
> > ___
> > Spice-devel mailing list
> > Spice-devel@lists.freedesktop.org
> > http://lists.freedesktop.org/mailman/listinfo/spice-devel
>
> ___
> Spice-devel mailing list
> Spice-devel@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/spice-devel
>
___
Spice-devel mailing list
Spice-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/spice-devel

Re: [Spice-devel] Spice on OS/X

[Attila Sukosd]

Hi,


This might be a stupid question, but why don't you try to use spice-gtk on
OS/X instead of spicec ?
It has everything needed, such as gtk2/gtk3 and gstreamer for audio, all
cross platform.

Rgrds,

Attila


On Mon, Apr 25, 2011 at 11:34 PM, Cliff Sharp  wrote:

>  When trying to port the alsa-lib to OS/X while porting Spice to OS/X I am
> having some difficulties resolving issues with alsa-lib. I am using
> alsa-lib-1.0.24.1
>
> After doing a ./configure - I have also tried
> ./configure --enable-shared=no --enable-static=yes
>
> Either way I get the following error in the middle ---
> ./configure: line 18735: CC_NOUNDEFINED: command not found
>
> ___
>
> And then the end of the ./configure looks like this ---
>
> configure: creating ./config.status
> config.status: creating Makefile
> config.status: creating doc/Makefile
> config.status: creating doc/pictures/Makefile
> config.status: creating doc/doxygen.cfg
> config.status: creating include/Makefile
> config.status: creating include/sound/Makefile
> config.status: creating src/Versions
> config.status: creating src/Makefile
> config.status: creating src/control/Makefile
> config.status: creating src/mixer/Makefile
> config.status: creating src/pcm/Makefile
> config.status: creating src/pcm/scopes/Makefile
> config.status: creating src/rawmidi/Makefile
> config.status: creating src/timer/Makefile
> config.status: creating src/hwdep/Makefile
> config.status: creating src/seq/Makefile
> config.status: creating src/ucm/Makefile
> config.status: creating src/compat/Makefile
> config.status: creating src/alisp/Makefile
> config.status: creating src/conf/Makefile
> config.status: creating src/conf/cards/Makefile
> config.status: creating src/conf/pcm/Makefile
> config.status: creating modules/Makefile
> config.status: creating modules/mixer/Makefile
> config.status: creating modules/mixer/simple/Makefile
> config.status: creating alsalisp/Makefile
> config.status: creating aserver/Makefile
> config.status: creating test/Makefile
> config.status: creating test/lsb/Makefile
> config.status: creating utils/Makefile
> config.status: creating utils/alsa-lib.spec
> config.status: creating utils/alsa.pc
> config.status: creating include/config.h
> config.status: include/config.h is unchanged
> config.status: executing depfiles commands
> Creating asoundlib.h...
>
> Does this look like the ./configure completed successfully???
>
> __
>
> Then as a result of the make I get the following ---
>
> Making all in doc
> Making all in pictures
> make[2]: Nothing to be done for `all'.
> make[2]: Nothing to be done for `all-am'.
> Making all in include
> make  all-recursive
> Making all in sound
> make[3]: Nothing to be done for `all'.
> Making all in src
> Making all in control
>  CC cards.lo
>  CC tlv.lo
>  CC namehint.lo
>  CC hcontrol.lo
>  CC control.lo
> /var/folders/Pv/PvC+gYnqE1aH2WUpUaGMJk+++TI/-Tmp-//cctnQSSU.s:6097:Expected
> comma after segment-name
> /var/folders/Pv/PvC+gYnqE1aH2WUpUaGMJk+++TI/-Tmp-//cctnQSSU.s:6101:Expected
> comma after segment-name
> /var/folders/Pv/PvC+gYnqE1aH2WUpUaGMJk+++TI/-Tmp-//cctnQSSU.s:6101:Rest of
> line ignored. 1st junk character valued 32 ( ).
> /var/folders/Pv/PvC+gYnqE1aH2WUpUaGMJk+++TI/-Tmp-//cctnQSSU.s:6593:Unknown
> pseudo-op: .symver
> /var/folders/Pv/PvC+gYnqE1aH2WUpUaGMJk+++TI/-Tmp-//cctnQSSU.s:6593:Rest of
> line ignored. 1st junk character valued 95 (_).
> /var/folders/Pv/PvC+gYnqE1aH2WUpUaGMJk+++TI/-Tmp-//cctnQSSU.s:6637:Unknown
> pseudo-op: .symver
> /var/folders/Pv/PvC+gYnqE1aH2WUpUaGMJk+++TI/-Tmp-//cctnQSSU.s:6637:Rest of
> line ignored. 1st junk character valued 95 (_).
> make[2]: *** [control.lo] Error 1
> make[1]: *** [all-recursive] Error 1
> make: *** [all-recursive] Error 1
>
> I haven't been able to quite figure out what is going with the make errors.
> I would appreciate it if someone would be able to give me some hints.
>
> Thanks
>
> 
>
>
>
>
>
> ___
> Spice-devel mailing list
> Spice-devel@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/spice-devel
>
>
___
Spice-devel mailing list
Spice-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/spice-devel

Re: [Spice-devel] Building celt-0.5.1.3 on OSX - Undefined symbols for architecture x86_64

[Attila Sukosd]

Hi,

I've also got similar errors during the test, but seemed to work fine
regardless... (Of course its not very optimal)

Best Regards,

Attila
On Mon, Apr 11, 2011 at 9:52 AM, Christophe Fergeau wrote:

> Hi Cliff,
>
> On Sat, Apr 09, 2011 at 06:04:38PM -0500, Cliff Sharp wrote:
> > Undefined symbols for architecture x86_64:
> >   "_ec_ilog", referenced from:
> >   _ec_enc_uint in ectest.o
> >   _ec_dec_uint in ectest.o
> >   _ec_enc_tell in ectest.o
> >   _ec_dec_tell in ectest.o
> >   _log2_frac in ectest.o
> >   _imusdiv32even in ectest.o
>
> It looks like these symbols should be defined in the libcelt that was
> just built (assuming the leading _ is something that is added to all
> public symbols in osx). However, looking at tests/Makefile.am and at
> your gcc link line, I see no reference to linking the examples to
> libcelt.
>
> Can you try adding
> ectest_LDADD = $(top_builddir)/libcelt/libcelt@PACKAGE_APPEND@.la
> to tests/Makefile.am, and regenerate the autofoo (running autoreconf -fi
> and then configure is generally enough). Similar errors might happen for
> other test files, in which case you'll want to try a similar fix, just
> changing the "ectest" prefix.
>
> Let me know if this helps,
>
> Christophe
>
> ___
> Spice-devel mailing list
> Spice-devel@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/spice-devel
>
>
___
Spice-devel mailing list
Spice-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/spice-devel

Re: [Spice-devel] Porting snappy/libspicec-glib.so onto Android-ARM

[Attila Sukosd]

Hi,

Looks great! As soon as I get my hands on an Android tablet, I
will definitely give it a go :)

Best Regards,

Attila Sukosd

-
DTU Computing Center - www.cc.dtu.dk
att...@cc.dtu.dk


On Thu, Mar 31, 2011 at 10:10 AM, Shuxiang Lim wrote:

> Mae govannon!
>  Well,this has nearly been solved by recross-compiling the openssl
> statically and building libssl/libcrpt.a into libspicec, but I still cannot
> use the system ones, never mind.
> *root@gnollwood:/angmar/gtk/spice-gtk-0.5/gtk# l libspicec.so snappy
> -rwxr-xr-x 1 root root 5.6M 2011-03-31 15:54 libspicec.so
> -rwxr-xr-x 1 root root  62K 2011-03-31 15:54 snappy
> now the libspicec has "NO" dependences at all!
> Namaarie!
>
> *
>
> On Thu, Mar 31, 2011 at 3:15 PM, Shuxiang Lim wrote:
>
>> Hi,
>>   I wonder if there anybody has tried my solution,for I've got no feedback
>> till now?
>>   Now,because the deps of spicec-gtk are so MANY,thus use the static libs
>> shall be economic,
>> hence the new snappy/libspicec.so:
>> *# arm-eabi-readelf -d libspicec.so
>> Dynamic section at offset 0x38bf98 contains 22 entries:
>>   TagType Name/Value
>>  0x0001 (NEEDED) Shared library: [libdl.so]
>>  0x0001 (NEEDED) Shared library: [libstdc++.so]
>>  0x0001 (NEEDED) Shared library: [libz.so]
>>  0x0001 (NEEDED) Shared library: [libc.so]
>>  0x0001 (NEEDED) Shared library: [libcrypto.so]
>>  0x0001 (NEEDED) Shared library: [libssl.so]
>>  0x0001 (NEEDED) Shared library: [libm.so]
>> ...*
>> all the deps of libspicec.so can be found in android system,the other deps
>> such as glibs are all built staticaly into libspicec.
>>   But I got another bug, when staticaly linked,libcrypto and libssl will
>> spit SEGFAULT in running(the same as when using the shared ones in Android
>> system),but my self-compiled shared libssl and libcrypto work well, why?
>> Does this mean there is some buggy use in
>> spice-channel.c :spice_channel_send_auth()? The static or system's shared
>> libssl/libcrypto always die at RSA_size() or BIO_free() in
>> spice_channel_send_auth()).
>>   Would Somebody do a try or check on this?
>>   I'm keen on that.
>>   Rgrds.
>>
>>
>> On Fri, Mar 25, 2011 at 3:52 PM, Shuxiang Lim wrote:
>>
>>> Hi!
>>>   There already exist libssl.so and libcrypto.so in Android (in
>>> /system/lib/ of my device),
>>> but my snappy/libspicec.so got only SEGFAULT if using them,I hope someone
>>> has time to check why.
>>>   Besides these. All the functions in snappy/libspicec.so works well with
>>> all my built libs.
>>>   .eg. I use this cmd to start qemu to fore the use
>>> pixman/jpeg/zlib/openssl:
>>> *#sudo qemu-system-x86_64 ... -spice port=5900,password=gnoll,\
>>> jpeg-wan-compression=always,\
>>> zlib-glz-wan-compression=always
>>>On the device:
>>> #LD_LIBRARY_PATH=./lib ./snappy -h 192.168.1.31 -p 5900 -w gnoll -o
>>> ahoo.ppm
>>> (snappy:3157): GSpice-DEBUG: spice-session.c:803 session: disconnecting 0
>>> (snappy:3157): GSpice-DEBUG: spice-channel.c:127 main-1:0:
>>> spice_channel_constructed
>>> (snappy:3157): GSpice-DEBUG: spice-channel.c:1400 Open coroutine starting
>>> 0x22018
>>> (snappy:3157): GSpice-DEBUG: spice-channel.c:1257 Started background
>>> coroutine 0x22044
>>> (snappy:3157): GSpice-DEBUG: spice-session.c:900 Resolving host
>>> 192.168.1.31 5900
>>> (snappy:3157): GSpice-DEBUG: spice-session.c:913 Trying one socket
>>> (snappy:3157): GSpice-DEBUG: spice-session.c:864 Socket pending
>>> (snappy:3157): GSpice-DEBUG: spice-session.c:879 Finally connected
>>> (snappy:3157): GSpice-DEBUG: spice-channel.c:931 main-1:0:
>>> spice_channel_recv_link_msg: 0 caps
>>> (snappy:3157): GSpice-DEBUG: spice-channel.c:793 main-1:0: channel up,
>>> state 5
>>> (snappy:3157): GSpice-DEBUG: spice-session.c:1015 set mm time: 25115964
>>> (snappy:3157): GSpice-DEBUG: spice-channel.c:127 cursor-4:0:
>>> spice_channel_constructed
>>> (snappy:3157): GSpice-DEBUG: spice-channel.c:127 display-2:0:
>>> spice_channel_constructed
>>> (snappy:3157): GSpice-DEBUG: spice-channel.c:127 inputs-3:0:
>>> spice_channel_constructed
>>> (snappy:3157): GSpice-DEBUG: spice-channel.c:1400 Open coroutine starting
>>> 0x2a0

Re: [Spice-devel] spice 0.6.3 slower than 0.4?

[Attila Sukosd]

Hi,

On Mon, Mar 14, 2011 at 10:28 AM, Hans de Goede  wrote:

> Hi,
>
>
>
> On 03/14/2011 10:00 AM, Vermonden David wrote:
>
>> Thanks for your quick response!
>>
>>
>> Slower when I play a movie (tried serveral). For instance when playing a
>> need for speed full HD movie it goes very smooth with spice 0.4 with
>> correct sound synchronisation but when using 0.6.3 or 0.8 it shocks
>> (when heavy action it's almost a slide show) and the sound isn't
>> syncronised anymore.
>>
>>
> I think we indeed may have some regressions wrt streaming video
> performance. Someone needs to look into this I guess ...
>
> Hmm, thats strange. We've been seeing much better performance in video
streaming with the latest 0.8 client with the 0.4 server.

In earlier releases there were problems with the video not updating unless
the window was scrolled, but that is gone now too.


Regards,

Attila

Regards,
>
> Hans
>
> ___
> Spice-devel mailing list
> Spice-devel@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/spice-devel
>
___
Spice-devel mailing list
Spice-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/spice-devel

Re: [Spice-devel] Try to port spicec into Android

[Attila Sukosd]

Could you maybe give access to other devs to aid the development?

Rgrds,

Attila

On Wed, Mar 9, 2011 at 11:18 AM, Shuxiang Lim  wrote:

> Yep, I walked around this but to face more chored and nasty troubles in
> porting Pulseaudio lib, time limited, so I decided to DISABLE the
> audio(playback/record) channels first. Thus the porting of libspicec_glib.so
> is finished(along with all its dependences) and androidVNCViewer(whose UI
> will be peeled to become spicec's) proj. has been built:
> *#file libspicec_glib.so *
> libspicec_glib.so: ELF 32-bit LSB shared object, ARM, version 1 (SYSV),
> dynamically linked, not stripped
> *#arm-eabi-readelf -d libspicec_glib.so *
> Dynamic section at offset 0x774a4 contains 27 entries:
>   TagType Name/Value
>  0x0001 (NEEDED) Shared library: [libc.so]
>  0x0001 (NEEDED) Shared library: [libm.so]
>  0x0001 (NEEDED) Shared library: [libpixman-1.so.0]
>  0x0001 (NEEDED) Shared library: [libssl.so.1.0.0]
>  0x0001 (NEEDED) Shared library:
> [libcrypto.so.1.0.0]
>  0x0001 (NEEDED) Shared library: [libjpeg.so.62]
>  0x0001 (NEEDED) Shared library: [libz.so]
>  0x0001 (NEEDED) Shared library: [libglib-2.0.so.0]
>  0x0001 (NEEDED) Shared library: [libgio-2.0.so.0]
>  0x0001 (NEEDED) Shared library:
> [libgobject-2.0.so.0]
>  0x0001 (NEEDED) Shared library:
> [libgmodule-2.0.so.0]
>  0x0001 (NEEDED) Shared library:
> [libgthread-2.0.so.0]
>  0x0010 (SYMBOLIC)   0x0
>  
> Now comes the last adventure of Native interfaces exposing and UI building!
>  Regards.
>
>
> On Wed, Mar 9, 2011 at 3:57 PM, Shuxiang Lim wrote:
>
>> Well, I think I may try the "--with-coroutine=gthread" in spice-gtk
>> configuring to walk around that...
>>
>>
>> On Wed, Mar 9, 2011 at 11:10 AM, Shuxiang Lim wrote:
>>
>>> Hi,I need help!
>>>   Now I've managed to divided spicec-gtk into two parts
>>> libspicec.so(based on libpixman.so,libglib-2.0.so...No relation to X11 at
>>> all) and spicec(based on libspicec.so and libgtk.so...). And the glib2.0
>>> porting to Android is also completed. But I'm blocked in compiling libspicec
>>> onto Android at the begining for the continuation.c uses the functions in
>>>  :setcontext(),getcontext()..., which are some thread-related
>>> funcs as I know,and, definitely unsuprisingly, Android libc doesn't have
>>> them! Is there a way to drop or replace the use of such funcs? Or should I
>>> manually write setcontext from scratch?
>>>   RGRDs.
>>>
>>>
>>> On Mon, Mar 7, 2011 at 5:14 PM, Alon Levy  wrote:
>>>
 On Mon, Mar 07, 2011 at 09:08:28AM +0800, Shuxiang Lim wrote:
 > Option 1: use spice-gtk with a gtk android backend
 > a) compiling gtk for it would be possible.
 > b) write a partial gtk backend, good enough for spice-gtk.
 > c) no changes to spice-gtk.
 >Yep,that's really a good hope,but it's another project(too huge and
 far
 > away for me now):
 > Project:"GTK for Android.". So now I can use only the Android SDK to
 finish
 > the UI(the new native UI APIs in NDK is not reliable in versions).

 Yeah, I think you're right, I can't find anyone already working on this
 by
 simple web search. Maybe spice-gtk's non ui objects are dependent only
 on
 gobject / stuff that is easy to just drop in (ugly, but still more
 maintainable
 then basing your work on spicec, long term).

 >And also you've referred that "spicec is already platform
 independent",
 > that's true to Linux and Windows,but not to Android,for such
 independence is
 > based on the C++ independence over the os which cannot stand through
 the
 > JAVA UIed android.So there is no way to just add a subdir ./android
 under
 > spice/client along with ./x11 and ./windows. It should be a combined
 proj.
 > of C/C++ and Java. (That's why I hate Android and yearn for
 Maemo/Meego.)

 Definitely easier to port to Maemo :)

 >Regards.
 >
 > On Fri, Mar 4, 2011 at 7:04 PM, Alon Levy  wrote:
 >
 > > On Fri, Mar 04, 2011 at 06:21:19PM +0800, Shuxiang Lim wrote:
 > > >  Hi, friends,
 > > > Thanks for your replies. It's definitely right till now I've
 been
 > > > working a tougher way compared to spice-gtk.And actually I've
 considered
 > > to
 > > > steer my way to the latter in fear of the troublesome and crippled
 C++
 > > > support in Android NDK:C is more "simple and safe" in Android than
 C++.
 > > > But,AFAIK,there is no gtk port for Android yet. And the biggest
 obstacle
 > > is
 > > > the framework of Android:in its design,all UI should be done in

Re: [Spice-devel] OS/X and/or iPad Port

[Attila Sukosd]

Well the main reason is that X11 is already there, so didn't have to worry
about rewriting all the graphics.
I've been getting decent performance with it, streaming full screen HD works
pretty well.

But I do agree that in the long term, it would be better to use the native
GUI instead. I just didn't have the resources to do so (yet).

Rgrds,

Attila

On Mon, Mar 7, 2011 at 3:12 AM, Cliff Sharp  wrote:

> Is there any particular reason you are using X11 - seems very slow on OS/X?
>
> Sent from my iPhone
>
> On Mar 6, 2011, at 3:41 AM, Attila Sukosd  wrote:
>
> Hi,
>
> I've been doing a bit of OS X porting which uses X11 and PortAudio.
> Haven't really looked into iPad though.
>
>
> Rgrds,
>
> Attila
>
>
> On Sun, Mar 6, 2011 at 5:08 AM, Cliff Sharp < 
> csh...@vbridges.com> wrote:
>
>> Is anyone planning or know of anyone porting SPICE to OS/ X and/or iPad?
>> Thanks
>>
>> 
>>
>>
>>
>>
>>
>> ___
>> Spice-devel mailing list
>>  Spice-devel@lists.freedesktop.org
>>  <http://lists.freedesktop.org/mailman/listinfo/spice-devel>
>> http://lists.freedesktop.org/mailman/listinfo/spice-devel
>>
>>
>
___
Spice-devel mailing list
Spice-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/spice-devel

Re: [Spice-devel] OS/X and/or iPad Port

[Attila Sukosd]

Hi,

I've been doing a bit of OS X porting which uses X11 and PortAudio.
Haven't really looked into iPad though.


Rgrds,

Attila


On Sun, Mar 6, 2011 at 5:08 AM, Cliff Sharp  wrote:

> Is anyone planning or know of anyone porting SPICE to OS/ X and/or iPad?
> Thanks
>
> 
>
>
>
>
>
> ___
> Spice-devel mailing list
> Spice-devel@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/spice-devel
>
>
___
Spice-devel mailing list
Spice-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/spice-devel

Re: [Spice-devel] Try to port spicec into Android

[Attila Sukosd]

Hi,

I would also be interested in an android port, and looking through
spice-gtk, it does seems much simpler than spicec.

Best Regards,

Attila

On Fri, Mar 4, 2011 at 9:36 AM, Alon Levy  wrote:

> On Fri, Mar 04, 2011 at 03:38:51PM +0800, Shuxiang Lim wrote:
> > Hi all,
> >I'm trying these days to port spicec into Android.But it's a rather
> TOUGH
> > way to go because the structure of spicec and android are desperately
> > inappropriate:the linux version of spicec is based on the X11,which is
> not
> > available in Android,thus the UI of spicec should be rewritten from
> > scratch...More troublesome is that the UI part and data part in current
>
> Haven't looked at your proposal below yet, but did you check the spice-gtk
> work? maybe it is easier to start from that? are gtk libraries available on
> android? not talking about X. spice-gtk has objects for connection and
> channels
> that afaik don't do any output, that's separate from the actual widget that
> uses X. Also, gtk 3 has backends - did anyone do a backend for android?
>
> Since going forward we plan to ditch the spicec client, that would be
> really
> preffered. Now that I see what you have planned it sounds good, but better
> to use spice-gtk.
>
> of course that's not to say we won't love to see this working anyway :)
>
> > spicec is entangled in the hierarchical system in C++! So my plan is
> this:
> > first split the spicec into two parts,data and UI,transform the data part
> > into libspicec.so;then rewrite the UI part in JAVA. Besides, I should
> also
> > tinker some problems caused by the Crippled NDK C++ support and the Lamed
> > bionic c lib in android .
> >And now the first step is roughly done,hence the change of the spicec
> > structure:
> >From
> > |-->playback
> > thread
> > |-->cursor
> > thread
> > spicec:spicec process（application process）-->main thread->|-->*record
> thread
> > *
> > |-->inputs
> > thread
> > |-->display
> > thread
> > To:
> > ===>
> >  |-->libspicec.so:application thread-->main
> > thread-->|
> >  |
> > |
> >  |  |<--display thread<--|
> >  |
> >  | |--->|<--cursor
> > thread<---|<--|
> >  | ||<--inputs thread<---|
> > spicec:spicec process--->| ||<--playback thread<-|
> >  | |
> >  | |
> >  | |
> > <-|
> >  |
> >   |
> >  |
> >   |
> >  |-->spicec:platform
> > thread-->|
> >
> > The hierarchical relationship has been unleashed with one thread(record
> > channel) deleted and two new threads (app and platform)  created. The
> first
> > as the "data thread",the other as the "work thread" which is driven by
> the
> > signals from the first thread as well as its sub threads and requested to
> do
> > the UI-related work:
> >
> > platform thread：>blocked and waiting:-->job
> > request-<--|
> >   |   |
> > |
> >   ^   |
> > |
> >   |
> > | |
> >   |<--|-<-|
> > |
> >   |   |
> > |
> > platform thread over<--if(job==die)<--| send req. blocked
> > and waiting
> >   |   ^ |
> > |
> >   |   | |
> >^
> >   |   | |
> > _|_
> >   |   | |
> > | app/plbk/cusor
> > thd
> >  |<---job donedojob()<--else--|   | |->go on->|
> > __
> >  ||
> >  |--->feed back-->|
> >
> >
> > So the next work is to expose the native JNI interface in platform thread
> to
> > the UI written in Android SDK. I try to use the UI
> > frame of AndroidVNCViewer in
> > code.google.com/p/*android*-*vnc*-viewer/,then the work of platform
> > thread will be replaced by UI but the msg
> > communication to libspicec will be remained. That's the easiest way I can
> > envisage except rewriting all parts in spicec from scra

Re: [Spice-devel] [Qemu-devel] RFC: usb redirection over the network, interesting outside of spice?

[Attila Sukosd]

Hi,

I guess it should be abstract enough to support multiple back-ends, be it a
kernel driver or through libusb?


Rgrds,

Attila


2010/11/29 Gerd Hoffmann 

>  Hi,
>
>
>  I'm note sure about what I will say, but will a kernel approach
>> handle specific disconnection/reconnection of devices, that libusb
>> cannot?
>>
>
> Don't know, didn't investigate (yet) what libusb can do and what it can't.
>
> cheers,
>  Gerd
>
>
>
> ___
> Spice-devel mailing list
> Spice-devel@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/spice-devel
>
___
Spice-devel mailing list
Spice-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/spice-devel

Re: [Spice-devel] QXL Driver working in X11?

[Attila Sukosd]

Hi,

I just did a fresh FC13 install, then install qxl from the rep and it works
fine, just needed a bit of xorg.conf tweaking to support resolutions above
1024x768. (this is with spice v0.4)

Rgrds,

Attila

2010/10/1 Frédéric Grelot 

> Hi,
>
> I just read the post of Hans about vdagent support for linux, which
> reminded me that the last time I tried, I couldn't manage to make the QXL
> driver work with Fedora : did anything evolve about this?
> I've been using spice a lot with windows XP, but would prefer to use it
> with my F13/14 virtual machines...
> If it is not ready yet, are there any plan to make it working before F14
> release?
>
> Thanks for your answers.
>
> Frederic.
> ___
> Spice-devel mailing list
> Spice-devel@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/spice-devel
>
___
Spice-devel mailing list
Spice-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/spice-devel

Re: [Spice-devel] [PATCH] client: port for Mac OS X

[Attila Sukosd]

Hi,

Thanks for looking though the patch :)

On Wed, Sep 29, 2010 at 5:46 PM, Alexander Larsson  wrote:

> On Sun, 2010-09-26 at 14:57 +0200, Attila Sukosd wrote:
> > Hi All,
> >
> > I finally had a bit of time to gather the changes to the spice client
> > in order to get it working under Mac.
>
> Good stuff. I landed some of the cleanup from this patch as:
>
> http://lists.freedesktop.org/archives/spice-devel/2010-September/001249.html
>
> Also, I did a new version of the select patch that further simplifies
> things:
>
> http://lists.freedesktop.org/archives/spice-devel/2010-September/001264.html
> Waiting for review on it...
>
> Further review:
>
> Why the GPL change? All other headers are LGPL 2.1 anyway, and we want
> the client LGPL anyway so it can be librariefied.
>

Yea, sorry bout the licensing change, I guess the old sources had some
different licensing.


>
> +#if defined(__APPLE__) || defined(__MACH__)
> +#ifndef MSG_NOSIGNAL
> +#define MSG_NOSIGNAL SO_NOSIGPIPE
> +#endif
> +#endif
>
> This is not right. SO_NOSIGPIPE is not used in the same way as
> MSG_NOSIGNAL.
> See e.g.
> http://lists.policyd.org/pipermail/devel/2007-September/000468.html
>
> Hmm, thats good to know.



> In general we want to avoid sprinkling __LINUX__ or __APPLE__ defines in
> the "unixy" code (its hard to avoid for win32 though). Instead we want
> to check things in configure and use proper HAVE_FOO checks, etc.
>
> So, for instance we'd have HAVE_ALSA (or maybe USE_ALSA in this case
> since we might have multiple detected sound system in any particular
> system), rather than __LINUX__ checks. And similar for the thread stuff.
>
> Yes, I agree, but it was just much easier to play around with it, without
having to modify too much in the autoconf stuff.


> Anyway, if you rebase your patch based on the stuff thats landed things
> should look much easier for you to handle.
>
>
___
Spice-devel mailing list
Spice-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/spice-devel

Re: [Spice-devel] [PATCH] spice: vdagent: add basic clipboard support

[Attila Sukosd]

Sorry for hijacking this, but whats the irc server/channel name?

Cheers,

Attila

On Wed, Aug 18, 2010 at 2:15 PM, Alexander Larsson  wrote:

> On Mon, 2010-08-09 at 12:58 +0300, Arnon Gilboa wrote:
> > From: Arnon Gilboa 
> >
> > -currently supports text only (UTF8)
> > -add VDAgent::dispatch_message()
> > -in VDAgent::read_completion() handle multi-chunk msgs
> > -fix chunk size bug in VDService::handle_pipe_data()
> > -add size to VDPipeMessage
>
> This reads out the clipboard and writes it to the client on every
> change. This is bad for two reasons:
>
> 1) It sends a lot of data to the client when it might not be needed
> 2) It always forces clipboard using apps to serialize any clip board
> data it has to text and pass it to windows every time someone copies and
> pastes. This is unnecessary in most cases since cut and paste is mostly
> intra-application. Additionally it may be costly since if you copy
> something more complex like pdf or html extracting the text from it may
> not be trivial.
>
> I know we discussed this on irc. What is the status of that?
>
> I guess we could split out the pure bugfixes from this and commit
> though.
>
> --
> =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
>  Alexander LarssonRed Hat, Inc
>   al...@redhat.comalexander.lars...@gmail.com
> He's a globe-trotting amnesiac grifter possessed of the uncanny powers of
> an
> insect. She's a sarcastic junkie snake charmer with a birthmark shaped like
> Liberty's torch. They fight crime!
>
> ___
> Spice-devel mailing list
> Spice-devel@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/spice-devel
>
___
Spice-devel mailing list
Spice-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/spice-devel

Re: [Spice-devel] [RFC] patch to remove CEGUI dependency

[Attila Sukosd]

Hi Darren,

Not yet, I havent really had the time. As far as I've seen, other than the
limited libraries, the graphics and audio will definitely need
reimplementing, since androids don't run X11 or ALSA. It might be possible
to port the current OpenGL code to OpenGL ES ? Not sure if that would be
easier than a full gfx rewrite? (I haven't been able to get the current
OpenGL implementation to run..)

Best Regards,

Attila

On Fri, Aug 13, 2010 at 5:54 AM, Darren Xiong  wrote:

> hi,Attila
> Have you ever succeed to port on android? I decide to to so, but when I
> looked into android SDK, found that there are many missing libs in android,
> do you have any ideas on this?
>
> Best Regards
> Darren
>
> 2010/7/1 Attila Sukosd 
>
> On Wed, Jun 30, 2010 at 8:57 PM, Alon Levy  wrote:
>>
>>> This has been tested a little, just to get my n900 to run spicec (it does
>>> now :)
>>>  * patch adds a --enable-cegui flag, defaults to disabled
>>>  * so default becomes:
>>>  * quit if no -h and -p arguments supplied (instead of showing dialog)
>>>  * if vm quits for any reason we quit (instead of returning to dialog)
>>>
>>> The define is called "HAVE_CEGUI" but should really be USE_GUI or
>>> something like that.
>>>
>>> commit 138bdba17a725a4f09400b1399dd652df6dbd254
>>> Author: Alon Levy 
>>> Date:   Wed Jun 30 20:50:26 2010 +0300
>>>
>>>CEGUI made optional
>>>
>>> diff --git a/client/application.cpp b/client/application.cpp
>>> index 482215c..9744083 100644
>>> --- a/client/application.cpp
>>> +++ b/client/application.cpp
>>> @@ -24,6 +24,8 @@
>>>  #include 
>>>  #endif
>>>
>>> +#include 
>>> +
>>>  #include "application.h"
>>>  #include "screen.h"
>>>  #include "utils.h"
>>> @@ -42,7 +44,9 @@
>>>  #include "cmd_line_parser.h"
>>>  #include "tunnel_channel.h"
>>>  #include "rect.h"
>>> +#ifdef HAVE_CEGUI
>>>  #include "gui/gui.h"
>>> +#endif
>>>  #include 
>>>  #include 
>>>  #include 
>>> @@ -102,6 +106,7 @@ void SwitchHostEvent::response(AbstractProcessLoop&
>>> events_loop)
>>>  }
>>>
>>>  //todo: add inactive visual appearance
>>> +#ifdef HAVE_CEGUI
>>>  class GUIBarrier: public ScreenLayer {
>>>  public:
>>> GUIBarrier(int id)
>>> @@ -147,6 +152,7 @@ private:
>>> int _id;
>>> AutoRef _cursor;
>>>  };
>>> +#endif // HAVE_CEGUI
>>>
>>>  class InfoLayer: public ScreenLayer {
>>>  public:
>>> @@ -279,6 +285,7 @@ void StickyKeyTimer::response(AbstractProcessLoop&
>>> events_loop)
>>> app->deactivate_interval_timer(this);
>>>  }
>>>
>>> +#ifdef HAVE_CEGUI
>>>  class GUITimer: public Timer {
>>>  public:
>>> GUITimer(GUI& gui)
>>> @@ -314,6 +321,7 @@ private:
>>>  };
>>>  #endif
>>>
>>> +#endif // HAVE_CEGUI
>>>
>>>  static MouseHandler default_mouse_handler;
>>>  static KeyHandler default_key_handler;
>>> @@ -330,7 +338,9 @@ enum AppCommands {
>>> APP_CMD_CONNECT,
>>> APP_CMD_DISCONNECT,
>>>  #endif
>>> +#ifdef HAVE_CEGUI
>>> APP_CMD_SHOW_GUI,
>>> +#endif // HAVE_CEGUI
>>>  };
>>>
>>>  Application::Application()
>>> @@ -351,7 +361,9 @@ Application::Application()
>>> , _monitors (NULL)
>>> , _title (L"SPICEc:%d")
>>> , _sys_key_intercept_mode (false)
>>> +#ifdef HAVE_CEGUI
>>> , _gui_mode (GUI_MODE_FULL)
>>> +#endif // HAVE_CEGUI
>>> , _during_host_switch(false)
>>> , _state (DISCONNECTED)
>>>  {
>>> @@ -371,7 +383,9 @@ Application::Application()
>>> _commands_map["connect"] = APP_CMD_CONNECT;
>>> _commands_map["disconnect"] = APP_CMD_DISCONNECT;
>>>  #endif
>>> +#ifdef HAVE_CEGUI
>>> _commands_map["show-gui"] = APP_CMD_SHOW_GUI;
>>> +#endif // HAVE_CEGUI
>>>
>>> _canvas_types.resize(1);
>>>  #ifdef WIN32
>>> @@ -391,7 +405,9 @@ Application::Application()
>>>
>>> ",connect=shift+f5"
>>>
>>> ",disconnect=shift+f6"
>>>  #endif
>>> +#ifdef HAVE_CEGUI
>&g

Re: [Spice-devel] SPICE developers wanted

[Attila Sukosd]

On Fri, Jul 30, 2010 at 11:03 AM, Alon Levy  wrote:

> On 07/29/2010 07:40 PM, Attila Sukosd wrote:
> > Yes, I can confirm it works, I've got it compiled and running (kinda) on
> my
> > n810.
> >
> > I do get a "BadWindow (invalid Window parameter) minor 0 request
> > X_ConvertSelection" X11 error message when I launch it though. Haven't
> had
> > time to play around with it too much yet..
> >
>
> not good, sounds like our new fangled clipboard support isn't
> supported.. please send a stack trace if possible. Thanks for testing.
>
> > It has a 400Mhz TI OMAP 2420.
> >
> > Attila
> >
> > On Thu, Jul 29, 2010 at 6:31 PM, Alon Levy  wrote:
> >
> >> ok, so I just tested that this actually works on my n900.
> >>
> >> You need to use upstream and apply two patches on top of it, both
> >> attached (the first was also sent to the list for review).
> >>
> >> The resolution is still an issue.
> >>
> >> Btw what's the cpu on the n800? what does cat /proc/cpuinfo say, and
> uname
> >> -a?
> >>
> >>
> >> - "Alon Levy"  wrote:
> >>
> >>> I just pushed some of the fixes to upstream spice
> >>> (git://anongit.freedesktop.org/spice/spice)
> >>>
> >>> It is broken now with the autogenerated protocol. I'm trying to fix
> >>> that. I'll update you.
> >>>
> >>> - Original Message -
> >>> From: "Steven Tan" 
> >>> To: "Alon Levy" 
> >>> Sent: Thursday, July 29, 2010 10:21:47 AM (GMT+0200) Auto-Detected
> >>> Subject: Re: [Spice-devel] SPICE developers wanted
> >>>
> >>> Hi Alon,
> >>>
> >>> Really appreciate if you could provide the patches.
> >>>
> >>> Thanks
> >>> Steven
> >>>
> >>> On Jul 28, 2010, at 3:31 PM, Alon Levy  wrote:
> >>>
> >>>
> >>> - "steven"  wrote:
> >>>
> >>> Hi Guys
> >>>
> >>>
> >>> I'm looking for someone who can help with porting SPICE onto an
> >>> ARM-based platform using Linux. Write me if you are interested and
> >>> I'll furnish more details. Please include a self-introduction in your
> >>> email with your skills and experience.
> >>>
> >>>
> >>>
> >>> Just FYI, spice has been ported to N900 and to PC-Z1, both arm based
> >>> platforms. (different
> >>> variants). The patches are not committed but I would gladly provide
> >>> them.
> >>>
> >>> Thanks
> >>> Steven
> >>>
> >>> ___
> >>> Spice-devel mailing list
> >>> Spice-devel@lists.freedesktop.org
> >>> http://lists.freedesktop.org/mailman/listinfo/spice-devel
> >>
> >> ___
> >> Spice-devel mailing list
> >> Spice-devel@lists.freedesktop.org
> >> http://lists.freedesktop.org/mailman/listinfo/spice-devel
> >>
> >>
> >
>
> Sorry for not getting back earlier, how do I get a stack trace? I'm not
very familiar with X debugging.

Cheers
___
Spice-devel mailing list
Spice-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/spice-devel

Re: [Spice-devel] SPICE developers wanted

[Attila Sukosd]

Yes, I can confirm it works, I've got it compiled and running (kinda) on my
n810.

I do get a "BadWindow (invalid Window parameter) minor 0 request
X_ConvertSelection" X11 error message when I launch it though. Haven't had
time to play around with it too much yet..

It has a 400Mhz TI OMAP 2420.

Attila

On Thu, Jul 29, 2010 at 6:31 PM, Alon Levy  wrote:

> ok, so I just tested that this actually works on my n900.
>
> You need to use upstream and apply two patches on top of it, both
> attached (the first was also sent to the list for review).
>
> The resolution is still an issue.
>
> Btw what's the cpu on the n800? what does cat /proc/cpuinfo say, and uname
> -a?
>
>
> - "Alon Levy"  wrote:
>
> > I just pushed some of the fixes to upstream spice
> > (git://anongit.freedesktop.org/spice/spice)
> >
> > It is broken now with the autogenerated protocol. I'm trying to fix
> > that. I'll update you.
> >
> > - Original Message -
> > From: "Steven Tan" 
> > To: "Alon Levy" 
> > Sent: Thursday, July 29, 2010 10:21:47 AM (GMT+0200) Auto-Detected
> > Subject: Re: [Spice-devel] SPICE developers wanted
> >
> > Hi Alon,
> >
> > Really appreciate if you could provide the patches.
> >
> > Thanks
> > Steven
> >
> > On Jul 28, 2010, at 3:31 PM, Alon Levy  wrote:
> >
> >
> > - "steven"  wrote:
> >
> > Hi Guys
> >
> >
> > I'm looking for someone who can help with porting SPICE onto an
> > ARM-based platform using Linux. Write me if you are interested and
> > I'll furnish more details. Please include a self-introduction in your
> > email with your skills and experience.
> >
> >
> >
> > Just FYI, spice has been ported to N900 and to PC-Z1, both arm based
> > platforms. (different
> > variants). The patches are not committed but I would gladly provide
> > them.
> >
> > Thanks
> > Steven
> >
> > ___
> > Spice-devel mailing list
> > Spice-devel@lists.freedesktop.org
> > http://lists.freedesktop.org/mailman/listinfo/spice-devel
>
> ___
> Spice-devel mailing list
> Spice-devel@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/spice-devel
>
>
___
Spice-devel mailing list
Spice-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/spice-devel

Re: [Spice-devel] Using USB with Spice

[Attila Sukosd]

On Wed, Jul 28, 2010 at 5:01 PM, Andrew Cathrow  wrote:

>
>
> - Original Message -
> > From: "Informatique" 
> > To: spice-devel@lists.freedesktop.org
> > Sent: Monday, July 26, 2010 5:32:45 AM
> > Subject: [Spice-devel] Using USB with Spice
> > Hi,
> >
> >
> > We'd like to use Spice for running thinclients.
> >
> > Clients Windows XP are virtualized with Spice, and we'd like to
> > benefit thinclient's USB under Windows session. Unfortunately, we
> > didn't find any procedure to access USB.
> >
> > Could you inform us of the way of doing that?
> >
>
> Spice today doesn't include native support for USB remoting, it's one of
> the roadmap features.
> Products that use Spice (for example Red Hat Enterprise Virtualization) use
> another component for remote USB in the mean time.
>
>
Could you elaborate on that? We are testing the RHEV beta, and would like to
see how to get the USB stuff to work.



>
> >
> >
> > Thank you,
> >
> >
> >
> >
> > Olivier Doyen,
> >
> > Informatic Department of Fléron
> > ___
> > Spice-devel mailing list
> > Spice-devel@lists.freedesktop.org
> > http://lists.freedesktop.org/mailman/listinfo/spice-devel
> ___
> Spice-devel mailing list
> Spice-devel@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/spice-devel
>

Cheers,

Attila
___
Spice-devel mailing list
Spice-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/spice-devel

Re: [Spice-devel] SPICE developers wanted

[Attila Sukosd]

On Wed, Jul 28, 2010 at 10:18 AM, Alon Levy  wrote:

>
> - "Attila Sukosd"  wrote:
>
> > On Wed, Jul 28, 2010 at 9:31 AM, Alon Levy < al...@redhat.com > wrote:
> >
> >
> >
> >
> >
> >
> >
> > - "steven" < stevenph...@yahoo.com > wrote:
> >
> > > Hi Guys
> > >
> > >
> > > I'm looking for someone who can help with porting SPICE onto an
> > > ARM-based platform using Linux. Write me if you are interested and
> > > I'll furnish more details. Please include a self-introduction in
> > your
> > > email with your skills and experience.
> > >
> > >
> >
> > Just FYI, spice has been ported to N900 and to PC-Z1, both arm based
> > platforms. (different
> > variants). The patches are not committed but I would gladly provide
> > them.
> >
> > > Thanks
> > > Steven
> >
> >
> >
> > >
> > > ___
> > > Spice-devel mailing list
> > > Spice-devel@lists.freedesktop.org
> > > http://lists.freedesktop.org/mailman/listinfo/spice-devel
> > ___
> > Spice-devel mailing list
> > Spice-devel@lists.freedesktop.org
> > http://lists.freedesktop.org/mailman/listinfo/spice-devel
> >
> > I was actually planning to get it to work on the N810. I guess you
> > still need X11 to run it, and since (at least the Xomap in the N810)
> > does not do MIT-SHM, I'm guessing it would be rather slow currently.
> >
>
> on N900 it was usable, under X11 like you say. I don't know the difference
> between
> the machines relating to graphics driver, but I didn't use any opengl.
> also, same resolution
> I think (800x480 or something like that).
> I don't have a n810 to test on. The "patch" I was referring to is very
> simple, basically:
>  1. one line to configure.ac to let cpu check pass
>  2. empty implementation for atomic ops - haven't given this much testing,
> but it seemed to work. of course
>  the right way would be to actually have an arm implmenetation, but I don't
> know enough arm
>  assembler to write one, if you find someone to do this they could do
> better here :)
>
> > Attila
>

Did you have any issues with the guest resolution? (since the device display
has a non standard res?)

Attila
___
Spice-devel mailing list
Spice-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/spice-devel

Re: [Spice-devel] SPICE developers wanted

[Attila Sukosd]

On Wed, Jul 28, 2010 at 9:31 AM, Alon Levy  wrote:

>
> - "steven"  wrote:
>
> > Hi Guys
> >
> >
> > I'm looking for someone who can help with porting SPICE onto an
> > ARM-based platform using Linux. Write me if you are interested and
> > I'll furnish more details. Please include a self-introduction in your
> > email with your skills and experience.
> >
> >
>
> Just FYI, spice has been ported to N900 and to PC-Z1, both arm based
> platforms. (different
> variants). The patches are not committed but I would gladly provide them.
>
> > Thanks
> > Steven
> >
> > ___
> > Spice-devel mailing list
> > Spice-devel@lists.freedesktop.org
> > http://lists.freedesktop.org/mailman/listinfo/spice-devel
> ___
> Spice-devel mailing list
> Spice-devel@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/spice-devel
>

I was actually planning to get it to work on the N810. I guess you still
need X11 to run it, and since (at least the Xomap in the N810) does not do
MIT-SHM, I'm guessing it would be rather slow currently.

Attila
___
Spice-devel mailing list
Spice-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/spice-devel

Re: [Spice-devel] [Spice-commits] Changes to 'refs/tags/0.5.2'

[Attila Sukosd]

On Thu, Jul 8, 2010 at 10:44 PM, Alexander Larsson <
al...@kemper.freedesktop.org> wrote:

> Tag '0.5.2' created by Alexander Larsson  at 2010-07-08
> 21:27 -0700
>
> Release 0.5.2
>
> Changes since the dawn of time:
> Alexander Larsson (50):
>  Import all protocol headers from spice/common
>  Add MIT style COPYING file
>  Add standard header for defining core types
>  Use spice/types.h and its types
>  Add standard header for structure packing
>  Add standard memory barrier header
>  Use  memory barrier
>  Add utility script to do C identifier renaming
>  Clean up all network protocol names to start with Spice/SPICE_
>  Rename all identifiers
>  Clean up header names, removing references to "red"
>  Clean up and standardize header guards
>  Hide internal macros with _SPICE prefix
>  Always include using  style
>  Add autoconf and pkg-config setup
>  Add gitignore file
>  Fix up SPICE_SPICE typo
>  fix up reames
>  Add includes.sed file to handle include renaming
>  Disable warning about our use of pragma pack in include file
>  Add a bunch of generically useful macros
>  Use int32, not int in protocol defining structure
>  Add SPICE_MSG_MAIN_MIGRATE_SWITCH_HOST message
>  Bump minor to 3
>  Make pci id be 0x1ff rev 1, for unstable work
>  Add surface type enum
>  Add some comment describing the bitmap formats
>  Pass format when creating surfaces rather than depth
>  Add source/dest alpha information to AlphaBlend
>  Add image flag for "all high bits are set to one"
>  Add byteswapping macros
>  Fix some misspelled identifiers
>  Add some types needed by the demarshalling work
>  Move all enums and flags to generated header file
>  Move all message structs to spice
>  Remove duplicated enums for keyboard modifiers
>  Reset minor to 0 as we're bumping major
>  Remove SPICE_CLIP_TYPE_PATH enum.
>  Change SpicePath.size to SpicePath.num_segments
>  Simplify SpiceLineAttr by removing unused elements and enums
>  Don't make SpicePath.segment a SpicePathSeg
>  Update SpicePath.segments to a pointer array
>  Use QXLFIXED, not SPICE_FIXED28_4 in qxl_dev.h
>  Make SpiceLineAttr.style a normal pointer
>  Add QXLCursorHeader and use instead of SpiceCursorHeader in qxl
>  Move spice/draw.h to spice
>  List all the PCI ids and revisions instead of just the latest/current
>  Include enums.h from qxl_dev.h
>  Fix misspellings
>  Update NEWS for release
>
> Gerd Hoffmann (23):
>  make unstable qxl compatible with 0.4 qxl
>  add QXL_SURF_FLAG_KEEP_DATA
>  qxl abi: add AlphaBlnd.
>  qxl abi: add Fill.
>  qxl abi: add Opaque.
>  qxl abi: add Copy+Blend.
>  qxl abi: add QXLTransparent
>  qxl abi: add QXLRop3
>  qxl abi: add QXLStroke
>  qxl abi: add QXLText
>  qxl abi: add QXLBlackness+QXLInvers+QXLWhiteness
>  qxl abi: add QXLQMask
>  qxl abi: add QXLBrush
>  qxl abi: add QXLPattern
>  qxl abi: add QXLLineAttr
>  qxl abi: add QXLClip
>  qxl abi: add QXLPoint & friends
>  qxl abi: add QXLRect
>  qxl abi: zap SPICE_ADDRESS for clip rects and paths.
>  make SpiceRect compatible with pixman_box32
>  Update SpiceString to use an array of pointers for glyphs
>  qxl abi: Add QXLImage and & co
>   place pkgconfig file in /usr/share
>
> Izik Eidus (2):
>  spice-protocl: add spice_msg_display_surface_create/destroy
>  spice-protocol off screens supports
>
> Yonit Halperin (4):
>  add image type for jpeg
>  cache support for replacing images that were compressed using jpeg
> with lossless images
>  add image type for images that are compressed by zlib after they have
> been compressed by glz
>  add image type for RGBA bitmaps that were compressed by a combination
> of JPEG (RGB) and LZ (alpha channel).
>
> ___
> Spice-commits mailing list
> spice-comm...@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/spice-commits
>

Hi,

Quick question, why has the pkgconfig files been moved to share/pkgconfig
instead of the original lib/pkgconfig path?

This means that since all the other libraries put their pkgconfig file in
lib/pkgconfig, two paths need to be set for it to find the libs...

Cheers,

Attila
___
Spice-devel mailing list
Spice-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/spice-devel

Re: [Spice-devel] spice BSD/OSX client

[Attila Sukosd]

On Wed, Jul 7, 2010 at 11:01 AM, Alexander Larsson  wrote:

> On Tue, 2010-07-06 at 10:53 +0200, Attila Sukosd wrote:
>
> >
> > Hi guys,
> >
> > I thought I'll post an update on the Mac client. I have it up and
> > running using the latest sources from the git dev. Event handler is
> > doing select(), playback and recording is done with PortAudio, R and B
> > re-swapped for peer_major == 1, and CEGUI is disabled since it caused
> > a LOT of issues...
>
> Epic. Can you put up patches somewhere? I guess this still uses X11 on
> osx, right?
>
> Yea, it is using X11. Porting to Cocoa would be a rather bigger job. I'll
try to clean it up a bit and upload a patch somewhere...



> > So now I'm only facing a few minor issues/things I've noticed:
> >
> > 1. Video playback seem to stop after a few seconds, but if the window
> > is moved around or scrolled the video playback resumes again for a few
> > seconds. I've tried it with VLC, windows media player and flash video
> > players (youtube). Also, sometimes only the center square gets updated
> > but not the rest. It is not very consistent as sometimes the video
> > plays back fine..
>
> Weird. No idea...
>
> > 2. Bandwidth usage seemed to have increased, with the v0.4 client ive
> > been seeing 1-2MB/s for full screen HD video playback, while with the
> > current one I've been seeing peeks of 8-9MB/s on a 100mbit network
>
> Yeah, there has been some changes with e.g. the offscreen surfaces, etc
> that probably needs tweaking to get back to previous levels. Once we're
> feature frozen and have all this down we need to sit down and measure
> and tweak things.
>
> > 3. We didn't receive (as far as I'm aware) the linux firefox plugin
> > for the client with our RH beta package, and Im not sure where to find
> > it? I've ended up creating a launcher script, associated that with
> > spice:// protocol in firefox and modified the javascript on the
> > management machine to redirect to a spice:// address in case the
> > plugin wasn't found. Not sure if this is the best way of doing it?
>
> spice-xpi is not on freedesktop.org atm. I guess we should maybe put it
> up, although i don't know if its generally useful for non-rhel
> customers.
>
> I had a quick glance at the spice-xpi, but it seems way too complicated for
a simple function of launching the spice client with the correct
arguments... Though that might just be me :)


> --
> =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
>  Alexander LarssonRed Hat, Inc
>   al...@redhat.comalexander.lars...@gmail.com
> He's an unconventional guerilla shaman plagued by the memory of his
> family's
> brutal murder. She's a virginal junkie pearl diver on the trail of a serial
> killer. They fight crime!
>
>
___
Spice-devel mailing list
Spice-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/spice-devel

Re: [Spice-devel] spice BSD/OSX client

[Attila Sukosd]

On Fri, Jun 25, 2010 at 12:32 PM, Attila Sukosd wrote:

> On Fri, Jun 25, 2010 at 11:41 AM, Gerd Hoffmann  wrote:
>
>>  Hi,
>>
>>
>>  Also, the kqueue implementation in OS X 10.6 seem to have been broken,
>>> so I went with your suggestion and reimplemented the event handler using
>>> select(). One thing I noticed though was that the epoll implementation
>>> watched the fds for both read and write (add_to_poll()), but since it is
>>> edge triggered, it only fires once per change, but my select()
>>> implementation is level triggered, which meant it would never block and
>>> use up 100% CPU (for example monitoring a File fd, it always triggers).
>>> After playing a bit around with it, i decided to drop watching write for
>>> fds all together, and the client seem to work fine. Is there a need to
>>> check it or am I safe with monitoring only reads?
>>>
>>
>> It isn't save.  When you got -EAGAIN from a write() or send() syscall
>> because the output pipe is full you have to watch for the socket becoming
>> writable so you can flush out the bits you havn't sent yet.
>>
>> As far I know there is no bulk data going from client to server, so if you
>> are working on a fast LAN it is quite possible that you never hit the
>> "output pipe full" case and the client works fine for you.
>>
>>
>>  Now on to the audio, I have been implementing audio using CoreAudio
>>> Framework for OS X (another idea could be OpenAL which is also
>>> cross-platform?),  which pulls in a lot of extra headers, including
>>> MacTypes.h which unfortunately defines a "Rect" and "Point" struct which
>>> causes issues with the definitions inside common/draw.h. I can hack
>>> around it, but its not very nice, or I could rename the ones in spice,
>>> but that would break any compatibility with my patches to the current
>>> upstream code.
>>>
>>
>> What code base you are working on?  In the unstable tree the structs have
>> been renamed to SpiceRect and SpicePoint exactly to avoid name clashes like
>> this.  Also the headers have been splitted away into a spice-protocol
>> package.
>>
>> A few days ago Alex landed the marshaller bits in the unstable tree and
>> the spice client can handle both 0.4 and unstable spice protocols now. So
>> you can jump to the unstable code base even if you need the client play
>> nicely with 0.4 spice servers.  This will also make it easier to merge your
>> patches upstream.
>>
>> HTH,
>>  Gerd
>>
>> Hi Gerd,
>
> Thanks for the fast reply! Sounds good! Yes, right now I've been working on
> version 0.4, but since the unstable tree is now backwards compatible, I will
> move on to that.
>
> Rgrds,
>
> Attila.
>

Hi guys,

I thought I'll post an update on the Mac client. I have it up and running
using the latest sources from the git dev. Event handler is doing select(),
playback and recording is done with PortAudio, R and B re-swapped for
peer_major == 1, and CEGUI is disabled since it caused a LOT of issues...

So now I'm only facing a few minor issues/things I've noticed:

1. Video playback seem to stop after a few seconds, but if the window is
moved around or scrolled the video playback resumes again for a few seconds.
I've tried it with VLC, windows media player and flash video players
(youtube). Also, sometimes only the center square gets updated but not the
rest. It is not very consistent as sometimes the video plays back fine..

2. Bandwidth usage seemed to have increased, with the v0.4 client ive been
seeing 1-2MB/s for full screen HD video playback, while with the current one
I've been seeing peeks of 8-9MB/s on a 100mbit network

3. We didn't receive (as far as I'm aware) the linux firefox plugin for the
client with our RH beta package, and Im not sure where to find it? I've
ended up creating a launcher script, associated that with spice:// protocol
in firefox and modified the javascript on the management machine to redirect
to a spice:// address in case the plugin wasn't found. Not sure if this is
the best way of doing it?


Best Regards,

Attila
___
Spice-devel mailing list
Spice-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/spice-devel

Re: [Spice-devel] [RFC] patch to remove CEGUI dependency

[Attila Sukosd]

On Wed, Jun 30, 2010 at 8:57 PM, Alon Levy  wrote:

> This has been tested a little, just to get my n900 to run spicec (it does
> now :)
>  * patch adds a --enable-cegui flag, defaults to disabled
>  * so default becomes:
>  * quit if no -h and -p arguments supplied (instead of showing dialog)
>  * if vm quits for any reason we quit (instead of returning to dialog)
>
> The define is called "HAVE_CEGUI" but should really be USE_GUI or something
> like that.
>
> commit 138bdba17a725a4f09400b1399dd652df6dbd254
> Author: Alon Levy 
> Date:   Wed Jun 30 20:50:26 2010 +0300
>
>CEGUI made optional
>
> diff --git a/client/application.cpp b/client/application.cpp
> index 482215c..9744083 100644
> --- a/client/application.cpp
> +++ b/client/application.cpp
> @@ -24,6 +24,8 @@
>  #include 
>  #endif
>
> +#include 
> +
>  #include "application.h"
>  #include "screen.h"
>  #include "utils.h"
> @@ -42,7 +44,9 @@
>  #include "cmd_line_parser.h"
>  #include "tunnel_channel.h"
>  #include "rect.h"
> +#ifdef HAVE_CEGUI
>  #include "gui/gui.h"
> +#endif
>  #include 
>  #include 
>  #include 
> @@ -102,6 +106,7 @@ void SwitchHostEvent::response(AbstractProcessLoop&
> events_loop)
>  }
>
>  //todo: add inactive visual appearance
> +#ifdef HAVE_CEGUI
>  class GUIBarrier: public ScreenLayer {
>  public:
> GUIBarrier(int id)
> @@ -147,6 +152,7 @@ private:
> int _id;
> AutoRef _cursor;
>  };
> +#endif // HAVE_CEGUI
>
>  class InfoLayer: public ScreenLayer {
>  public:
> @@ -279,6 +285,7 @@ void StickyKeyTimer::response(AbstractProcessLoop&
> events_loop)
> app->deactivate_interval_timer(this);
>  }
>
> +#ifdef HAVE_CEGUI
>  class GUITimer: public Timer {
>  public:
> GUITimer(GUI& gui)
> @@ -314,6 +321,7 @@ private:
>  };
>  #endif
>
> +#endif // HAVE_CEGUI
>
>  static MouseHandler default_mouse_handler;
>  static KeyHandler default_key_handler;
> @@ -330,7 +338,9 @@ enum AppCommands {
> APP_CMD_CONNECT,
> APP_CMD_DISCONNECT,
>  #endif
> +#ifdef HAVE_CEGUI
> APP_CMD_SHOW_GUI,
> +#endif // HAVE_CEGUI
>  };
>
>  Application::Application()
> @@ -351,7 +361,9 @@ Application::Application()
> , _monitors (NULL)
> , _title (L"SPICEc:%d")
> , _sys_key_intercept_mode (false)
> +#ifdef HAVE_CEGUI
> , _gui_mode (GUI_MODE_FULL)
> +#endif // HAVE_CEGUI
> , _during_host_switch(false)
> , _state (DISCONNECTED)
>  {
> @@ -371,7 +383,9 @@ Application::Application()
> _commands_map["connect"] = APP_CMD_CONNECT;
> _commands_map["disconnect"] = APP_CMD_DISCONNECT;
>  #endif
> +#ifdef HAVE_CEGUI
> _commands_map["show-gui"] = APP_CMD_SHOW_GUI;
> +#endif // HAVE_CEGUI
>
> _canvas_types.resize(1);
>  #ifdef WIN32
> @@ -391,7 +405,9 @@ Application::Application()
>
> ",connect=shift+f5"
>
> ",disconnect=shift+f6"
>  #endif
> +#ifdef HAVE_CEGUI
>
> ",show-gui=shift+f7"
> +#endif // HAVE_CEGUI
>   ,
> _commands_map));
> _hot_keys = parser->get();
>
> @@ -402,6 +418,7 @@ Application::Application()
> _sticky_info.key  = REDKEY_INVALID;
> _sticky_info.timer.reset(new StickyKeyTimer());
>
> +#ifdef HAVE_CEGUI
> _gui.reset(new GUI(*this, DISCONNECTED));
> _gui_timer.reset(new GUITimer(*_gui.get()));
> activate_interval_timer(*_gui_timer, 1000 / 30);
> @@ -409,6 +426,7 @@ Application::Application()
> _gui_test_timer.reset(new TestTimer(*this));
> activate_interval_timer(*_gui_test_timer, 1000 * 30);
>  #endif
> +#endif // HAVE_CEGUI
> for (int i = SPICE_CHANNEL_MAIN; i < SPICE_END_CHANNEL; i++) {
> _peer_con_opt[i] = RedPeer::ConnectionOptions::CON_OP_BOTH;
> }
> @@ -416,12 +434,14 @@ Application::Application()
>
>  Application::~Application()
>  {
> +#ifdef HAVE_CEGUI
> deactivate_interval_timer(*_gui_timer);
>  #ifdef GUI_DEMO
> deactivate_interval_timer(*_gui_test_timer);
>  #endif
> destroyed_gui_barriers();
> _gui->set_screen(NULL);
> +#endif // HAVE_CEGUI
>
> if (_info_layer->screen()) {
> _main_screen->detach_layer(*_info_layer);
> @@ -511,7 +531,11 @@ void Application::remove_mouse_handler(MouseHandler&
> handler)
>
>  void Application::capture_mouse()
>  {
> -if (!_active_screen || _gui->screen()) {
> +if (!_active_screen
> +#ifdef HAVE_CEGUI
> +|| _gui->screen()
> +#endif // HAVE_CEGUI
> +) {
> return;
> }
> _active_screen->capture_mouse();
> @@ -568,11 +592,15 @@ void Application::switch_host(const std::string&
> host, int port, int sport,
>
>  int Application::run()
>  {
> +#ifdef HAVE_CEGUI
> if (_gui_mode != GUI_MODE_FULL) {
> connect();
> }
>
> show_gui();
> +#else
> +connect();
> +#endif // HAVE_GUI
> _exit_code = ProcessLoop::run();
> return _exit_code;
>  }
> @@ -630,7 +658,9 @@ RedScreen* Application::get_screen(int id)
> size.y = SCREEN_INIT_HEIGHT;
> }
> screen = _screens[id] = new RedScreen(*this, id, _title, size.x,
> size.y);
> +#ifdef HA

Re: [Spice-devel] Latest development branch on Ubuntu 9.04

[Attila Sukosd]

On Tue, Jun 29, 2010 at 9:48 AM, Attila Sukosd wrote:

> Hi guys,
>
> So I've been trying to get the sources from the devel git to work, and I've
> got it to compile however I was facing some CEGUI issues:
>
> 29/06/2010 09:13:14 (Std)    CEGUI System initialisation completed
> 
> 29/06/2010 09:13:14 (Std)    Version 0.6.2 
> 29/06/2010 09:13:14 (Std)    Renderer module is: Unknown renderer
> (vendor did not set the ID string!) 
> 29/06/2010 09:13:14 (Std)    XML Parser module is:
> CEGUI::XercesParser - Official Xerces-C++ based parser module for CEGUI 
> 29/06/2010 09:13:14 (Std)    Scripting module is: None 
> 29/06/2010 09:13:14 (Std)   Attempting to load Scheme from file
> 'TaharezLook.scheme'.
> 29/06/2010 09:13:14 (Std)   XercesParser::initialiseSchema - Attempting
> to load schema from file 'GUIScheme.xsd'.
> 29/06/2010 09:13:14 (Error) CEGUI::GenericException in file
> ../../client/gui/resource_provider.cpp(83) : failed
> 29/06/2010 09:13:14 (Error) XercesParser::parseXMLFile - An unexpected
> error occurred while parsing XML file 'TaharezLook.scheme'.
> 29/06/2010 09:13:14 (Error) Scheme::Scheme - loading of Scheme from
> file 'TaharezLook.scheme' failed.
>
> This was using the "libcegui-mk2-*" packages from the default Ubuntu
> repositories. After playing around with it and regenerating the
> taharez_look.*.c, I still got nowhere, so I downloaded the CEGUI 0.6.2
> sources and compiled it by hand, but I still had the same issue. In the end,
> I did manage to "fix" it by changing the default xml parser for CEGUI to
> libxml (--with-default-xml-parser=LibxmlParser) instead of the Xerces one.
>
>
> Now I'm down to the issue of not being able to connect to a v0.4 server
> cause of version mismatch:
>
> 1277797671 INFO spice : [12999:12999] Application::main: starting 0.5.1
> 1277797671 INFO spice : [12999:12999] GUI::GUI(Application&,
> Application::State):
> 1277797671 INFO spice : [12999:13002] RedPeer::connect_unsecure: Connecting
> 192.168.1.4 6001
> 1277797671 WARN spice : [12999:13002] RedChannel::run: version mismatch:
> expect 4294967294 got 1
> 1277797671 INFO spice : [12999:12999] main: Spice client terminated
> (exitcode = 11)
>
> Server side:
>
> handle_dev_input: attach
> create_cairo_context: using cairo canvas
> interface_change_notifier: VD_INTERFACE_VDI_PORT
> interface_change_notifier: VD_INTERFACE_TABLET
> reds_handle_read_header_done: version mismatch
> reds_handle_read_header_done: version mismatch
>
>
>
> Best Regards,
>
> Attila
>

Update:

Changing #define RED_VERSION_MAJOR (~(uint32_t)0 - 1)
to #define RED_VERSION_MAJOR 1
has "fixed" the issue.

Attila
___
Spice-devel mailing list
Spice-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/spice-devel

[Spice-devel] Latest development branch on Ubuntu 9.04

[Attila Sukosd]

Hi guys,

So I've been trying to get the sources from the devel git to work, and I've
got it to compile however I was facing some CEGUI issues:

29/06/2010 09:13:14 (Std)    CEGUI System initialisation completed

29/06/2010 09:13:14 (Std)    Version 0.6.2 
29/06/2010 09:13:14 (Std)    Renderer module is: Unknown renderer
(vendor did not set the ID string!) 
29/06/2010 09:13:14 (Std)    XML Parser module is:
CEGUI::XercesParser - Official Xerces-C++ based parser module for CEGUI 
29/06/2010 09:13:14 (Std)    Scripting module is: None 
29/06/2010 09:13:14 (Std)   Attempting to load Scheme from file
'TaharezLook.scheme'.
29/06/2010 09:13:14 (Std)   XercesParser::initialiseSchema - Attempting
to load schema from file 'GUIScheme.xsd'.
29/06/2010 09:13:14 (Error) CEGUI::GenericException in file
../../client/gui/resource_provider.cpp(83) : failed
29/06/2010 09:13:14 (Error) XercesParser::parseXMLFile - An unexpected
error occurred while parsing XML file 'TaharezLook.scheme'.
29/06/2010 09:13:14 (Error) Scheme::Scheme - loading of Scheme from file
'TaharezLook.scheme' failed.

This was using the "libcegui-mk2-*" packages from the default Ubuntu
repositories. After playing around with it and regenerating the
taharez_look.*.c, I still got nowhere, so I downloaded the CEGUI 0.6.2
sources and compiled it by hand, but I still had the same issue. In the end,
I did manage to "fix" it by changing the default xml parser for CEGUI to
libxml (--with-default-xml-parser=LibxmlParser) instead of the Xerces one.


Now I'm down to the issue of not being able to connect to a v0.4 server
cause of version mismatch:

1277797671 INFO spice : [12999:12999] Application::main: starting 0.5.1
1277797671 INFO spice : [12999:12999] GUI::GUI(Application&,
Application::State):
1277797671 INFO spice : [12999:13002] RedPeer::connect_unsecure: Connecting
192.168.1.4 6001
1277797671 WARN spice : [12999:13002] RedChannel::run: version mismatch:
expect 4294967294 got 1
1277797671 INFO spice : [12999:12999] main: Spice client terminated
(exitcode = 11)

Server side:

handle_dev_input: attach
create_cairo_context: using cairo canvas
interface_change_notifier: VD_INTERFACE_VDI_PORT
interface_change_notifier: VD_INTERFACE_TABLET
reds_handle_read_header_done: version mismatch
reds_handle_read_header_done: version mismatch



Best Regards,

Attila
___
Spice-devel mailing list
Spice-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/spice-devel

Re: [Spice-devel] Compilation issues on Ubuntu and Mac

[Attila Sukosd]

On Mon, Jun 28, 2010 at 12:46 PM, Alexander Larsson wrote:

> On Mon, 2010-06-28 at 12:39 +0200, Alexander Larsson wrote:
> > On Mon, 2010-06-28 at 11:05 +0200, Attila Sukosd wrote:
> > > Hi guys,
> > >
> > > I've been trying to get the latest git sources to compile and i've
> > > been getting the same issue on both platforms:
> > >
> > > g++ -DHAVE_CONFIG_H -I. -I../.. -DSW_CANVAS_CACHE
> > > -DSW_CANVAS_NO_CHUNKS -DUSE_GLZ -D__STDC_LIMIT_MACROS -I. -I..
> > > -I../../common -I../../common/linux -I../../client
> > > -I/usr/local/include/spice-1-I/usr/include/alsa
> > > -I/usr/local/include/pixman-1-I/usr/local/include
> > > -I/usr/include/CEGUI   -Wall -Wno-sign-compare -Werror
> > > -Wno-deprecated-declarations  -g -O2 -MT main.o -MD -MP
> > > -MF .deps/main.Tpo -c -o main.o main.cpp
> > > In file included from ../red_channel.h:28,
> > >  from ../red_client.h:25,
> > >  from ../application.h:23,
> > >  from main.cpp:19:
> > > ../marshallers.h:27: error: declaration of ‘void (*  > > struct>::SpiceMsgEmpty)(SpiceMarshaller*, SpiceMsgEmpty*)’
> > > ../../common/messages.h:42: error: changes meaning of ‘SpiceMsgEmpty’
> > > from ‘typedef struct SpiceMsgEmpty SpiceMsgEmpty’
> > > ../marshallers.h:28: error: declaration of ‘void (*  > > struct>::SpiceMsgData)(SpiceMarshaller*, SpiceMsgData*)’
> > > ../../common/messages.h:39: error: changes meaning of ‘SpiceMsgData’
> > > from ‘typedef struct SpiceMsgData SpiceMsgData’
> > >
> > >
> > > Any help would be highly appriciated!
> >
> > The name of the function member of the struct (SpiceMsgEmpty) is the
> > same as a typedefed type (SpiceMsgEmpty) which gives an error.
> >
> > I dunno why this doesn't cause problems for others, but it should be
> > easy to solve by adding some prefix. I'll handle it.
>
> Should be fixed in git. You may need to make clean to ensure the right
> source files are regenerated.
>
> --
> =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
>  Alexander LarssonRed Hat, Inc
>   al...@redhat.comalexander.lars...@gmail.com
> He's a benighted vegetarian househusband fleeing from a secret government
> programme. She's a vivacious snooty pearl diver living homeless in New
> York's
> sewers. They fight crime!
>
>
Great! Thanks for your fast reply again :)

Ill give it a try!

Rgrds,

Attila
___
Spice-devel mailing list
Spice-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/spice-devel

[Spice-devel] Compilation issues on Ubuntu and Mac

[Attila Sukosd]

Hi guys,

I've been trying to get the latest git sources to compile and i've been
getting the same issue on both platforms:

g++ -DHAVE_CONFIG_H -I. -I../.. -DSW_CANVAS_CACHE -DSW_CANVAS_NO_CHUNKS
-DUSE_GLZ -D__STDC_LIMIT_MACROS -I. -I.. -I../../common -I../../common/linux
-I../../client -I/usr/local/include/spice-1-I/usr/include/alsa
-I/usr/local/include/pixman-1-I/usr/local/include
-I/usr/include/CEGUI   -Wall -Wno-sign-compare -Werror
-Wno-deprecated-declarations  -g -O2 -MT main.o -MD -MP -MF
.deps/main.Tpo -c -o main.o main.cpp
In file included from ../red_channel.h:28,
 from ../red_client.h:25,
 from ../application.h:23,
 from main.cpp:19:
../marshallers.h:27: error: declaration of ‘void (* ::SpiceMsgEmpty)(SpiceMarshaller*, SpiceMsgEmpty*)’
../../common/messages.h:42: error: changes meaning of ‘SpiceMsgEmpty’ from
‘typedef struct SpiceMsgEmpty SpiceMsgEmpty’
../marshallers.h:28: error: declaration of ‘void (* ::SpiceMsgData)(SpiceMarshaller*, SpiceMsgData*)’
../../common/messages.h:39: error: changes meaning of ‘SpiceMsgData’ from
‘typedef struct SpiceMsgData SpiceMsgData’


Any help would be highly appriciated!

Thanks!

Best Regards,

Attila
___
Spice-devel mailing list
Spice-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/spice-devel

Re: [Spice-devel] spice BSD/OSX client

[Attila Sukosd]

On Fri, Jun 25, 2010 at 11:41 AM, Gerd Hoffmann  wrote:

>  Hi,
>
>
>  Also, the kqueue implementation in OS X 10.6 seem to have been broken,
>> so I went with your suggestion and reimplemented the event handler using
>> select(). One thing I noticed though was that the epoll implementation
>> watched the fds for both read and write (add_to_poll()), but since it is
>> edge triggered, it only fires once per change, but my select()
>> implementation is level triggered, which meant it would never block and
>> use up 100% CPU (for example monitoring a File fd, it always triggers).
>> After playing a bit around with it, i decided to drop watching write for
>> fds all together, and the client seem to work fine. Is there a need to
>> check it or am I safe with monitoring only reads?
>>
>
> It isn't save.  When you got -EAGAIN from a write() or send() syscall
> because the output pipe is full you have to watch for the socket becoming
> writable so you can flush out the bits you havn't sent yet.
>
> As far I know there is no bulk data going from client to server, so if you
> are working on a fast LAN it is quite possible that you never hit the
> "output pipe full" case and the client works fine for you.
>
>
>  Now on to the audio, I have been implementing audio using CoreAudio
>> Framework for OS X (another idea could be OpenAL which is also
>> cross-platform?),  which pulls in a lot of extra headers, including
>> MacTypes.h which unfortunately defines a "Rect" and "Point" struct which
>> causes issues with the definitions inside common/draw.h. I can hack
>> around it, but its not very nice, or I could rename the ones in spice,
>> but that would break any compatibility with my patches to the current
>> upstream code.
>>
>
> What code base you are working on?  In the unstable tree the structs have
> been renamed to SpiceRect and SpicePoint exactly to avoid name clashes like
> this.  Also the headers have been splitted away into a spice-protocol
> package.
>
> A few days ago Alex landed the marshaller bits in the unstable tree and the
> spice client can handle both 0.4 and unstable spice protocols now. So you
> can jump to the unstable code base even if you need the client play nicely
> with 0.4 spice servers.  This will also make it easier to merge your patches
> upstream.
>
> HTH,
>  Gerd
>
> Hi Gerd,

Thanks for the fast reply! Sounds good! Yes, right now I've been working on
version 0.4, but since the unstable tree is now backwards compatible, I will
move on to that.

Rgrds,

Attila
___
Spice-devel mailing list
Spice-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/spice-devel

Re: [Spice-devel] spice BSD/OSX client

[Attila Sukosd]

On Mon, May 31, 2010 at 10:59 AM, Alexander Larsson wrote:

> On Sat, 2010-05-29 at 20:39 +0200, Attila Sukosd wrote:
> > Hi guys,
> >
> > I have spent the last day or two doing some porting so that spicec
> > would use kqueue on bsd instead of epoll. I have disabled audio for
> > now, but once the current version works as it should, I will do a port
> > to CoreAudio aswell.
>
> For the client, i'm not sure using kqueue is the best way. It seems like
> a better idea to just move both linux and bsd to use regular poll. There
> is no way we'll have enough file descriptors on the client side to get
> any kind of scaling problems that epoll/kqueue are meant to solve, so we
> just get portability complexity for no gain.
>
> So, a better way forward is probably to drop both epoll and kqueue and
> switch to a normal poll or select.
>
> > I now have a working version, however I had to disable the shm stuff
> > in order to get it to work since I have been getting the following
> > error:
> >
> > 1275161751 ERROR spice : x_error_handler: x error on display :0.0
> > error (code 10)  BadAccess (attempt to access private resource denied)
> > major 139 minor 1 request 139
> >
> > Since the major code (139) is outside the 125? which is the standard
> > codes in X, I guessed that 139 is an Xorg extension,
> > $ xdpyinfo -display :0 -queryExtensions |grep 139
> > MIT-SHM  (opcode: 139, base event: 76, base error: 145)
> >
> > So my wild guess is that it tries to write outside the available
> > buffer?
> > Any help would be much appriciated!
>
> No. A BadAccess is an xserver message is an error return from an X call,
> saying some argument was wrong in some way related to access rights. My
> immediate guess is that some access rights on the shared memory segment
> was wrong.
>
> To debug this, add a call to
>XSynchronize (x_display, True);
>
> in Platform::init() in client/x11/platform.cpp
>
> Then you'll get the error on the actual X message that caused it and you
> can figure out what happens in the debugger.
>
>
>
> --
> =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
>  Alexander LarssonRed Hat, Inc
>   al...@redhat.comalexander.lars...@gmail.com
> He's a one-legged day-dreaming barbarian on the run. She's an artistic
> psychic
> bodyguard with an incredible destiny. They fight crime!
>
>

Hi Alex,

Thanks for your help! It turns out the issue was that shmctl(shminfo->shmid,
IPC_RMID, NULL) was called before XShmAttach() and apparently thats what
cause the issue. I moved it under XShmAttach in red_pixmap_cairo.cpp and now
it works almost perfectly.

Also, the kqueue implementation in OS X 10.6 seem to have been broken, so I
went with your suggestion and reimplemented the event handler using
select(). One thing I noticed though was that the epoll implementation
watched the fds for both read and write (add_to_poll()), but since it is
edge triggered, it only fires once per change, but my select()
implementation is level triggered, which meant it would never block and use
up 100% CPU (for example monitoring a File fd, it always triggers). After
playing a bit around with it, i decided to drop watching write for fds all
together, and the client seem to work fine. Is there a need to check it or
am I safe with monitoring only reads?

Now on to the audio, I have been implementing audio using CoreAudio
Framework for OS X (another idea could be OpenAL which is also
cross-platform?),  which pulls in a lot of extra headers, including
MacTypes.h which unfortunately defines a "Rect" and "Point" struct which
causes issues with the definitions inside common/draw.h. I can hack around
it, but its not very nice, or I could rename the ones in spice, but that
would break any compatibility with my patches to the current upstream code.

And another thing I have noticed was that sometimes when I try to play back
video (local or youtube), the video picture does not get updated (however I
see that the event handler is handling all the incoming frames) and
sometimes a square in the middle of the video gets updated but not the rest.
And, if I scroll the page or move the window while watching the video, it
refreshes fine. So I have no idea what goes on there :)


Anyway, otherwise it seem to perform pretty well.

Best Regards,

Attila
___
Spice-devel mailing list
Spice-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/spice-devel

[Spice-devel] spice BSD/OSX client

[Attila Sukosd]

Hi guys,

I have spent the last day or two doing some porting so that spicec would use
kqueue on bsd instead of epoll. I have disabled audio for now, but once the
current version works as it should, I will do a port to CoreAudio aswell.
I now have a working version, however I had to disable the shm stuff in
order to get it to work since I have been getting the following error:

1275161751 ERROR spice : x_error_handler: x error on display :0.0 error
(code 10)  BadAccess (attempt to access private resource denied) major 139
minor 1 request 139

Since the major code (139) is outside the 125? which is the standard codes
in X, I guessed that 139 is an Xorg extension,
$ xdpyinfo -display :0 -queryExtensions |grep 139
MIT-SHM  (opcode: 139, base event: 76, base error: 145)

So my wild guess is that it tries to write outside the available buffer?
Any help would be much appriciated!

Thanks a lot!

Regards,

Attila Sukosd
___
Spice-devel mailing list
Spice-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/spice-devel

Re: [Spice-devel] CEGUI xml error

[Attila Sukosd]

Hi again,


On Mon, May 3, 2010 at 1:24 PM, Attila Sukosd  wrote:
> Hi all,
>
> I have compiled the spice client from the git repo on Ubuntu 9.04, but
> when I try to launch it, nothing happens. It does create a CEGUI.log
> and it seems  like it has a problem parsing the TaharezLook.scheme
> file which is I guess define in the taharez_look.scheme.c.
>
> I have even tried creating my own taharez_look.scheme.c file out of
> the schemes provided with CEGUI without any luck.
>
> This is the error I get:
>
> 3/05/2010 13:07:09 (Std)       XercesParser::initialiseSchema -
> Attempting to load schema from file 'GUIScheme.xsd'.
> 03/05/2010 13:07:09 (Error)     CEGUI::GenericException in file
> ../../client/gui/resource_provider.cpp(83) : failed
> 03/05/2010 13:07:09 (Error)     XercesParser::parseXMLFile - An
> unexpected error occurred while parsing XML file 'TaharezLook.scheme'.
> 03/05/2010 13:07:09 (Error)     Scheme::Scheme - loading of Scheme
> from file 'TaharezLook.scheme' failed.
>
>
> Thanks a lot!
>
> Best Regads,
>
> Attila Sukosd
>
> Zsuatt v/ Attila Sukosd
> Software Development
> CVR: 30254783
> web: http://www.zsuatt.com/
>

I managed to fix it by recompiling CEGUI with the Libxml parser and
now it works fine.

Now I stumbled upon another issue using gl_fbo or gl_pbuff to render
on the client side:
canvas_get_mask: access violation 0x0 18
Aborted

Has anyone seen this before?

Cheers,

Attila Sukosd
___
Spice-devel mailing list
Spice-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/spice-devel

[Spice-devel] CEGUI xml error

[Attila Sukosd]

Hi all,

I have compiled the spice client from the git repo on Ubuntu 9.04, but
when I try to launch it, nothing happens. It does create a CEGUI.log
and it seems  like it has a problem parsing the TaharezLook.scheme
file which is I guess define in the taharez_look.scheme.c.

I have even tried creating my own taharez_look.scheme.c file out of
the schemes provided with CEGUI without any luck.

This is the error I get:

3/05/2010 13:07:09 (Std)   XercesParser::initialiseSchema -
Attempting to load schema from file 'GUIScheme.xsd'.
03/05/2010 13:07:09 (Error) CEGUI::GenericException in file
../../client/gui/resource_provider.cpp(83) : failed
03/05/2010 13:07:09 (Error) XercesParser::parseXMLFile - An
unexpected error occurred while parsing XML file 'TaharezLook.scheme'.
03/05/2010 13:07:09 (Error) Scheme::Scheme - loading of Scheme
from file 'TaharezLook.scheme' failed.


Thanks a lot!

Best Regads,

Attila Sukosd

Zsuatt v/ Attila Sukosd
Software Development
CVR: 30254783
web: http://www.zsuatt.com/
___
Spice-devel mailing list
Spice-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/spice-devel