Re: [Spice-devel] ARM support problem
Hi,Longchao! What do you want to build for arm? The client,server,or both? The server support only x86_64 now while the client has achieved the support of the cross-compile for arm. Rgrds. On Thu, May 26, 2011 at 2:35 PM, Longchao Dong wrote: > Hi, > > I am using spice-0.8.1 and try to compile it in a arm-based machine > with linux system.But when I type ".configure",I got an error says > "Only x86 and x86-64 are supported".Then I check the "configure" file > and find that there is no "armv7l" item when it try to check the > "$host_cpu".Ohhh,my cpu is just "armv7l".So I want to know if it is ok > to just add an "armv7l" item to let "configure" pass this cpu-type > check.Of cource there is a "armv7" item in the configure file. > Thanks in advance. > > -- > Wish you happy. > Longchao Dong > http://www.donglongchao.info > ___ > 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] androidSpice-0.1.6 released
That's right,I hope I can have time to fix the alignment issues in spice(such as in generated_marshallers.c and quic.s,etc..),or some guys can try this now? On Mon, May 16, 2011 at 6:27 PM, Christophe Fergeau wrote: > On Mon, May 16, 2011 at 05:12:10PM +0800, Shuxiang Lim wrote: > > Hi,all! > >I've mentioned before about the common/quic.c will cause SIGBUG on > ARM, > > then I walked around it by '-O0',it works for armv5,armv7,but I've just > > found this didn't work for ARM9,so I have to do the final and fool way to > > rewrite some statements in quic.c with memcpy() like this: > > *#ifdef ANDROID > > memcpy(&encoder->io_next_word, encoder->io_now++,sizeof(uint32_t)); > > #else > > encoder->io_next_word = *(encoder->io_now++); > > #endif > > We really need to fix all these unaligned accesses. In quic's case, I'm > wondering whether we could make sure that the buffer we're accessing is > alinged on a 4 byte boundary? > > 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] androidSpice-0.1.6 released
Yep,I've checked this before and its instructions such as __packed pointer did not work for me. On Mon, May 16, 2011 at 6:21 PM, Christophe Fergeau wrote: > On Mon, May 16, 2011 at 12:19:50PM +0300, Yaniv Kaul wrote: > > > > Assuming this happens because of non-aligned memory access, perhaps > > trying out the suggestion in > http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.faqs/ka3721.html > > makes sense? > > This seems to be about ARM's C compiler, not GCC > > Christophe > ___ Spice-devel mailing list Spice-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/spice-devel
Re: [Spice-devel] androidSpice-0.1.6 released
Hi,all! I've mentioned before about the common/quic.c will cause SIGBUG on ARM, then I walked around it by '-O0',it works for armv5,armv7,but I've just found this didn't work for ARM9,so I have to do the final and fool way to rewrite some statements in quic.c with memcpy() like this: *#ifdef ANDROID memcpy(&encoder->io_next_word, encoder->io_now++,sizeof(uint32_t)); #else encoder->io_next_word = *(encoder->io_now++); #endif *World's tranquil again. Forgive me for I've found no easy and cute way... Best Rgrds.* * On Sat, May 14, 2011 at 12:51 AM, The Ha wrote: > I just want personally to thank you for this hard work > Great job > > Thanks > Cheers > The Ha > > > On Fri, 13 May 2011, Shuxiang Lim wrote: > > Hi,All! >> Since the dilemma I faced in the use of QXL worked around and the client >> bugs fixed,I'm glad to >> release the androidSpice-0.1.6 on google code under LGPL: >> >> http://code.google.com/p/spice-client-android/ >> >> You shall check the wiki page of it for the build/install/use of it or >> download the .apk or src files. >> Any use or improvement will be appreciated! >> Besides, this version will need no change in server side at all,that is,it >> can process all QXL-mode image types. But its response will be slower than >> the former server-jpeg way,especially with QXL. The current architect is : >> 1.libspicec.so acts as the data client and processes all image data from >> server into image buffer in mem. >> 2.when image buffer updated,android-worker.c will take the data from >> buffer, >> do jpeg_encode,then send the jpg to JAVA UI to display. >> Here is the reason I commented in jni/android-spice-src/android-worker.c: >> */* >> 177 * All the sins comes from the architect of Android: All UI must be >> 178 * written in Java(at least <2.3), so I have to send the image buffer >> data to Java >> 179 * with Little and Fast flow as possible for the Easy display of >> latter,hence the use of JPEG_COMP. >> 180 * FIXME:This maybe the only rational way,but that means androidSpice >> will never leave >> 181 * the status quo labelled EXPERIMENTAL.Tragic... >> 182 * >> 183 * FIXME: androidSpice UI in JAVA can only process the image of >> horizontal bars >> 184 * So,even QXL gives me normal tiny rectangles,I should send bars to >> JAVA. >> 185 * So I abandon some little rects to low the flow,this is stupid >> though... >> 186 */* >> >> So I think this is the reasonable way: If not all the type of images be >> processed, where is the value of SPICE? >> But the "reasonable" way must face the unreasonable obstacle in >> Android:How >> to send image to JAVA UI, with little and fast flow and easy format for >> java? >> I choose JPEG,but that's the reason why in QXL will be slower than in VGA >> STD. And there is no cursor displayed in client in QXL mode for I haven't >> compose it in JAVA UI. >> >> Is my architect right,or is my jpeg_encode decision improvable? Any ideas? >> >> (BTW,My contract will expire this month,anyone can advice or introduce a >> job >> with handsome salary in China? My current one is bleak..) >> (另，我合同本月到期，那位能帮在上海介绍一个工资拉风点的工作阿，目前的有点...) >> (因みに、コントラクトは今月に終わるので、誰がもっと適当なサラリをできる仕事を紹介してくれませんか？上海に居るんですげと。。） >> >> Best Regards. >> --LimLin-林 >> >> > Alternate Email ___ Spice-devel mailing list Spice-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/spice-devel
[Spice-devel] androidSpice-0.1.6 released
Hi,All! Since the dilemma I faced in the use of QXL worked around and the client bugs fixed,I'm glad to release the androidSpice-0.1.6 on google code under LGPL: http://code.google.com/p/spice-client-android/ You shall check the wiki page of it for the build/install/use of it or download the .apk or src files. Any use or improvement will be appreciated! Besides, this version will need no change in server side at all,that is,it can process all QXL-mode image types. But its response will be slower than the former server-jpeg way,especially with QXL. The current architect is : 1.libspicec.so acts as the data client and processes all image data from server into image buffer in mem. 2.when image buffer updated,android-worker.c will take the data from buffer, do jpeg_encode,then send the jpg to JAVA UI to display. Here is the reason I commented in jni/android-spice-src/android-worker.c: */* 177 * All the sins comes from the architect of Android: All UI must be 178 * written in Java(at least <2.3), so I have to send the image buffer data to Java 179 * with Little and Fast flow as possible for the Easy display of latter,hence the use of JPEG_COMP. 180 * FIXME:This maybe the only rational way,but that means androidSpice will never leave 181 * the status quo labelled EXPERIMENTAL.Tragic... 182 * 183 * FIXME: androidSpice UI in JAVA can only process the image of horizontal bars 184 * So,even QXL gives me normal tiny rectangles,I should send bars to JAVA. 185 * So I abandon some little rects to low the flow,this is stupid though... 186 */* So I think this is the reasonable way: If not all the type of images be processed, where is the value of SPICE? But the "reasonable" way must face the unreasonable obstacle in Android:How to send image to JAVA UI, with little and fast flow and easy format for java? I choose JPEG,but that's the reason why in QXL will be slower than in VGA STD. And there is no cursor displayed in client in QXL mode for I haven't compose it in JAVA UI. Is my architect right,or is my jpeg_encode decision improvable? Any ideas? (BTW,My contract will expire this month,anyone can advice or introduce a job with handsome salary in China? My current one is bleak..) (另，我合同本月到期，那位能帮在上海介绍一个工资拉风点的工作阿，目前的有点...) (因みに、コントラクトは今月に終わるので、誰がもっと適当なサラリをできる仕事を紹介してくれませんか？上海に居るんですげと。。） Best Regards. --LimLin-林 ___ Spice-devel mailing list Spice-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/spice-devel
Re: [Spice-devel] jpeg and jpeg_alpha in spice
Ok,
I've found a simple way in gcc manual, just disable all optimization option
in gcc by "-O0" will help this,but I'm not sure whether it's the final
solution.
Rgrds.
On Wed, May 4, 2011 at 10:33 AM, Shuxiang Lim wrote:
> Hi,Alon!
> Thanks,but now I decide to abandon such drudgery try of forcing use JPEG
> in spice-server because it's not a friendly reasonable way to spice. Now all
> that I can do currently is just attempting to fasten the image traffic
> between libspicec.so and Java UI,all the sins come from the android
> framework and Java for there is no way to access directly the image buffer
> in mem maintained by libspicec.so from Java. The only hope will be
> file-mem-mapping between C and Java, but that will never give me any
> surprise,I suppose.
> Besides,another reason that enticed me to force use of JPEG is the
> common/quic.c in client is damned buggy of SIGBUS on android/ARM on some ops
> such as pointer typecasting.
> That's common in my porting work,for example,in generated_demashaller.c,
> this
> *#define write_int8(ptr, val) *(int8_t *)(ptr) = val*
> will cause SIGBUS on ARM, so I change it into
> *#define write_int8(ptr,v) {int8_t val=v;memcpy(ptr,&val,sizeof(int8_t));
> }*
> then it's safe, but seems ugly and clumsy.
> So, is there any simple,elegant and safe way to do this?
> Best regards.
>
>
>
>
>
> On Tue, May 3, 2011 at 11:40 PM, Alon Levy wrote:
>
>> On Tue, May 03, 2011 at 11:48:59AM +0800, Shuxiang Lim wrote:
>> > Hi,All!
>>
>> Hi Shuxiang,
>>
>> AFAIK you can't avoid non jpeg images because most (all?) rendering
>> operations still happen
>> on the client, so it can't or/xor/move with mask an 'almost' bitmap.
>>
>> But the person who wrote this code should be back on the list next week,
>> so if you can
>> wait until then you should get a better answer.
>>
>> Alon
>>
>> >I've found a problem that when
>> > 1. using qxl,thus the image type will be SPICE_BITMAP_FMT_RGBA;
>> > 2. and forcing the use of red_jpeg_compress_image ('cause I want to get
>> only
>> > JPEG in client) in spice server
>> >then SPICE_IMAGE_TYPE_JPEG_ALPHA will be produced,but this will cause
>> the
>> > color disorder in the dest image in client.
>> >Normally,spice will use quic_compress or lz_compress for
>> > SPICE_BITMAP_FMT_RGBA, so SPICE_IMAGE_TYPE_JPEG_ALPHA will never be
>> used, Am
>> > I right? So why did we define SPICE_IMAGE_TYPE_JPEG_ALPHA? How can I
>> produce
>> > only NORMAL SPICE_IMAGE_TYPE_JPEG for SPICE_BITMAP_FMT_RGBA?
>> > Best Regards.
>>
>> > ___
>> > 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] jpeg and jpeg_alpha in spice
Hi,Alon!
Thanks,but now I decide to abandon such drudgery try of forcing use JPEG
in spice-server because it's not a friendly reasonable way to spice. Now all
that I can do currently is just attempting to fasten the image traffic
between libspicec.so and Java UI,all the sins come from the android
framework and Java for there is no way to access directly the image buffer
in mem maintained by libspicec.so from Java. The only hope will be
file-mem-mapping between C and Java, but that will never give me any
surprise,I suppose.
Besides,another reason that enticed me to force use of JPEG is the
common/quic.c in client is damned buggy of SIGBUS on android/ARM on some ops
such as pointer typecasting.
That's common in my porting work,for example,in generated_demashaller.c,
this
*#define write_int8(ptr, val) *(int8_t *)(ptr) = val*
will cause SIGBUS on ARM, so I change it into
*#define write_int8(ptr,v) {int8_t val=v;memcpy(ptr,&val,sizeof(int8_t)); }
*
then it's safe, but seems ugly and clumsy.
So, is there any simple,elegant and safe way to do this?
Best regards.
On Tue, May 3, 2011 at 11:40 PM, Alon Levy wrote:
> On Tue, May 03, 2011 at 11:48:59AM +0800, Shuxiang Lim wrote:
> > Hi,All!
>
> Hi Shuxiang,
>
> AFAIK you can't avoid non jpeg images because most (all?) rendering
> operations still happen
> on the client, so it can't or/xor/move with mask an 'almost' bitmap.
>
> But the person who wrote this code should be back on the list next week,
> so if you can
> wait until then you should get a better answer.
>
> Alon
>
> >I've found a problem that when
> > 1. using qxl,thus the image type will be SPICE_BITMAP_FMT_RGBA;
> > 2. and forcing the use of red_jpeg_compress_image ('cause I want to get
> only
> > JPEG in client) in spice server
> >then SPICE_IMAGE_TYPE_JPEG_ALPHA will be produced,but this will cause
> the
> > color disorder in the dest image in client.
> >Normally,spice will use quic_compress or lz_compress for
> > SPICE_BITMAP_FMT_RGBA, so SPICE_IMAGE_TYPE_JPEG_ALPHA will never be used,
> Am
> > I right? So why did we define SPICE_IMAGE_TYPE_JPEG_ALPHA? How can I
> produce
> > only NORMAL SPICE_IMAGE_TYPE_JPEG for SPICE_BITMAP_FMT_RGBA?
> > Best Regards.
>
> > ___
> > 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] jpeg and jpeg_alpha in spice
Hi,All!
I've found a problem that when
1. using qxl,thus the image type will be SPICE_BITMAP_FMT_RGBA;
2. and forcing the use of red_jpeg_compress_image ('cause I want to get only
JPEG in client) in spice server
then SPICE_IMAGE_TYPE_JPEG_ALPHA will be produced,but this will cause the
color disorder in the dest image in client.
Normally,spice will use quic_compress or lz_compress for
SPICE_BITMAP_FMT_RGBA, so SPICE_IMAGE_TYPE_JPEG_ALPHA will never be used, Am
I right? So why did we define SPICE_IMAGE_TYPE_JPEG_ALPHA? How can I produce
only NORMAL SPICE_IMAGE_TYPE_JPEG for SPICE_BITMAP_FMT_RGBA?
Best Regards.
___
Spice-devel mailing list
Spice-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/spice-devel
Re: [Spice-devel] androidSpice-0.1.4 released
On Wed, Apr 27, 2011 at 5:28 PM, Alon Levy wrote: > On Wed, Apr 27, 2011 at 04:54:55PM +0800, Shuxiang Lim wrote: > > Yep,it's really nasty. > >But if I want to leverage FULL spice image ability,I have to: > > 1.Fix the bugs of sigbus in quic.c on Android by rewriting the > > pointer-type-cast into memcpy.etc.. > No idea what the problem is, is it a compile error? can you point to the > lines/functions? > I assume we are talking about common/quic.c? > > No,it will get SIGBUSes in runtime on android and cause process killed,yes,I mean common/qui.c. It's not new to me for I have fixed the SIGBUSes in generated-demarshaller.c,,etc. before. All of them are from the pointer-typecast in C,them will be OK in x86,but not for ARM. So the quick way to fix is to rewrite them by memcpy(); > > 2.Then,then,I got the processed image buffer in memory,BUT,HOW can I > output > > it??? AFAIK,android offer no image output API for C(at least <2.3), and > Java > > cannot access memory directly(am I right?). How can I do it besides > sending > > the image data as soon and little as possible to Java via Unix-sock? > > So, no matter how fast or colorful Spice is, it's choked by Android > > framework and Java. > > what prevents you from rendering to a buffer and then giving that to java > like > you already do with the jpeg images? I confess not looking at the > androidSpice code, > so I'm not sure how exactly you do it, but the two options that come to > mind are > passing the jpeg buffer as is and letting java uncompress and display, or > uncompressing > and then passing the uncompressed buffer to java. If the later, then just > let the > existing rendering code do it's work on a memory buffer and then pass the > results. > > > > > Thus,if Java has the ability to maitain something like image buffer in > > memory like C(can it??), this may be the most-efficeint way I can > imagine: > > implementing spice protocol and rewriting UI in Java,and leaving only(or > > not) the image computing work to lib**.so via JNI. > > ok, so exactly what I outline above? but I'm not familiar with JNI or the > android > SDK. > > > But that's beyond my current scope. > > > > Any ideas to access the memory block of image buffer allocated by > > C(libspicec.so) directly in Java,instantly and swiftly? > > > > sorry, no idea. > > Anyway, I HAVE to utilize full power of SPICE rather than use only JPEG,otherwise my porting is useless.I'm searching for the way for Java to use the image buffer maintained by C. Besides,the "Over mem limit" error in Java on AVDs is caused by the little mem size of them,I will not try to do the optmstn at present. Rgrds. > > ...One more time I want to curse Android and disdain Java... > > Best regards. > > > > On Wed, Apr 27, 2011 at 4:20 PM, Alon Levy wrote: > > > > > On Wed, Apr 27, 2011 at 10:30:18AM +0800, Shuxiang Lim wrote: > > > > Hi,all! > > > >Thanks for the trying/feedbacking and sorry for the nascent itches > of > > > the > > > > project. > > > >As I've mentioned in the wiki page of this proj.,to use the > > > androidSpice, > > > > the server should be modified to force the use of JPEG > compression,and > > > qemu > > > > should not use" -vga qxl" and should use "-usbdevice tablet"(check > for > > > the > > > > reason in wikipage,maybe you can fix this),have you checked this? > > > > > > so you need to use a standard vga device and not the qxl right now? > well, > > > it's > > > certainly a good start. But you do realize without the qxl device this > is > > > no more > > > then a different vnc? i.e. it sends bitmaps only, using jpeg maybe, I > > > wasn't aware > > > we did that in this case, but no other operation (no copy / text / any > > > other rop). > > > > > > >If not forced to use JPEG,the quic algorithm in client will cause > > > SIGBUS > > > > and quit,if qxl is not disabled ,the Java UI will crash for it can > handle > > > > only SPICE_IMAGE_TYPE_JPEG=105 till now. > > > >And also,the app will cause "over memory limit" of Java in some > > > machine > > > > of android-2.2 and AVDs. > > > >I'm working to fix this,welcome to improve it! > > > >I'v uploaded the androidSpice.apk and androidSpice-debug.apk with > the > > > > latter's debug msg switched on(you can chec
Re: [Spice-devel] androidSpice-0.1.4 released
Yep,it's really nasty. But if I want to leverage FULL spice image ability,I have to: 1.Fix the bugs of sigbus in quic.c on Android by rewriting the pointer-type-cast into memcpy.etc.. 2.Then,then,I got the processed image buffer in memory,BUT,HOW can I output it??? AFAIK,android offer no image output API for C(at least <2.3), and Java cannot access memory directly(am I right?). How can I do it besides sending the image data as soon and little as possible to Java via Unix-sock? So, no matter how fast or colorful Spice is, it's choked by Android framework and Java. Thus,if Java has the ability to maitain something like image buffer in memory like C(can it??), this may be the most-efficeint way I can imagine: implementing spice protocol and rewriting UI in Java,and leaving only(or not) the image computing work to lib**.so via JNI. But that's beyond my current scope. Any ideas to access the memory block of image buffer allocated by C(libspicec.so) directly in Java,instantly and swiftly? ...One more time I want to curse Android and disdain Java... Best regards. On Wed, Apr 27, 2011 at 4:20 PM, Alon Levy wrote: > On Wed, Apr 27, 2011 at 10:30:18AM +0800, Shuxiang Lim wrote: > > Hi,all! > >Thanks for the trying/feedbacking and sorry for the nascent itches of > the > > project. > >As I've mentioned in the wiki page of this proj.,to use the > androidSpice, > > the server should be modified to force the use of JPEG compression,and > qemu > > should not use" -vga qxl" and should use "-usbdevice tablet"(check for > the > > reason in wikipage,maybe you can fix this),have you checked this? > > so you need to use a standard vga device and not the qxl right now? well, > it's > certainly a good start. But you do realize without the qxl device this is > no more > then a different vnc? i.e. it sends bitmaps only, using jpeg maybe, I > wasn't aware > we did that in this case, but no other operation (no copy / text / any > other rop). > > >If not forced to use JPEG,the quic algorithm in client will cause > SIGBUS > > and quit,if qxl is not disabled ,the Java UI will crash for it can handle > > only SPICE_IMAGE_TYPE_JPEG=105 till now. > >And also,the app will cause "over memory limit" of Java in some > machine > > of android-2.2 and AVDs. > >I'm working to fix this,welcome to improve it! > >I'v uploaded the androidSpice.apk and androidSpice-debug.apk with the > > latter's debug msg switched on(you can check the ANDROID LOG msg by #adb > > logcat). I've also uploaded the red_worker.c for server modifying(If > > needed,you can get the libspicec.so from the installed android program > file > > directory as /data/data/com.keqi*/lib/libspicec.so to use directly in the > > Android proj.). > >Best Regards. > > ---Lim---Lin林-- > > > > On Wed, Apr 27, 2011 at 6:14 AM, Gianluca Cecchi > > wrote: > > > > > Hello, > > > device is HTC Wildfire with android 2.2.1 and my guest is windows 7 on > > > F14+virt-preview repo. > > > In /var/log/libvirt/qemu/guest.log after pressing connect button I get: > > > > > > reds_handle_main_link: > > > reds_show_new_channel: channel 1:0, connected successfully, over Non > Secure > > > link > > > reds_main_handle_message: net test: latency 22.151000 ms, bitrate > > > 10769821 bps (10.270902 Mbps) > > > reds_show_new_channel: channel 2:0, connected successfully, over Non > Secure > > > link > > > red_dispatcher_set_peer: > > > handle_dev_input: connect > > > handle_new_display_channel: jpeg disabled > > > handle_new_display_channel: zlib-over-glz disabled > > > reds_show_new_channel: channel 3:0, connected successfully, over Non > Secure > > > link > > > inputs_link: > > > > > > Then error message on android device (see jpeg) > > > I select "force close" and I get in log file: > > > > > > red_receive: Connection reset by peer > > > reds_disconnect: > > > red_dispatcher_shutdown_cursor_peer: > > > red_dispatcher_shutdown_peer: > > > handle_dev_input: cursor disconnect > > > handle_dev_input: disconnect > > > > > > Connection works from another f14 pc with spicy. > > > Any information that I can give from the android device? > > > > > > Gianluca > > > > > > 2011/4/26 Mosebach Kai : > > > > Hey Lin, > > > > > > > > Just gave it a quick shot : > > > > > > > > - DNS resolving not wor
Re: [Spice-devel] androidSpice-0.1.4 released
Hi,all! Thanks for the trying/feedbacking and sorry for the nascent itches of the project. As I've mentioned in the wiki page of this proj.,to use the androidSpice, the server should be modified to force the use of JPEG compression,and qemu should not use" -vga qxl" and should use "-usbdevice tablet"(check for the reason in wikipage,maybe you can fix this),have you checked this? If not forced to use JPEG,the quic algorithm in client will cause SIGBUS and quit,if qxl is not disabled ,the Java UI will crash for it can handle only SPICE_IMAGE_TYPE_JPEG=105 till now. And also,the app will cause "over memory limit" of Java in some machine of android-2.2 and AVDs. I'm working to fix this,welcome to improve it! I'v uploaded the androidSpice.apk and androidSpice-debug.apk with the latter's debug msg switched on(you can check the ANDROID LOG msg by #adb logcat). I've also uploaded the red_worker.c for server modifying(If needed,you can get the libspicec.so from the installed android program file directory as /data/data/com.keqi*/lib/libspicec.so to use directly in the Android proj.). Best Regards. ---Lim---Lin林-- On Wed, Apr 27, 2011 at 6:14 AM, Gianluca Cecchi wrote: > Hello, > device is HTC Wildfire with android 2.2.1 and my guest is windows 7 on > F14+virt-preview repo. > In /var/log/libvirt/qemu/guest.log after pressing connect button I get: > > reds_handle_main_link: > reds_show_new_channel: channel 1:0, connected successfully, over Non Secure > link > reds_main_handle_message: net test: latency 22.151000 ms, bitrate > 10769821 bps (10.270902 Mbps) > reds_show_new_channel: channel 2:0, connected successfully, over Non Secure > link > red_dispatcher_set_peer: > handle_dev_input: connect > handle_new_display_channel: jpeg disabled > handle_new_display_channel: zlib-over-glz disabled > reds_show_new_channel: channel 3:0, connected successfully, over Non Secure > link > inputs_link: > > Then error message on android device (see jpeg) > I select "force close" and I get in log file: > > red_receive: Connection reset by peer > reds_disconnect: > red_dispatcher_shutdown_cursor_peer: > red_dispatcher_shutdown_peer: > handle_dev_input: cursor disconnect > handle_dev_input: disconnect > > Connection works from another f14 pc with spicy. > Any information that I can give from the android device? > > Gianluca > > 2011/4/26 Mosebach Kai : > > Hey Lin, > > > > Just gave it a quick shot : > > > > - DNS resolving not working? > > - access to server w/o password not supported? > > - access w/ password produces a "force kill" after a vibration > > - some traffic is seen on the spice-server side though > > > > (couldn’t connect therefore) > > > > Any logfiles I can provide? > > > > HW/SW : Android V2.2 on Samsung Galaxy Tab > > > > Cheers Kai > > > > On 4/26/11 9:43 AM, "Shuxiang Lim" wrote: > > > >>Released with src & .apk files with button-double-click fixed. > >>--Lin-- > >> > >>On 4/26/11, Shuxiang Lim wrote: > >>> Hi,all! > >>> After I workaround the bug "input will choke output",I'm glad to > >>> release the USABLE androidSpice-0.1.4 on google code: > >>> > >>> http://code.google.com/p/spice-client-android/ > >>> > >>> You shall check the wiki page of it for the build/install/use of it. > >>> Any use or improvement will be appreciated! > >>> Best Regards. > >>> --Lin-林 > >>> > >>___ > >>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] androidSpice-0.1.4 released
Released with src & .apk files with button-double-click fixed. --Lin-- On 4/26/11, Shuxiang Lim wrote: > Hi,all! > After I workaround the bug "input will choke output",I'm glad to > release the USABLE androidSpice-0.1.4 on google code: > > http://code.google.com/p/spice-client-android/ > > You shall check the wiki page of it for the build/install/use of it. > Any use or improvement will be appreciated! > Best Regards. > --Lin-林 > ___ Spice-devel mailing list Spice-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/spice-devel
[Spice-devel] androidSpice-0.1.4 released
Hi,all! After I workaround the bug "input will choke output",I'm glad to release the USABLE androidSpice-0.1.4 on google code: http://code.google.com/p/spice-client-android/ You shall check the wiki page of it for the build/install/use of it. Any use or improvement will be appreciated! Best Regards. --Lin-林 ___ Spice-devel mailing list Spice-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/spice-devel
Re: [Spice-devel] Release the androidSpice-0.1.3 experimental.
Hi,
Well,since I really don't want to get into the dirt of coroutine_*()
funcs, I force the input-channel to be ready in spice-channel.c by
change
ret = g_io_wait_interruptable(&c->wait, c->sock, G_IO_IN);
to
ret = G_IO_IN;
Now,anyway,IT WORKS,it will never hesitate to receive data from
server,thus the choking and yieldto()-->abort()-->segfault will not
happen any more,cheers!
BTW,is there any danger in such gory modification? Is there some better way?
Today will be a gorgeous spring day!
Best Regards.
--Lin--林----
On 4/26/11, Shuxiang Lim wrote:
> Now confirmed,it will fall in dead loop in spice_channel_iterate() for
> g_io_wait_interruptable()-->coroutine_yield()-->coroutine_swap() because
> coroutine_swap() always returns NULL, how to fix this? Any spice-gtk guys
> can help me?
> Rgrds.
>
> On Mon, Apr 25, 2011 at 9:08 PM, Shuxiang Lim
> wrote:
>
>> After some tracing work: I found that,when no input occurs in the
>> client,the output flow from server to client may be jammed by the slow
>> network but will never be choked.But when there's input, the client
>> will always fall soon in the endless calling for coroutine_yield() and
>> coroutine_swap() in coroutine_gthread.c (for threads prior
>> swapping???why should this?) and usually cause the "yield to
>> itself"-->abort() -->segfault. Thus,client will have no mood to
>> receive data from server at all,and the output will be choked(input
>> still OK).
>> So,why does such dead-lock-liked thing happens only on android,how
>> can I fix this,or how can I disable such Swapping? Any ideas?
>> Rgrds.
>>
>>
>> On 4/25/11, Shuxiang Lim wrote:
>> > Hi,all!
>> >I'm happy to release the experimental androidSpice under
>> > LGPL,welcome
>> to
>> > improve!
>> >The source and wiki now dwell in google code site here:
>> > http://code.google.com/p/spice-client-android/
>> >All introductions of porting can be found or redirected in the wiki
>> > page.
>> >
>> >The structure of androidSpice:
>> > 1.Data layer,extracted from spice-gtk-0.5, the main logic and data
>> > transportation/proccessing of spice protocol,along with all its
>> > dependencies,built statically into libspicec.so
>> > 2.Data layer will add two new threads in android-worker.c for the I/O
>> with
>> > Java UI layer via UNIX-sockets(see the PROBLEMS below)
>> > 3.UI layer,rewritten in Java. Output the Images and capture user-input
>> > events and communicate with libspicec.so.
>> >
>> > PROBLEMS:
>> >
>> > "The damned greatest obstacle I've faced in the porting lies in the
>> > structure of Android itself:It has no(at least for version<2.3 )
>> > exposed
>> > audio/image output and input API for C(only Java!)! So I have to
>> transport
>> > all the fixed data got from spice-server to Java layer by adding two
>> > new
>> > threads to handle the I/O communication with Java UI via two
>> > UNIX-sockets,that's the leg-drawing of speed. Besides, quic.c in client
>> is
>> > buggy of SIGBUS or SIGSEGV on android(anyone can fix it?thx!),I have no
>> > better way but to force use of JPEG compression in server and the
>> > client
>> > will send jpeg data directly to Java UI for output, it's queer and
>> > should
>> > be
>> > condemned('cause Spice's value is in the image processing ability)"
>> >
>> > So now It just WORKS,but works badly, the first untolerable bug is this
>> >
>> > Bug 1:If press fast on the device the spice-server as well as the
>> > android-spice-client will be choked and no image updates will be sent
>> > out
>> > from server.
>> > I'm still working on this bug,I need help!
>> >
>> > Best regards,
>> > --林
>> >
>>
>
___
Spice-devel mailing list
Spice-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/spice-devel
Re: [Spice-devel] Release the androidSpice-0.1.3 experimental.
Now confirmed,it will fall in dead loop in spice_channel_iterate() for
g_io_wait_interruptable()-->coroutine_yield()-->coroutine_swap() because
coroutine_swap() always returns NULL, how to fix this? Any spice-gtk guys
can help me?
Rgrds.
On Mon, Apr 25, 2011 at 9:08 PM, Shuxiang Lim wrote:
> After some tracing work: I found that,when no input occurs in the
> client,the output flow from server to client may be jammed by the slow
> network but will never be choked.But when there's input, the client
> will always fall soon in the endless calling for coroutine_yield() and
> coroutine_swap() in coroutine_gthread.c (for threads prior
> swapping???why should this?) and usually cause the "yield to
> itself"-->abort() -->segfault. Thus,client will have no mood to
> receive data from server at all,and the output will be choked(input
> still OK).
> So,why does such dead-lock-liked thing happens only on android,how
> can I fix this,or how can I disable such Swapping? Any ideas?
> Rgrds.
>
>
> On 4/25/11, Shuxiang Lim wrote:
> > Hi,all!
> >I'm happy to release the experimental androidSpice under LGPL,welcome
> to
> > improve!
> >The source and wiki now dwell in google code site here:
> > http://code.google.com/p/spice-client-android/
> >All introductions of porting can be found or redirected in the wiki
> > page.
> >
> >The structure of androidSpice:
> > 1.Data layer,extracted from spice-gtk-0.5, the main logic and data
> > transportation/proccessing of spice protocol,along with all its
> > dependencies,built statically into libspicec.so
> > 2.Data layer will add two new threads in android-worker.c for the I/O
> with
> > Java UI layer via UNIX-sockets(see the PROBLEMS below)
> > 3.UI layer,rewritten in Java. Output the Images and capture user-input
> > events and communicate with libspicec.so.
> >
> > PROBLEMS:
> >
> > "The damned greatest obstacle I've faced in the porting lies in the
> > structure of Android itself:It has no(at least for version<2.3 ) exposed
> > audio/image output and input API for C(only Java!)! So I have to
> transport
> > all the fixed data got from spice-server to Java layer by adding two new
> > threads to handle the I/O communication with Java UI via two
> > UNIX-sockets,that's the leg-drawing of speed. Besides, quic.c in client
> is
> > buggy of SIGBUS or SIGSEGV on android(anyone can fix it?thx!),I have no
> > better way but to force use of JPEG compression in server and the client
> > will send jpeg data directly to Java UI for output, it's queer and should
> > be
> > condemned('cause Spice's value is in the image processing ability)"
> >
> > So now It just WORKS,but works badly, the first untolerable bug is this
> >
> > Bug 1:If press fast on the device the spice-server as well as the
> > android-spice-client will be choked and no image updates will be sent out
> > from server.
> > I'm still working on this bug,I need help!
> >
> > Best regards,
> > --林
> >
>
___
Spice-devel mailing list
Spice-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/spice-devel
Re: [Spice-devel] Release the androidSpice-0.1.3 experimental.
Hi,Kai,
Yep,all the sin of Android is its framework: Java UI layer. But since
there are the ARM optimization for dalvik VM, as well as the opengl
ES/alsalib APIs for Java in Android, it's worthy trying to achieve
a completely Java porting ONLY IF your have enough time/energy/bugget of
this...
Rgrds.
2011/4/25 Mosebach Kai
> Too bad, that’s exactly what I was thinking of though (totally native,
> leaving out JNI hybrid) => for use in an applet for instance…
>
> But thanks for the insight!
>
> From: Shuxiang Lim mailto:shohyang...@gmail.com>>
> Date: Mon, 25 Apr 2011 22:49:23 +0800
> To: Kai Mosebach kai.moseb...@bsse.ethz.ch>>
> Subject: Re: [Spice-devel] Release the androidSpice-0.1.3 experimental.
>
> Hi,Kai,
> Sorry but I've not got your meaning, you mean,"How to rewrite all of
> spice-client in Java"?(rather than my current "Hybrid" work?)
> If yes, it's possible and not very hard for the proficient Java guys to
> implement the spice protocol in Java and leave the image/audio computing
> works( such as the work of pixman,celt,etc..) remained for C in lib*.so for
> JNI use by Java. It should not be FULLY rewritten 'cause I don't trust the
> maths computing ability of Java.
> Regards.
>
> 2011/4/25 Mosebach Kai kai.moseb...@bsse.ethz.ch>>
> Hi Shuxian,
>
> How probable / easy would it be to generate a (native) Java port out of
> this assuming that we leave Sound Support out for now?
> And (beside me owning an Galaxy Tab w/ Android <2.3) wouldn't it be much
> easier (and maybe better) to just leave out Android <2.3?
>
> Cheers and Thanks for the great Work!
>
> Kai
>
> On 4/25/11 3:08 PM, "Shuxiang Lim" shohyang...@gmail.com>> wrote:
>
> >After some tracing work: I found that,when no input occurs in the
> >client,the output flow from server to client may be jammed by the slow
> >network but will never be choked.But when there's input, the client
> >will always fall soon in the endless calling for coroutine_yield() and
> >coroutine_swap() in coroutine_gthread.c (for threads prior
> >swapping???why should this?) and usually cause the "yield to
> >itself"-->abort() -->segfault. Thus,client will have no mood to
> >receive data from server at all,and the output will be choked(input
> >still OK).
> > So,why does such dead-lock-liked thing happens only on android,how
> >can I fix this,or how can I disable such Swapping? Any ideas?
> >Rgrds.
> >
> >
> >On 4/25/11, Shuxiang Lim shohyang...@gmail.com>> wrote:
> >> Hi,all!
> >>I'm happy to release the experimental androidSpice under
> >>LGPL,welcome to
> >> improve!
> >>The source and wiki now dwell in google code site here:
> >> http://code.google.com/p/spice-client-android/
> >>All introductions of porting can be found or redirected in the wiki
> >> page.
> >>
> >>The structure of androidSpice:
> >> 1.Data layer,extracted from spice-gtk-0.5, the main logic and data
> >> transportation/proccessing of spice protocol,along with all its
> >> dependencies,built statically into libspicec.so
> >> 2.Data layer will add two new threads in android-worker.c for the I/O
> >>with
> >> Java UI layer via UNIX-sockets(see the PROBLEMS below)
> >> 3.UI layer,rewritten in Java. Output the Images and capture user-input
> >> events and communicate with libspicec.so.
> >>
> >> PROBLEMS:
> >>
> >> "The damned greatest obstacle I've faced in the porting lies in the
> >> structure of Android itself:It has no(at least for version<2.3 ) exposed
> >> audio/image output and input API for C(only Java!)! So I have to
> >>transport
> >> all the fixed data got from spice-server to Java layer by adding two new
> >> threads to handle the I/O communication with Java UI via two
> >> UNIX-sockets,that's the leg-drawing of speed. Besides, quic.c in client
> >>is
> >> buggy of SIGBUS or SIGSEGV on android(anyone can fix it?thx!),I have no
> >> better way but to force use of JPEG compression in server and the client
> >> will send jpeg data directly to Java UI for output, it's queer and
> >>should
> >> be
> >> condemned('cause Spice's value is in the image processing ability)"
> >>
> >> So now It just WORKS,but works badly, the first untolerable bug is this
> >>
> >> Bug 1:If press fast on the device the spice-server as well as the
> >> android-spice-client will be choked and no image updates will be sent
> >>out
> >> from server.
> >> I'm still working on this bug,I need help!
> >>
> >> Best regards,
> >> --林
> >>
> >___
> >Spice-devel mailing list
> >Spice-devel@lists.freedesktop.org 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] Release the androidSpice-0.1.3 experimental.
After some tracing work: I found that,when no input occurs in the
client,the output flow from server to client may be jammed by the slow
network but will never be choked.But when there's input, the client
will always fall soon in the endless calling for coroutine_yield() and
coroutine_swap() in coroutine_gthread.c (for threads prior
swapping???why should this?) and usually cause the "yield to
itself"-->abort() -->segfault. Thus,client will have no mood to
receive data from server at all,and the output will be choked(input
still OK).
So,why does such dead-lock-liked thing happens only on android,how
can I fix this,or how can I disable such Swapping? Any ideas?
Rgrds.
On 4/25/11, Shuxiang Lim wrote:
> Hi,all!
>I'm happy to release the experimental androidSpice under LGPL,welcome to
> improve!
>The source and wiki now dwell in google code site here:
> http://code.google.com/p/spice-client-android/
>All introductions of porting can be found or redirected in the wiki
> page.
>
>The structure of androidSpice:
> 1.Data layer,extracted from spice-gtk-0.5, the main logic and data
> transportation/proccessing of spice protocol,along with all its
> dependencies,built statically into libspicec.so
> 2.Data layer will add two new threads in android-worker.c for the I/O with
> Java UI layer via UNIX-sockets(see the PROBLEMS below)
> 3.UI layer,rewritten in Java. Output the Images and capture user-input
> events and communicate with libspicec.so.
>
> PROBLEMS:
>
> "The damned greatest obstacle I've faced in the porting lies in the
> structure of Android itself:It has no(at least for version<2.3 ) exposed
> audio/image output and input API for C(only Java!)! So I have to transport
> all the fixed data got from spice-server to Java layer by adding two new
> threads to handle the I/O communication with Java UI via two
> UNIX-sockets,that's the leg-drawing of speed. Besides, quic.c in client is
> buggy of SIGBUS or SIGSEGV on android(anyone can fix it?thx!),I have no
> better way but to force use of JPEG compression in server and the client
> will send jpeg data directly to Java UI for output, it's queer and should
> be
> condemned('cause Spice's value is in the image processing ability)"
>
> So now It just WORKS,but works badly, the first untolerable bug is this
>
> Bug 1:If press fast on the device the spice-server as well as the
> android-spice-client will be choked and no image updates will be sent out
> from server.
> I'm still working on this bug,I need help!
>
> Best regards,
> --林
>
___
Spice-devel mailing list
Spice-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/spice-devel
[Spice-devel] Release the androidSpice-0.1.3 experimental.
Hi,all!
I'm happy to release the experimental androidSpice under LGPL,welcome to
improve!
The source and wiki now dwell in google code site here:
http://code.google.com/p/spice-client-android/
All introductions of porting can be found or redirected in the wiki page.
The structure of androidSpice:
1.Data layer,extracted from spice-gtk-0.5, the main logic and data
transportation/proccessing of spice protocol,along with all its
dependencies,built statically into libspicec.so
2.Data layer will add two new threads in android-worker.c for the I/O with
Java UI layer via UNIX-sockets(see the PROBLEMS below)
3.UI layer,rewritten in Java. Output the Images and capture user-input
events and communicate with libspicec.so.
PROBLEMS:
"The damned greatest obstacle I've faced in the porting lies in the
structure of Android itself:It has no(at least for version<2.3 ) exposed
audio/image output and input API for C(only Java!)! So I have to transport
all the fixed data got from spice-server to Java layer by adding two new
threads to handle the I/O communication with Java UI via two
UNIX-sockets,that's the leg-drawing of speed. Besides, quic.c in client is
buggy of SIGBUS or SIGSEGV on android(anyone can fix it?thx!),I have no
better way but to force use of JPEG compression in server and the client
will send jpeg data directly to Java UI for output, it's queer and should be
condemned('cause Spice's value is in the image processing ability)"
So now It just WORKS,but works badly, the first untolerable bug is this
Bug 1:If press fast on the device the spice-server as well as the
android-spice-client will be choked and no image updates will be sent out
from server.
I'm still working on this bug,I need help!
Best regards,
--林
___
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
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 >> 0x2a000 >> (snappy:3157): GSpice-DEBUG: spice-channel.c:1257 Started background >> coroutine 0x2a02c >> (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 display-2:0: >> spice_channel_recv_link_msg: 0 caps >> (snappy:3157): GSpice-DEBUG: spice-channel.c:793 display-2:0: channel up, >> stat
Re: [Spice-devel] Porting snappy/libspicec-glib.so onto Android-ARM
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 > 0x2a000 > (snappy:3157): GSpice-DEBUG: spice-channel.c:1257 Started background > coroutine 0x2a02c > (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 display-2:0: > spice_channel_recv_link_msg: 0 caps > (snappy:3157): GSpice-DEBUG: spice-channel.c:793 display-2:0: channel up, > state 5 > (snappy:3157): GSpice-DEBUG: channel-display.c:522 display: create primary > canvas > (snappy:3157): GSpice-DEBUG: snappy.c:44 primary_create: 640x480, format 32 > wrote screen shot to ahoo.ppm > * Best Rgrds. > > > On Fri, Mar 25, 2011 at 3:17 PM, Shuxiang Lim wrote: > >> >> All the files bz2ed. >> >> On Fri, Mar 25, 2011 at 2:58 PM, Shuxiang Lim wrote: >> >>> amakefile attathed. >>> >>> >>> On Fri, Mar 25, 2011 at 2:41 PM, Shuxiang Lim wrote: >>> >>>> Hi,guys! >>>>This is my instructions and patches for porting >>>> snappy/libspicec-glib.so extracted from spicec-gtk-0.5 onto Android-ARM. >>>>It's still nascent and raw though, more hacking is needed! >>>>These are my steps, s
Re: [Spice-devel] Porting snappy/libspicec-glib.so onto Android-ARM
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 0x2a000 (snappy:3157): GSpice-DEBUG: spice-channel.c:1257 Started background coroutine 0x2a02c (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 display-2:0: spice_channel_recv_link_msg: 0 caps (snappy:3157): GSpice-DEBUG: spice-channel.c:793 display-2:0: channel up, state 5 (snappy:3157): GSpice-DEBUG: channel-display.c:522 display: create primary canvas (snappy:3157): GSpice-DEBUG: snappy.c:44 primary_create: 640x480, format 32 wrote screen shot to ahoo.ppm * Best Rgrds. On Fri, Mar 25, 2011 at 3:17 PM, Shuxiang Lim wrote: > > All the files bz2ed. > > On Fri, Mar 25, 2011 at 2:58 PM, Shuxiang Lim wrote: > >> amakefile attathed. >> >> >> On Fri, Mar 25, 2011 at 2:41 PM, Shuxiang Lim wrote: >> >>> Hi,guys! >>>This is my instructions and patches for porting >>> snappy/libspicec-glib.so extracted from spicec-gtk-0.5 onto Android-ARM. >>>It's still nascent and raw though, more hacking is needed! >>>These are my steps, suppose you're familiar with cross compiling. >>> >>> 1.I use the android NDK provided by Mozzila which has nearly full C++ >>> support: >>> >>> http://ftp.mozilla.org/pub/mozilla.org/mobile/source/android-ndk-r4c-0moz3.tar.bz2 >>> and I have modified Andrew Ross's perl script:agcc to extract and use >>> the toolchain from this NDK (attached) >>> 2. Then I cross compile glib2.28.1 onto Android in this order: >>> 1)libiconv-1.13.1.tar.gz: >>> configured by: >>> *CC=agcc CXX=agcc LD=arm-eabi-ld RANLIB=arm-eabi-ranlib \ >>> PKG_CONFIG_LIBDIR=/data/local/lib/pkgconfig:/data/local/share/pkgconfig/ >>> \ >>> ./configure \ >>> --prefix=/data/local \ >>> --host=arm-eabi-linux \* >>> *--enable-shared \* >>> 2)gettext-0.18.1.1.tar.gz >>> configured by: >>> *CC=agcc CPPFLAGS="-I/data/local/include" LDFLAGS="-L/data/local/lib" >>> CXX=agcc LD=arm-eabi-ld RANLIB=arm-eabi-ranlib \ >>> PKG_CONFIG_LIBDIR=/data/local/lib/pkgconfig:/data/local/share/pkgconfig/ >>> \ >>> ./configure \ >>> --prefix=/data/local \ >>> --host=arm-eabi-linux \ >>> --enable-shared \ >>> --cache-file=arm.cache \ >>> --without-included-regex \ >>> --disable-java --disable-openmp --without-libiconv-prefix >>> --without-libintl-prefix --without-libglib-2.0-prefix >>> --without-libcroco-0.6-prefix --with-included-libxml >>> --without-libncurses-prefix --without-libtermcap-prefix >>> --without-libcurses-prefix --without-libexpat-prefix --without-emacs >>> * But the build of gettext will not fully succeed,never mind, I need >
Re: [Spice-devel] Porting snappy/libspicec-glib.so onto Android-ARM
amakefile attathed. On Fri, Mar 25, 2011 at 2:41 PM, Shuxiang Lim wrote: > Hi,guys! >This is my instructions and patches for porting snappy/libspicec-glib.so > extracted from spicec-gtk-0.5 onto Android-ARM. >It's still nascent and raw though, more hacking is needed! >These are my steps, suppose you're familiar with cross compiling. > > 1.I use the android NDK provided by Mozzila which has nearly full C++ > support: > > http://ftp.mozilla.org/pub/mozilla.org/mobile/source/android-ndk-r4c-0moz3.tar.bz2 > and I have modified Andrew Ross's perl script:agcc to extract and use the > toolchain from this NDK (attached) > 2. Then I cross compile glib2.28.1 onto Android in this order: > 1)libiconv-1.13.1.tar.gz: > configured by: > *CC=agcc CXX=agcc LD=arm-eabi-ld RANLIB=arm-eabi-ranlib \ > PKG_CONFIG_LIBDIR=/data/local/lib/pkgconfig:/data/local/share/pkgconfig/ \ > ./configure \ > --prefix=/data/local \ > --host=arm-eabi-linux \* > *--enable-shared \* > 2)gettext-0.18.1.1.tar.gz > configured by: > *CC=agcc CPPFLAGS="-I/data/local/include" LDFLAGS="-L/data/local/lib" > CXX=agcc LD=arm-eabi-ld RANLIB=arm-eabi-ranlib \ > PKG_CONFIG_LIBDIR=/data/local/lib/pkgconfig:/data/local/share/pkgconfig/ \ > ./configure \ > --prefix=/data/local \ > --host=arm-eabi-linux \ > --enable-shared \ > --cache-file=arm.cache \ > --without-included-regex \ > --disable-java --disable-openmp --without-libiconv-prefix > --without-libintl-prefix --without-libglib-2.0-prefix > --without-libcroco-0.6-prefix --with-included-libxml > --without-libncurses-prefix --without-libtermcap-prefix > --without-libcurses-prefix --without-libexpat-prefix --without-emacs > * But the build of gettext will not fully succeed,never mind, I need > only libintl.so so just make install. > > 3) glib-2.28.1.tar.gz > 1st, do patching with my attached file > *#patch -p0 < ** glib-android.patch* > 2nd, write this into the cache file arm.cache: > *#cat > arm.cache > ac_cv_android_arm=yes > glib_cv_stack_grows=no > ** glib_cv_uscore=no* > *ac_cv_func_posix_getpwuid_r=no > ac_cv_func_posix_getgrgid_r=no* > ctrl-D > 3rd, make sure you have the tools such as glib-genmarshaller of right > vision in your host machine(you may need to first install glib on your host > machine) > 4th, autoconf;then configured the same as libiconv. > 5td, make;make install > > 3. Also I have to port pixman and openssl and jpeg onto android. > 1)pixman-0.20.0,jpeg-6b: config. make;make install same as libiconv > 2)openssl-1.0.0: config by: > ./config no-asm shared --prefix=/data/local/ > then modify the Makefile:gcc-->agcc remove the -m64..etc. > make;make install > > 4. for snappy and libspicec-glib.so > 1).tar xf spice-gtk-0.5.tar.gz > 2).#patch -p0 < snappy-android.patch (file attached) > 3).ensure to succeed in the normal ./configure and make on the current > host machine to generate config.h and some other files. > *#CC=gcc \ > ./configure \ > --prefix=/usr/local/mylocal \ > --enable-shared \ > --cache-file=arm.cache \ > --with-coroutine=gthread > #make > > *4).#cd gtk/ > 5). you may use or reference my attached file :amakfile > #make clean -f amakefile > #make -f amakefile > 6) put the lib*.so files and exec. file snappy onto android device and run. > *#LD_LIBRARY_PATH=/system/lib:/data/local/lib ./snappy -h 192.168.1.31 -p > 5900 -o ahoo.ppm* > > You may have check my snapped image ahoo.jpeg<--ahoo.ppm and run-logs in my > blogs: > http://blog.csdn.net/rozenix/archive/2011/03/25/6277742.aspx > http://blog.csdn.net/rozenix/archive/2011/03/25/6277647.aspx > > That's it! Mail me if you've got any problem! > Happy hacking! > > > > > amakefile Description: Binary data ___ Spice-devel mailing list Spice-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/spice-devel
[Spice-devel] Porting snappy/libspicec-glib.so onto Android-ARM
Hi,guys!
This is my instructions and patches for porting snappy/libspicec-glib.so
extracted from spicec-gtk-0.5 onto Android-ARM.
It's still nascent and raw though, more hacking is needed!
These are my steps, suppose you're familiar with cross compiling.
1.I use the android NDK provided by Mozzila which has nearly full C++
support:
http://ftp.mozilla.org/pub/mozilla.org/mobile/source/android-ndk-r4c-0moz3.tar.bz2
and I have modified Andrew Ross's perl script:agcc to extract and use the
toolchain from this NDK (attached)
2. Then I cross compile glib2.28.1 onto Android in this order:
1)libiconv-1.13.1.tar.gz:
configured by:
*CC=agcc CXX=agcc LD=arm-eabi-ld RANLIB=arm-eabi-ranlib \
PKG_CONFIG_LIBDIR=/data/local/lib/pkgconfig:/data/local/share/pkgconfig/ \
./configure \
--prefix=/data/local \
--host=arm-eabi-linux \*
*--enable-shared \*
2)gettext-0.18.1.1.tar.gz
configured by:
*CC=agcc CPPFLAGS="-I/data/local/include" LDFLAGS="-L/data/local/lib"
CXX=agcc LD=arm-eabi-ld RANLIB=arm-eabi-ranlib \
PKG_CONFIG_LIBDIR=/data/local/lib/pkgconfig:/data/local/share/pkgconfig/ \
./configure \
--prefix=/data/local \
--host=arm-eabi-linux \
--enable-shared \
--cache-file=arm.cache \
--without-included-regex \
--disable-java --disable-openmp --without-libiconv-prefix
--without-libintl-prefix --without-libglib-2.0-prefix
--without-libcroco-0.6-prefix --with-included-libxml
--without-libncurses-prefix --without-libtermcap-prefix
--without-libcurses-prefix --without-libexpat-prefix --without-emacs
* But the build of gettext will not fully succeed,never mind, I need only
libintl.so so just make install.
3) glib-2.28.1.tar.gz
1st, do patching with my attached file
*#patch -p0 < ** glib-android.patch*
2nd, write this into the cache file arm.cache:
*#cat > arm.cache
ac_cv_android_arm=yes
glib_cv_stack_grows=no
** glib_cv_uscore=no*
*ac_cv_func_posix_getpwuid_r=no
ac_cv_func_posix_getgrgid_r=no*
ctrl-D
3rd, make sure you have the tools such as glib-genmarshaller of right vision
in your host machine(you may need to first install glib on your host
machine)
4th, autoconf;then configured the same as libiconv.
5td, make;make install
3. Also I have to port pixman and openssl and jpeg onto android.
1)pixman-0.20.0,jpeg-6b: config. make;make install same as libiconv
2)openssl-1.0.0: config by:
./config no-asm shared --prefix=/data/local/
then modify the Makefile:gcc-->agcc remove the -m64..etc.
make;make install
4. for snappy and libspicec-glib.so
1).tar xf spice-gtk-0.5.tar.gz
2).#patch -p0 < snappy-android.patch (file attached)
3).ensure to succeed in the normal ./configure and make on the current host
machine to generate config.h and some other files.
*#CC=gcc \
./configure \
--prefix=/usr/local/mylocal \
--enable-shared \
--cache-file=arm.cache \
--with-coroutine=gthread
#make
*4).#cd gtk/
5). you may use or reference my attached file :amakfile
#make clean -f amakefile
#make -f amakefile
6) put the lib*.so files and exec. file snappy onto android device and run.
*#LD_LIBRARY_PATH=/system/lib:/data/local/lib ./snappy -h 192.168.1.31 -p
5900 -o ahoo.ppm*
You may have check my snapped image ahoo.jpeg<--ahoo.ppm and run-logs in my
blogs:
http://blog.csdn.net/rozenix/archive/2011/03/25/6277742.aspx
http://blog.csdn.net/rozenix/archive/2011/03/25/6277647.aspx
That's it! Mail me if you've got any problem!
Happy hacking!
--- ./spice-gtk-0.5/gtk/spice-channel.c 2011-01-28 03:07:24.0 +0800
+++ ./aspice-gtk-0.5/gtk/spice-channel.c 2011-03-25 09:31:47.0 +0800
@@ -1124,10 +1124,10 @@ SpiceChannel *spice_channel_new(SpiceSes
gtype = SPICE_TYPE_INPUTS_CHANNEL;
break;
case SPICE_CHANNEL_PLAYBACK:
-gtype = SPICE_TYPE_PLAYBACK_CHANNEL;
+//gtype = SPICE_TYPE_PLAYBACK_CHANNEL;
break;
case SPICE_CHANNEL_RECORD:
-gtype = SPICE_TYPE_RECORD_CHANNEL;
+//gtype = SPICE_TYPE_RECORD_CHANNEL;
break;
default:
return NULL;
--- ./spice-gtk-0.5/gtk/spice-session.c 2011-01-27 02:54:53.0 +0800
+++ ./aspice-gtk-0.5/gtk/spice-session.c 2011-03-25 09:16:43.0 +0800
@@ -984,7 +984,7 @@ int spice_session_get_connection_id(Spic
return s->connection_id;
}
-#if !GLIB_CHECK_VERSION(2,28,0)
+//#if !GLIB_CHECK_VERSION(2,28,0)
static guint64 g_get_monotonic_clock(void)
{
GTimeVal tv;
@@ -994,7 +994,7 @@ static guint64 g_get_monotonic_clock(voi
return (((gint64) tv.tv_sec) * 100) + tv.tv_usec;
}
-#endif
+//#endif
G_GNUC_INTERNAL
guint32 spice_session_get_mm_time(SpiceSession *session)
--- ./spice-gtk-0.5/gtk/channel-display.c 2011-01-24 19:47:13.0 +0800
+++ ./aspice-gtk-0.5/gtk/channel-display.c 2011-03-25 09:16:09.0 +0800
@@ -19,9 +19,11 @@
#include "config.h"
#endif
+/*
#ifdef HAVE_SYS_SHM_H
#include
#endif
+*/
#ifdef HAVE_SYS_IPC_H
#include
@@ -518,6 +520,7 @@ static int create_canvas(SpiceChannel *c
if (surface->primary) {
Re: [Spice-devel] Success in porting snappy of spicec-gtk onto Android
Hi,all! I've reported my experimental full-glib-android-porting solution as #645659 in gtk-bugzilla: https://bugzilla.gnome.org/show_bug.cgi?id=645659 You may check it. My hackings on spice-gtk to succeed the snappy/libspicec-glib.so porting onto android are very dirty and direct. If time permitted, I will file and share them soon as possible. Welcome to use, debug and improve! Best Regards. On Wed, Mar 23, 2011 at 7:25 PM, Alon Levy wrote: > On Wed, Mar 23, 2011 at 06:03:50PM +0800, Shuxiang Lim wrote: > > Hi,everyone! > >The problems of full glib porting I mentioned in the previous mails > have > > been solved, you may reference this: > > > http://www.listware.net/201103/gtk-devel-list/55247-full-glib-porting-onto-android.html > > Hi, > > Way cool. I can't really read the patch there very well. Is this something > you plan to try pushing into glib? > > Congratulations, > > Alon > > >And also after some hacking on spice-gtk(mostly on the SIGBUS/SEGFAULT > > issues,such as replace write_uint16() with memcpy(),..etc), I've > succeeded > > to compile and run snappy and libspicec.so extracted from current > spice-gtk > > for android: > > * > > #file snappy libspicec.so > > snappy: ELF 32-bit LSB executable, ARM, version 1 (SYSV), > dynamically > > linked (uses shared libs), not stripped > > libspicec.so: ELF 32-bit LSB shared object, ARM, version 1 (SYSV), > > dynamically linked, not stripped* > > *root@gnollwood:/angmar/pashwa# l*s -l > > total 6.9M > > -rw-r--r-- 1 root root 1.4M 2011-03-23 14:57 libcrypto.so.1.0.0 > > -rw-r--r-- 1 root root 1.4M 2011-03-23 14:57 libgio-2.0.so.0 > > -rw-r--r-- 1 root root 1.2M 2011-03-23 14:57 libglib-2.0.so.0 > > -rw-r--r-- 1 root root 12K 2011-03-23 14:57 libgmodule-2.0.so.0 > > -rw-r--r-- 1 root root 312K 2011-03-23 14:57 libgobject-2.0.so.0 > > -rw-r--r-- 1 root root 18K 2011-03-23 14:57 libgthread-2.0.so.0 > > -rw-r--r-- 1 root root 1010K 2011-03-23 14:57 libiconv.so.2 > > -rw-r--r-- 1 root root 41K 2011-03-23 14:57 libintl.so.8 > > -rw-r--r-- 1 root root 117K 2011-03-23 14:57 libjpeg.so.62 > > -rw-r--r-- 1 root root 457K 2011-03-23 14:57 libpixman-1.so.0 > > -rw-r--r-- 1 root root 810K 2011-03-23 14:57 libspicec.so > > -rw-r--r-- 1 root root 275K 2011-03-23 14:57 libssl.so.1.0.0 > > > > Run on the Android device: > > *##cd /data/local/* > > *##LD_LIBRARY_PATH=/data/local/lib:/system/lib ./snappy -h 192.168.1.31 > -p > > 5902 -o ahoo.ppm* > > ... > > (snappy:2135): GSpice-DEBUG: spice-channel.c:127 inputs-3:0: > > spice_channel_constructed > > (snappy:2135): GSpice-DEBUG: spice-channel.c:1414 Open coroutine starting > > 0xc2268 > > (snappy:2135): GSpice-DEBUG: spice-channel.c:1271 Started background > > coroutine 0xc2294 > > (snappy:2135): GSpice-DEBUG: spice-session.c:900 Resolving host > 192.168.1.31 > > 5902 > > (snappy:2135): GSpice-DEBUG: spice-session.c:864 Socket pending > > (snappy:2135): GSpice-DEBUG: spice-session.c:879 Finally connected > > snappy--gtype.c:g_type_class_unref:2950 > > ... > > snappy:channel-display.c:spice_display_handle_msg: 1220 > > snappy:channel-display.c:emit_invalidate: 614 > > wrote screen shot to ahoo.ppm > > *## ps > > > > *pp_321624 1169 122504 14256 afe0d984 S > > com.motorola.apncontrol > > app_401632 1169 126048 13952 afe0d984 S com.android.music > > app_651660 1169 123920 14836 afe0d984 S > com.google.android.gm > > root 2135 1712 42536 5556 afe0d06c S ./snappy > > root 2138 1148 708328 c006cb7c afe0d62c S /system/bin/sh > > root 2139 2138 860344 afe0c75c R ps > > *## cat /proc/2135/maps* > > 8000-0009e000 r-xp 1f:08 1042 /data/local/snappy > > ... > > 8000-80064000 r-xp 1f:08 1344 > > /data/local/lib/libpixman-1.so.0 > > 8010-80135000 r-xp 1f:08 1203 > > /data/local/lib/libssl.so.1.0.0 > > 8020-802ef000 r-xp 1f:08 962 > > /data/local/lib/libcrypto.so.1.0.0 > > > > 80a0-80a03000 r-xp 1f:08 1210 > > /data/local/lib/libgthread-2.0.so.0 > > 80b02000-80b03000 rw-p 1000 1f:08 1446 > > /data/local/lib/libgmodule-2.0.so.0 > > b000f000-b001 rw-p f000 1f:06 583/system/bin/linker > > ... > > *#file ahoo.ppm* > > ahoo.ppm: Netpbm PPM "rawbits" image data > > *#l ahoo.ppm * > > -rw-r--r-- 1 root root 2.3M 2011-03-23 17:24 ahoo.ppm > > > > That's it! Good luck to all! > > > ___ > > 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] Success in porting snappy of spicec-gtk onto Android
Hi,Christophe, Yes, I will share it and release my solution soon after some filing. Rgrds. On Wed, Mar 23, 2011 at 6:56 PM, Christophe Fergeau wrote: > Hi Shuxiang, > > On Wed, Mar 23, 2011 at 06:03:50PM +0800, Shuxiang Lim wrote: > >And also after some hacking on spice-gtk(mostly on the SIGBUS/SEGFAULT > > issues,such as replace write_uint16() with memcpy(),..etc), > > Are you planning to share these patches? I'm sure spice-gtk maintainers > would be interested in having a working ARM port upstream :) > > Thanks, > > Christophe > ___ Spice-devel mailing list Spice-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/spice-devel
[Spice-devel] Success in porting snappy of spicec-gtk onto Android
Hi,everyone! The problems of full glib porting I mentioned in the previous mails have been solved, you may reference this: http://www.listware.net/201103/gtk-devel-list/55247-full-glib-porting-onto-android.html And also after some hacking on spice-gtk(mostly on the SIGBUS/SEGFAULT issues,such as replace write_uint16() with memcpy(),..etc), I've succeeded to compile and run snappy and libspicec.so extracted from current spice-gtk for android: * #file snappy libspicec.so snappy: ELF 32-bit LSB executable, ARM, version 1 (SYSV), dynamically linked (uses shared libs), not stripped libspicec.so: ELF 32-bit LSB shared object, ARM, version 1 (SYSV), dynamically linked, not stripped* *root@gnollwood:/angmar/pashwa# l*s -l total 6.9M -rw-r--r-- 1 root root 1.4M 2011-03-23 14:57 libcrypto.so.1.0.0 -rw-r--r-- 1 root root 1.4M 2011-03-23 14:57 libgio-2.0.so.0 -rw-r--r-- 1 root root 1.2M 2011-03-23 14:57 libglib-2.0.so.0 -rw-r--r-- 1 root root 12K 2011-03-23 14:57 libgmodule-2.0.so.0 -rw-r--r-- 1 root root 312K 2011-03-23 14:57 libgobject-2.0.so.0 -rw-r--r-- 1 root root 18K 2011-03-23 14:57 libgthread-2.0.so.0 -rw-r--r-- 1 root root 1010K 2011-03-23 14:57 libiconv.so.2 -rw-r--r-- 1 root root 41K 2011-03-23 14:57 libintl.so.8 -rw-r--r-- 1 root root 117K 2011-03-23 14:57 libjpeg.so.62 -rw-r--r-- 1 root root 457K 2011-03-23 14:57 libpixman-1.so.0 -rw-r--r-- 1 root root 810K 2011-03-23 14:57 libspicec.so -rw-r--r-- 1 root root 275K 2011-03-23 14:57 libssl.so.1.0.0 Run on the Android device: *##cd /data/local/* *##LD_LIBRARY_PATH=/data/local/lib:/system/lib ./snappy -h 192.168.1.31 -p 5902 -o ahoo.ppm* ... (snappy:2135): GSpice-DEBUG: spice-channel.c:127 inputs-3:0: spice_channel_constructed (snappy:2135): GSpice-DEBUG: spice-channel.c:1414 Open coroutine starting 0xc2268 (snappy:2135): GSpice-DEBUG: spice-channel.c:1271 Started background coroutine 0xc2294 (snappy:2135): GSpice-DEBUG: spice-session.c:900 Resolving host 192.168.1.31 5902 (snappy:2135): GSpice-DEBUG: spice-session.c:864 Socket pending (snappy:2135): GSpice-DEBUG: spice-session.c:879 Finally connected snappy--gtype.c:g_type_class_unref:2950 ... snappy:channel-display.c:spice_display_handle_msg: 1220 snappy:channel-display.c:emit_invalidate: 614 wrote screen shot to ahoo.ppm *## ps *pp_321624 1169 122504 14256 afe0d984 S com.motorola.apncontrol app_401632 1169 126048 13952 afe0d984 S com.android.music app_651660 1169 123920 14836 afe0d984 S com.google.android.gm root 2135 1712 42536 5556 afe0d06c S ./snappy root 2138 1148 708328 c006cb7c afe0d62c S /system/bin/sh root 2139 2138 860344 afe0c75c R ps *## cat /proc/2135/maps* 8000-0009e000 r-xp 1f:08 1042 /data/local/snappy ... 8000-80064000 r-xp 1f:08 1344 /data/local/lib/libpixman-1.so.0 8010-80135000 r-xp 1f:08 1203 /data/local/lib/libssl.so.1.0.0 8020-802ef000 r-xp 1f:08 962 /data/local/lib/libcrypto.so.1.0.0 80a0-80a03000 r-xp 1f:08 1210 /data/local/lib/libgthread-2.0.so.0 80b02000-80b03000 rw-p 1000 1f:08 1446 /data/local/lib/libgmodule-2.0.so.0 b000f000-b001 rw-p f000 1f:06 583/system/bin/linker ... *#file ahoo.ppm* ahoo.ppm: Netpbm PPM "rawbits" image data *#l ahoo.ppm * -rw-r--r-- 1 root root 2.3M 2011-03-23 17:24 ahoo.ppm That's it! Good luck to all! ___ Spice-devel mailing list Spice-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/spice-devel
Re: [Spice-devel] New thread: problems in porting glib2.0 and snappy onto android
Thanks for inspiring! Sorry for being unable to response instantly 'cause we're of diff. semisphere. The android-bluetooth module DOES have glib included, it uses only libglib, and now I've compiled it under android souce into libglib.so,but it's not usable to spice-gtk for it's glib-2.0-20 which cannot afford some methods such as "g_byte_array_unref".etc,and there's none libgio/libgthread/libgmodule which are also needed by spicec-glib or snappy. As I've mentioned, in running of snappy,the segfault/sigbus comes from libgobj and my patching work is mainly in libgio. And I have found no clue of successful use of libgio..etc. in Android. So now, I suppose the problems are basically from two points:(suppose the spice-gtk has no wrong-use of glib) 1. The compiling fault such as the incorrect alignment setting which is the sin of the sigbus 2. The danger in the patching of the definitions from arpa/nameser*.h which may cause segfault. Anybody can give me some instructions of testing libg*? Appreciating. On Mon, Mar 21, 2011 at 6:30 PM, Alon Levy wrote: > On Mon, Mar 21, 2011 at 06:13:12PM +0800, Shuxiang Lim wrote: > > Hi, I open this new thread to clearly describe my condition: > > > > did you notice the post mentioning glib is actually part of android > since it's used for bluetooth? maybe you can find out which version / where > the headers / libs are and just link with it? > > I am trying to setup an environment according to your instructions but I > don't have any hw to test with. It will take me some time though. > > Alon > > > 1.I use the android NDK provided by Mozzila which has nearly full C++ > > support: > > > http://ftp.mozilla.org/pub/mozilla.org/mobile/source/android-ndk-r4c-0moz3.tar.bz2 > > and I have modified Andrew Ross's agcc to partner with this NDK: > > http://blog.csdn.net/rozenix/archive/2011/02/28/6212994.aspx > > > > 2. Then I cross compile glib2.28.1 onto Android in this order: > > 1)libiconv-1.13.1.tar.gz: > > configured by: > > *CC=agcc CXX=agcc LD=arm-eabi-ld RANLIB=arm-eabi-ranlib \ > > PKG_CONFIG_LIBDIR=/data/local/lib/pkgconfig:/data/local/share/pkgconfig/ > \ > > ./configure \ > > --prefix=/data/local \ > > --host=arm-eabi-linux \** > > --enable-malloc0returnsnull \* > > *--enable-shared \* > > 2)gettext-0.18.1.1.tar.gz > > configured by: > > *CC=agcc CPPFLAGS="-I/data/local/include" LDFLAGS="-L/data/local/lib" > > CXX=agcc LD=arm-eabi-ld RANLIB=arm-eabi-ranlib \ > > PKG_CONFIG_LIBDIR=/data/local/lib/pkgconfig:/data/local/share/pkgconfig/ > \ > > ./configure \ > > --prefix=/data/local \ > > --host=arm-eabi-linux \ > > --enable-malloc0returnsnull \ > > --enable-shared \ > > --cache-file=arm.cache \ > > --without-included-regex \ > > --disable-java --disable-openmp --without-libiconv-prefix > > --without-libintl-prefix --without-libglib-2.0-prefix > > --without-libcroco-0.6-prefix --with-included-libxml > > --without-libncurses-prefix --without-libtermcap-prefix > > --without-libcurses-prefix --without-libexpat-prefix --without-emacs > > * But the build of gettext will not fully succeed,never mind, I need > only > > libintl.so so just make install. > > > > 3) glib-2.28.1.tar.gz > > 1st, do patching with my attached file(these are all that I found that > have > > to be modified) > > 2nd, write this into the cache file arm.cache: > > *glib_cv_stack_grows=no** > > glib_cv_uscore=no > > ac_cv_func_posix_getpwuid_r=no > > ac_cv_func_posix_getgrgid_r=no* > > 3rd, configured the same as libiconv. > > 4th, remove the -lpthread in gthread/Makefile. > > 5td, make;make install > > > > 3. Also I have to port pixman and openssl onto android. > > 1)pixman-0.20.0: config. make;make install same as libiconv > > 2)openssl-1.0.0: config by: > > ./config no-asm shared --prefix=/data/local/ > > then modify the Makefile:gcc-->agcc remove the -m64..etc. > > make... > > > > 3. So I disable the audio channels and build snappy onto android with > this > > script under spice-gtk/gtk: > > #!/bin/bash > > COMMON_DIR=../common > > SPICE_GLIB_SRC="coroutine_gthread.c spice-util.c spice-session.c > > spice-channel.c spice-glib-enums.c spice-marshal.c > generated_demarshallers.c > > generated_demarshallers1.c generated_marshallers.c > generated_marshallers1.c > > gio-coroutine.c channel-base.c channel-main.c channel-display.c > > channel-display-mjpeg.c channel-cursor.c channel-inputs.c decode-
[Spice-devel] New thread: problems in porting glib2.0 and snappy onto android
Hi, I open this new thread to clearly describe my condition: 1.I use the android NDK provided by Mozzila which has nearly full C++ support: http://ftp.mozilla.org/pub/mozilla.org/mobile/source/android-ndk-r4c-0moz3.tar.bz2 and I have modified Andrew Ross's agcc to partner with this NDK: http://blog.csdn.net/rozenix/archive/2011/02/28/6212994.aspx 2. Then I cross compile glib2.28.1 onto Android in this order: 1)libiconv-1.13.1.tar.gz: configured by: *CC=agcc CXX=agcc LD=arm-eabi-ld RANLIB=arm-eabi-ranlib \ PKG_CONFIG_LIBDIR=/data/local/lib/pkgconfig:/data/local/share/pkgconfig/ \ ./configure \ --prefix=/data/local \ --host=arm-eabi-linux \** --enable-malloc0returnsnull \* *--enable-shared \* 2)gettext-0.18.1.1.tar.gz configured by: *CC=agcc CPPFLAGS="-I/data/local/include" LDFLAGS="-L/data/local/lib" CXX=agcc LD=arm-eabi-ld RANLIB=arm-eabi-ranlib \ PKG_CONFIG_LIBDIR=/data/local/lib/pkgconfig:/data/local/share/pkgconfig/ \ ./configure \ --prefix=/data/local \ --host=arm-eabi-linux \ --enable-malloc0returnsnull \ --enable-shared \ --cache-file=arm.cache \ --without-included-regex \ --disable-java --disable-openmp --without-libiconv-prefix --without-libintl-prefix --without-libglib-2.0-prefix --without-libcroco-0.6-prefix --with-included-libxml --without-libncurses-prefix --without-libtermcap-prefix --without-libcurses-prefix --without-libexpat-prefix --without-emacs * But the build of gettext will not fully succeed,never mind, I need only libintl.so so just make install. 3) glib-2.28.1.tar.gz 1st, do patching with my attached file(these are all that I found that have to be modified) 2nd, write this into the cache file arm.cache: *glib_cv_stack_grows=no** glib_cv_uscore=no ac_cv_func_posix_getpwuid_r=no ac_cv_func_posix_getgrgid_r=no* 3rd, configured the same as libiconv. 4th, remove the -lpthread in gthread/Makefile. 5td, make;make install 3. Also I have to port pixman and openssl onto android. 1)pixman-0.20.0: config. make;make install same as libiconv 2)openssl-1.0.0: config by: ./config no-asm shared --prefix=/data/local/ then modify the Makefile:gcc-->agcc remove the -m64..etc. make... 3. So I disable the audio channels and build snappy onto android with this script under spice-gtk/gtk: #!/bin/bash COMMON_DIR=../common SPICE_GLIB_SRC="coroutine_gthread.c spice-util.c spice-session.c spice-channel.c spice-glib-enums.c spice-marshal.c generated_demarshallers.c generated_demarshallers1.c generated_marshallers.c generated_marshallers1.c gio-coroutine.c channel-base.c channel-main.c channel-display.c channel-display-mjpeg.c channel-cursor.c channel-inputs.c decode-glz.c decode-jpeg.c decode-zlib.c $COMMON_DIR/mem.c $COMMON_DIR/marshaller.c $COMMON_DIR/canvas_utils.c $COMMON_DIR/sw_canvas.c $COMMON_DIR/pixman_utils.c $COMMON_DIR/lines.c $COMMON_DIR/rop3.c $COMMON_DIR/quic.c $COMMON_DIR/lz.c $COMMON_DIR/region.c $COMMON_DIR/ssl_verify.c" CPP_FLAGS="-DHAVE_CONFIG_H -DSW_CANVAS_CACHE -D_REENTRANT -I. -I.. -I../common -I/data/local/include/spice-1 -I/data/local/include/pixman-1 -I/data/local/include -I/data/local/include/glib-2.0 -I/data/local/lib/glib-2.0/include" C_FLAGS="-std=gnu99 -Wall -Wno-sign-compare -Wno-deprecated-declarations -Wl,--no-undefined -fPIC -DPIC " LD_FLAGS="-L/data/local/lib/ -lpixman-1 -lm -lssl -lcrypto -ljpeg -lz -lglib-2.0 -lgio-2.0 -lgobject-2.0 -lgmodule-2.0 -lgthread-2.0 " echo "agcc -shared -o libspicec_glib.so $SPICE_GLIB_SRC $CPP_FLAGS $C_FLAGS $LD_FLAGS" agcc -shared -o libspicec.so $SPICE_GLIB_SRC $CPP_FLAGS $C_FLAGS $LD_FLAGS agcc -o snappy spice-cmdline.c snappy.c -DG_LOG_DOMAIN=\"GSpice\" -DSW_CANVAS_CACHE -DSPICE_GTK_LOCALEDIR=\"/usr/local/share/locale\" $CPP_FLAGS $C_FLAGS $LD_FLAGS -lspicec -lintl -liconv -L./ then I put all the snappy,libspicec.so,lib*so onto android dev. and reproduce the faults. Thanks. --- glib-2.28.1/glib/gstrfuncs.c 2011-02-16 10:55:33.0 +0800 +++ aglib-2.28.1/glib/gstrfuncs.c 2011-03-21 16:33:18.0 +0800 @@ -442,8 +442,12 @@ g_ascii_strtod (const gchar *nptr, fail_pos = NULL; +#ifdef ANDROID + decimal_point = "."; +#else locale_data = localeconv (); decimal_point = locale_data->decimal_point; +#endif decimal_point_len = strlen (decimal_point); g_assert (decimal_point_len != 0); @@ -656,8 +660,12 @@ g_ascii_formatd (gchar *buffer, _g_snprintf (buffer, buf_len, format, d); +#ifdef ANDROID + decimal_point = "."; +#else locale_data = localeconv (); decimal_point = locale_data->decimal_point; +#endif decimal_point_len = strlen (decimal_point); g_assert (decimal_point_len != 0); --- glib-2.28.1/glib/gutils.c 2011-02-11 23:23:13.0 +0800 +++ aglib-2.28.1/glib/gutils.c 2011-03-21 17:08:09.0 +0800 @@ -29,6 +29,9 @@ */ #include "config.h" +#ifdef ANDROID +#undef HAVE_PWD_H +#endif #ifdef HAVE_UNISTD_H #include --- glib-2.28.1/gio/libasyncns/asyncns.c 2010-04-13 21:33:16.0 +0800 +++ aglib-2.28.1/gio/l
Re: [Spice-devel] Try to port spicec into Android
Ok,my prediction is right, this segfault is solved by disabling NLS (the use of gettext(). etc..)in glib. Yet then Bus Error comes: I know,it's mainly caused by the typecast for ARM has no same alignment style as x86.The question is: is there a way to fix this in the arm-gcc option other than rewrite the typecast statements into memcpy()?(There are huge amount of such statements in glib.). The -O0 option doesnot work. Rgrds. On Fri, Mar 18, 2011 at 11:52 AM, Shuxiang Lim wrote: > Hi,all,caution of the radioactive rays! > I feel rather frustrated though...Now I have ported libglib2.0 and its > deps(libintl,libiconv...) onto android as well as libspicec-glib.so and > snappy. > But when run,the snappy got only SEGFAULT and killed. > *#LD_LIBRARY_PATH=/data/local/lib ./snappy -h 192.168.1.31 -p 5900 -o > ahoo.ppm* > *[1] + Stopped (signal)LD_LIBRARY_PATH=/data/local/lib ./snappy -h > 192.168.1.31 -p 5900 -o ahoo.ppm > [1] Segmentation fault LD_LIBRARY_PATH=/data/local/lib ./snappy -h > 192.168.1.31 -p 5900 -o ahoo.ppm* > > Tracing the process,I found the SEGFAULT came from the > glib:g_object_new()!: > gtk/spice-session.c: > addr = g_object_new (G_TYPE_NETWORK_ADDRESS, "hostname", s->host, "port", > port, NULL); > -->libgobject:gobject/gtype.c > g_object_new()-->g_type_class_ref()-->type_class_init_Wm() > -->libgio:gio/gnetworkaddress.c > g_network_address_class_init()-->CRA. > > Now I'm still tracing the bug... It may come from the i18n string ops, but > if other bug occurs in glib,the future is dim... For I really has no time > and energy to hack the arcane and exotic glib(or it's caused by the > incorrect use of glib method in spicec?).(forgive such adjectives,to me,it's > true) > I really yearn for the spicec in PURE C and Modularized: > 1.Offer the switch to disable (do not POSIX-likedly depend on) locale, > libiconv, libintl, sys/shm.h, pwd.h, pthread,i18n, wchar_t,regex,gettext,... > for none of them can be found in android! > 2. Be as far away as we can from the other libs like the > glib/gtk,pulseaudio/alsalib... > 3. Completely modularize spicec into libspicec and spicec (this is what I > am working for) > as the data layer and the UI layer to ease the porting. > > Is there any plan about these now? Can anybody help to do the step 1 or > step 2 above? > Or, the simplest: the way to safely turn off locale and i18n in glib? > Pardon my whining and wish me Goodluck! > And again I shall desperately curse Android and bless Meego! > Regards. > > > On Thu, Mar 10, 2011 at 9:07 AM, Shuxiang Lim wrote: > >> >> That's true. But the audio output as well as the image output is unexposed >> or disabled for C/C++ apps in Android.So I plan to dwindle the work to >> implement the image first,if success, the audio work will be easy to follow. >> >> Regards. >> >> On Wed, Mar 9, 2011 at 6:22 PM, Attila Sukosd wrote: >> >>> 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:
Re: [Spice-devel] Try to port spicec into Android
Hi,all,caution of the radioactive rays! I feel rather frustrated though...Now I have ported libglib2.0 and its deps(libintl,libiconv...) onto android as well as libspicec-glib.so and snappy. But when run,the snappy got only SEGFAULT and killed. *#LD_LIBRARY_PATH=/data/local/lib ./snappy -h 192.168.1.31 -p 5900 -o ahoo.ppm* *[1] + Stopped (signal)LD_LIBRARY_PATH=/data/local/lib ./snappy -h 192.168.1.31 -p 5900 -o ahoo.ppm [1] Segmentation fault LD_LIBRARY_PATH=/data/local/lib ./snappy -h 192.168.1.31 -p 5900 -o ahoo.ppm* Tracing the process,I found the SEGFAULT came from the glib:g_object_new()!: gtk/spice-session.c: addr = g_object_new (G_TYPE_NETWORK_ADDRESS, "hostname", s->host, "port", port, NULL); -->libgobject:gobject/gtype.c g_object_new()-->g_type_class_ref()-->type_class_init_Wm() -->libgio:gio/gnetworkaddress.c g_network_address_class_init()-->CRA. Now I'm still tracing the bug... It may come from the i18n string ops, but if other bug occurs in glib,the future is dim... For I really has no time and energy to hack the arcane and exotic glib(or it's caused by the incorrect use of glib method in spicec?).(forgive such adjectives,to me,it's true) I really yearn for the spicec in PURE C and Modularized: 1.Offer the switch to disable (do not POSIX-likedly depend on) locale, libiconv, libintl, sys/shm.h, pwd.h, pthread,i18n, wchar_t,regex,gettext,... for none of them can be found in android! 2. Be as far away as we can from the other libs like the glib/gtk,pulseaudio/alsalib... 3. Completely modularize spicec into libspicec and spicec (this is what I am working for) as the data layer and the UI layer to ease the porting. Is there any plan about these now? Can anybody help to do the step 1 or step 2 above? Or, the simplest: the way to safely turn off locale and i18n in glib? Pardon my whining and wish me Goodluck! And again I shall desperately curse Android and bless Meego! Regards. On Thu, Mar 10, 2011 at 9:07 AM, Shuxiang Lim wrote: > > That's true. But the audio output as well as the image output is unexposed > or disabled for C/C++ apps in Android.So I plan to dwindle the work to > implement the image first,if success, the audio work will be easy to follow. > > Regards. > > On Wed, Mar 9, 2011 at 6:22 PM, Attila Sukosd wrote: > >> 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 tha
Re: [Spice-devel] Try to port spicec into Android
That's true. But the audio output as well as the image output is unexposed or disabled for C/C++ apps in Android.So I plan to dwindle the work to implement the image first,if success, the audio work will be easy to follow. Regards. On Wed, Mar 9, 2011 at 6:22 PM, Attila Sukosd wrote: > 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). >>>>> >&g
Re: [Spice-devel] Try to port spicec into Android
Yes,my said spicec is the spicec-gtk because I changed to for it's safer than the C++ spicec. On Wed, Mar 9, 2011 at 6:26 PM, Alon Levy wrote: > On Wed, Mar 09, 2011 at 06:18:50PM +0800, 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 * > > Cool. > > Just one thing - you keep saying spicec, the spicec is the name of the > executable > and package for the old-and-planned-to-be-phased-out-non-glib-client, so > you are > actually working with the spice-gtk repo now, right? git:// > gitorious.org/spice-gtk/spice-gtk.git? > > > 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 > > >>
Re: [Spice-devel] Try to port spicec into Android
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 t
Re: [Spice-devel] Try to port spicec into Android
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 JAVA >> > > powered >> > > > by SKIA libs.Therefore the port of UI libs(GTK,etc) will be choked >> by the >> > > > I/O level because Android don't completely expose them at all!(I >> once >> > > > managed to port Xfbdev onto it,but that's not commercially practical >> at >> > > all, >> > > > it's just a geeky trick maybe,an app in Android SHOULD NOT do this.) >> Only >> > > > the algorithm/data computing-related C/C++ libs are welcomed to be >> the >> > > JNI >> > > > servants to JAVA UI apps in Android. >> > > >You see, in such aspect, there is not too much diff between the >> C++ >> > > way >> > > > and gtk way in the porting of UI part. >> > > >> > > I'm going to try to prove that wrong by grepping hoping it makes >> sense, I >> > > never >> > > actually coded in gtk: >> > > >> > > $ git grep GObjectClass >> > > gtk/channel-cursor.c:GObjectClass *gobject_class = >> > > G_OBJECT_CLASS(klass); >> > > gtk/channel-display.c:GObjectClass *gobject_class = >> > > G_OBJECT_CLASS(klass); >> > > gtk/channel-inputs.c:GObjectClass *gobject_class = >> > > G_OBJECT_CLASS(klass);
Re: [Spice-devel] Try to port spicec into Android
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 JAVA > > > powered > > > > by SKIA libs.Therefore the port of UI libs(GTK,etc) will be choked by > the > > > > I/O level because Android don't completely expose them at all!(I > once > > > > managed to port Xfbdev onto it,but that's not commercially practical > at > > > all, > > > > it's just a geeky trick maybe,an app in Android SHOULD NOT do this.) > Only > > > > the algorithm/data computing-related C/C++ libs are welcomed to be > the > > > JNI > > > > servants to JAVA UI apps in Android. > > > >You see, in such aspect, there is not too much diff between the > C++ > > > way > > > > and gtk way in the porting of UI part. > > > > > > I'm going to try to prove that wrong by grepping hoping it makes sense, > I > > > never > > > actually coded in gtk: > > > > > > $ git grep GObjectClass > > > gtk/channel-cursor.c:GObjectClass *gobject_class = > > > G_OBJECT_CLASS(klass); > > > gtk/channel-display.c:GObjectClass *gobject_class = > > > G_OBJECT_CLASS(klass); > > > gtk/channel-inputs.c:GObjectClass *gobject_class = > > > G_OBJECT_CLASS(klass); > > > gtk/channel-main.c:GObjectClass *gobject_class = > G_OBJECT_CLASS(klass); > > > gtk/channel-playback.c:GObjectClass *gobject_class = > > > G_OBJECT_CLASS(klass); > > > gtk/channel-record.c:GObjectClass *gobject_class = > > > G_OBJECT_CLASS(klass); > > > gtk/spice-audio.h:GObjectClass parent_class; > > > gtk/spice-channel.c:GObjectClass *gobject_class = G_OBJECT_CLASS > > > (klass); > > > gtk/spice-channel.h:GObjectClass parent_class; > > > gtk/spice-gstaudio
Re: [Spice-devel] Try to port spicec into Android
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). 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.) 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 JAVA > powered > > by SKIA libs.Therefore the port of UI libs(GTK,etc) will be choked by the > > I/O level because Android don't completely expose them at all!(I once > > managed to port Xfbdev onto it,but that's not commercially practical at > all, > > it's just a geeky trick maybe,an app in Android SHOULD NOT do this.) Only > > the algorithm/data computing-related C/C++ libs are welcomed to be the > JNI > > servants to JAVA UI apps in Android. > >You see, in such aspect, there is not too much diff between the C++ > way > > and gtk way in the porting of UI part. > > I'm going to try to prove that wrong by grepping hoping it makes sense, I > never > actually coded in gtk: > > $ git grep GObjectClass > gtk/channel-cursor.c:GObjectClass *gobject_class = > G_OBJECT_CLASS(klass); > gtk/channel-display.c:GObjectClass *gobject_class = > G_OBJECT_CLASS(klass); > gtk/channel-inputs.c:GObjectClass *gobject_class = > G_OBJECT_CLASS(klass); > gtk/channel-main.c:GObjectClass *gobject_class = G_OBJECT_CLASS(klass); > gtk/channel-playback.c:GObjectClass *gobject_class = > G_OBJECT_CLASS(klass); > gtk/channel-record.c:GObjectClass *gobject_class = > G_OBJECT_CLASS(klass); > gtk/spice-audio.h:GObjectClass parent_class; > gtk/spice-channel.c:GObjectClass *gobject_class = G_OBJECT_CLASS > (klass); > gtk/spice-channel.h:GObjectClass parent_class; > gtk/spice-gstaudio.c:GObjectClass *gobject_class = > G_OBJECT_CLASS(klass); > gtk/spice-pulse.c:GObjectClass *gobject_class = G_OBJECT_CLASS(klass); > gtk/spice-session.c:GObjectClass *gobject_class = > G_OBJECT_CLASS(klass); > gtk/spice-session.h:GObjectClass parent_class; > gtk/spice-widget.c:GObjectClass *gobject_class = G_OBJECT_CLASS(klass); > > otoh: > U playa:spice-gtk alon (master)$ git grep --name-only GdkWindow > gtk/spice-widget-cairo.c > gtk/spice-widget.c > > (if you grep Window you get false negatives because of the compression > window). > > Anyway, this is a lame attempt to prove the gtk stuff that does ui (read: > uses X) > is separated in the code/architecture level :) > > >So for me the shining light of spicec-gtk is not in "GTK" but in "C". > I > > dare not to say I'm clear about every nook in spicec at all. My best hope > is > > that the IO in spicec shall be straight and succinct ,the inner > > graphic/sound computing(decompress,etc) shall have NO relation with upper > UI > > libs at all, so I can pipe the Finished image flow into UI through JNI > > interfaces and direct the user input backward. (That's why I can borrow > the > > UI from AndroidVNCViewer) > > Yeah, I think it is generally so, but again, it's so in spice-gtk too, and > that's > our only future supported client (*). > > (*) plans do change. > > > > libspicec.so(do most jobs) > > <==finishedimages/audio>>===<spicec.java.ui(only UI) > > > > Am I right? Is there any design that will frustrate this in spicec or > > spice-gtk? > > spicec is already separated at the platform level, since it uses low level >
Re: [Spice-devel] Try to port spicec into Android
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 JAVA powered by SKIA libs.Therefore the port of UI libs(GTK,etc) will be choked by the I/O level because Android don't completely expose them at all!(I once managed to port Xfbdev onto it,but that's not commercially practical at all, it's just a geeky trick maybe,an app in Android SHOULD NOT do this.) Only the algorithm/data computing-related C/C++ libs are welcomed to be the JNI servants to JAVA UI apps in Android. You see, in such aspect, there is not too much diff between the C++ way and gtk way in the porting of UI part. So for me the shining light of spicec-gtk is not in "GTK" but in "C". I dare not to say I'm clear about every nook in spicec at all. My best hope is that the IO in spicec shall be straight and succinct ,the inner graphic/sound computing(decompress,etc) shall have NO relation with upper UI libs at all, so I can pipe the Finished image flow into UI through JNI interfaces and direct the user input backward. (That's why I can borrow the UI from AndroidVNCViewer) libspicec.so(do most jobs) <==finishedimages/audio>>===<spicec.java.ui(only UI) Am I right? Is there any design that will frustrate this in spicec or spice-gtk? Regards. On Fri, Mar 4, 2011 at 4:36 PM, 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<-| > > | | > > | | > > | | > > <-| > > | > > | > > | > > | >
[Spice-devel] Try to port spicec into Android
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 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 scratch. It's tough too, for I have poor experiance in Java... Anyway, is there any other guy working on this? Is my way feasible??Any Ideas or help is appreciated. Best regards. ___ Spice-devel mailing list Spice-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/spice-devel
[Spice-devel] where ? Repo of VDAgent-0.6.3-win32
Hi all! I want to update my vdagent-win32 solution to 0.6.3 to do some fix on it, but I can find only the repo of 0.6.0 in http://git.freedesktop.org/git/spice/win32/vd_agent and the exe of vdagent-0.6.3 (I wanna the source file.), where is the current source files of vdagent-0.6.3? thanks. ___ Spice-devel mailing list Spice-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/spice-devel
[Spice-devel] Spice_Ubuntu_Install_Error
Hi,all! I'm a fresher in spice who try to install the spice C\S in Ubuntu 9.04 under the instructions in http://docs.cslabs.clarkson.edu/wiki/SPICE, fluent first, the spice client is well installed, yet I got the error in the step of # install vdesktop when in vdesktop/ I do "sudo ./configure --enable-spice", I got: [: 335: yes: unexpected operator Install prefix/usr/local BIOS directory/usr/local/share/qemu binary directory /usr/local/bin Manual directory /usr/local/share/man ELF interp prefix /usr/gnemul/qemu-%M Source path /home/sxlin/spice-sources/vdesktop/qemu C compilergcc Host C compiler gcc ARCH_CFLAGS -m64 make make install install host CPU x86_64 host big endian no target list x86_64-softmmu gprof enabled no sparse enabledno profiler no static build no -Werror enabled no SDL support yes SDL static link yes curses supportyes mingw32 support no Audio drivers oss Extra audio cards ac97 Mixer emulation no VNC TLS support yes TLS CFLAGS TLS LIBS -lgnutls libgcrypt support yes gcrypt CFLAGS gcrypt LIBS-lgcrypt kqemu support no kvm support no CPU emulation yes brlapi supportno Documentation no NPTL support yes vde support no AIO support yes QXL yes Spice yes SMB directoresyes SCSI devices yes ISAPC support yes KVM nestedno USB storage yes USB wacom yes USB serialyes USB net yes USB bluez no VMware driversyes NBD support yes bluetooth support no Only generic cpus no Then, in .../vdesktop/libkvm/ I do "sudo make ", here comes the error: gcc -m64 -D__x86_64__ -MMD -MF ./.libkvm.d -g -fomit-frame-pointer -Wall -fno-stack-protector -I /home/sxlin/spice-sources/vdesktop/kernel/include -c -o libkvm.o libkvm.c In file included from libkvm.c:38: libkvm.h:811: warning: ‘struct kvm_irq_routing_entry’ declared inside parameter list libkvm.h:811: warning: its scope is only this definition or declaration, which is probably not what you want libkvm.h:822: warning: ‘struct kvm_irq_routing_entry’ declared inside parameter list libkvm.c: In function ‘kvm_set_irq_level’: libkvm.c:672: error: ‘struct kvm_irq_level’ has no member named ‘status’ libkvm.c: At top level: libkvm.c:1269: warning: ‘struct kvm_irq_routing_entry’ declared inside parameter list libkvm.c:1268: error: conflicting types for ‘kvm_add_routing_entry’ libkvm.h:810: error: previous declaration of ‘kvm_add_routing_entry’ was here libkvm.c:1321: warning: ‘struct kvm_irq_routing_entry’ declared inside parameter list libkvm.c:1320: error: conflicting types for ‘kvm_del_routing_entry’ libkvm.h:821: error: previous declaration of ‘kvm_del_routing_entry’ was here libkvm.c: In function ‘kvm_get_irq_route_gsi’: libkvm.c:1404: error: ‘struct kvm_context’ has no member named ‘max_used_gsi’ libkvm.c:1405: error: ‘struct kvm_context’ has no member named ‘max_used_gsi’ libkvm.c:1406: error: ‘struct kvm_context’ has no member named ‘max_used_gsi’ libkvm.c:1411: warning: control reaches end of non-void function make: *** [libkvm.o] Error 1 Any ideas,It's a very low-level error, I mean it's the error from the codes, is it because of some failure in the pre-processor?(Some parameters have not been correctly generated. uhr..). OR it's because that I'v already installed the qemu+kvm before the spice? Any idea? Appreciating... ___ Spice-devel mailing list Spice-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/spice-devel
