Hi,in fact,I'm not sure of where the bug comes,for it's said glib works well on ARM. Are you familiar with Android NDK devel.(It's rather diff. from the common ARM cross compiling.)?Do you have Android SDK/NDK and Android device that you can test the native program? You can recreate it by these: 1.I use the android NDK provided by Mozzila which has nearly full C++ support: <a href="http://ftp.mozilla.org/pub/mozilla.org/mobile/source/android-ndk-r4c-0moz3.tar.bz2" target="_blank">http://ftp.mozilla.org/pub/mozilla.org/mobile/source/android-ndk-r4c-0moz3.tar.bz2</a> and I have modified Andrew Ross's agcc to partner with this NDK: <a href="http://blog.csdn.net/rozenix/archive/2011/02/28/6212994.aspx" target="_blank">http://blog.csdn.net/rozenix/archive/2011/02/28/6212994.aspx</a> 2. Then I cross compile glib2.28.1 onto Android in this order: libbind-6.0.tar.gz libiconv-1.13.1.tar.gz gettext-0.18.1.1.tar.gz glib-2.28.1.tar.gz Also I port pixman and openssl onto android. 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 copy lib*.so libspicec.so and snappy onto Android device and run,thus come the endless SIGBUS and SIGFAULT. Can you help me on this? Thank you forward! Rgrds. <div class="gmail_quote">On Fri, Mar 18, 2011 at 6:52 PM, Alon Levy <<a href="mailto:alevy@redhat.com" target="_blank">alevy@redhat.com</a>> wrote: <blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"> <div>On Fri, Mar 18, 2011 at 06:26:09PM +0800, Shuxiang Lim wrote: > Hi, </div><div>> I have to say I cannot solve the glib bugs on Android 'cause it's too > arcane and too huge for me now. e.g such a statement will cause a segfault: > gobject/gtype.c : > return static_fundamental_type_nodes[utype >> > G_TYPE_FUNDAMENTAL_SHIFT]; > when utype==0; for why, I never know and can get no help.. > So I shall face the decision again, return to C++? No! STL and class > hierarchies etc. is even more horrible! I have only one choice: remove the > glib from the spice-gtk now. > Anybody can give some suggestions on this? > Good weekend. </div>Can I recreate this in qemu-arm? can you give instructions? Regarding converting to no glib, I don't know how hard it would be. <div><div></div><div> > On Fri, Mar 18, 2011 at 5:15 PM, Alon Levy <<a href="mailto:alevy@redhat.com" target="_blank">alevy@redhat.com</a>> wrote: > > > On Fri, Mar 18, 2011 at 02:09:38PM +0800, Shuxiang Lim wrote: > > > 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. > > > > This is strange, as I know glib is used by maemo, running on n900, which is > > an arm. > > > > No idea, sorry. > > > > > On Fri, Mar 18, 2011 at 11:52 AM, Shuxiang Lim <<a href="mailto:shohyanglim@gmail.com" target="_blank">shohyanglim@gmail.com</a> > > >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()-->CRASSSSHHHH. > > > > > > > > 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 <<a href="mailto:shohyanglim@gmail.com" target="_blank">shohyanglim@gmail.com</a> > > >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 < > > <a href="mailto:attila.sukosd@gmail.com" target="_blank">attila.sukosd@gmail.com</a>>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 <<a href="mailto:shohyanglim@gmail.com" target="_blank">shohyanglim@gmail.com</a> > > >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: > > > >>>> Tag Type Name/Value > > > >>>> 0x00000001 (NEEDED) Shared library: [libc.so] > > > >>>> 0x00000001 (NEEDED) Shared library: [libm.so] > > > >>>> 0x00000001 (NEEDED) Shared library: > > > >>>> [libpixman-1.so.0] > > > >>>> 0x00000001 (NEEDED) Shared library: > > > >>>> [libssl.so.1.0.0] > > > >>>> 0x00000001 (NEEDED) Shared library: > > > >>>> [libcrypto.so.1.0.0] > > > >>>> 0x00000001 (NEEDED) Shared library: > > [libjpeg.so.62] > > > >>>> 0x00000001 (NEEDED) Shared library: [libz.so] > > > >>>> 0x00000001 (NEEDED) Shared library: > > > >>>> [libglib-2.0.so.0] > > > >>>> 0x00000001 (NEEDED) Shared library: > > > >>>> [libgio-2.0.so.0] > > > >>>> 0x00000001 (NEEDED) Shared library: > > > >>>> [libgobject-2.0.so.0] > > > >>>> 0x00000001 (NEEDED) Shared library: > > > >>>> [libgmodule-2.0.so.0] > > > >>>> 0x00000001 (NEEDED) Shared library: > > > >>>> [libgthread-2.0.so.0] > > > >>>> 0x00000010 (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 <<a href="mailto:shohyanglim@gmail.com" target="_blank">shohyanglim@gmail.com</a> > > >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 < > > <a href="mailto:shohyanglim@gmail.com" target="_blank">shohyanglim@gmail.com</a>>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 > > > >>>>>> <ucontext.h> :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 <<a href="mailto:alevy@redhat.com" target="_blank">alevy@redhat.com</a>> > > 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 <<a href="mailto:alevy@redhat.com" target="_blank">alevy@redhat.com</a>> > > > >>>>>>> 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>>===<<inputs==>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 > > > >>>>>>> > > libraries directly, unlike spice-gtk (X and GDI). So you > > would > > > >>>>>>> basically > > > >>>>>>> > > be adding a platform/android. > > > >>>>>>> > > > > > >>>>>>> > > In gtk I really haven't done android development, ever, at > > least > > > >>>>>>> not in the > > > >>>>>>> > > C level, but I was hoping: > > > >>>>>>> > > 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. > > > >>>>>>> > > > > > >>>>>>> > > Option 2 is of course to make spice-gtk also have platform > > > >>>>>>> separation, > > > >>>>>>> > > while > > > >>>>>>> > > still using gtk/gobject for all stuff that would Just Work > > when > > > >>>>>>> doing 1.a > > > >>>>>>> > > (the > > > >>>>>>> > > data structures, the signals, the macros, the > > introspection?). > > > >>>>>>> > > > > > >>>>>>> > > > Regards. > > > >>>>>>> > > > > > > >>>>>>> > > > > > > >>>>>>> > > > On Fri, Mar 4, 2011 at 4:36 PM, Alon Levy < > > <a href="mailto:alevy@redhat.com" target="_blank">alevy@redhat.com</a>> > > > >>>>>>> wrote: > > > >>>>>>> > > > > > > >>>>>>> > > > > On Fri, Mar 04, 2011 at 03:38:51PM +0800, Shuxiang Lim > > wrote: > > > >>>>>>> > > > > > Hi all, > > > >>>>>>> > > > > > I'm trying these days to port spicec into > > Android.But > > > >>>>>>> it's a > > > >>>>>>> > > rather > > > >>>>>>> > > > > TOUGH > > > >>>>>>> > > > > > way to go because the structure of spicec and android > > are > > > >>>>>>> desperately > > > >>>>>>> > > > > > inappropriate:the linux version of spicec is based on > > the > > > >>>>>>> X11,which > > > >>>>>>> > > is > > > >>>>>>> > > > > not > > > >>>>>>> > > > > > available in Android,thus the UI of spicec should be > > > >>>>>>> rewritten from > > > >>>>>>> > > > > > scratch...More troublesome is that the UI part and data > > > >>>>>>> part in > > > >>>>>>> > > current > > > >>>>>>> > > > > > > > >>>>>>> > > > > Haven't looked at your proposal below yet, but did you > > check > > > >>>>>>> the > > > >>>>>>> > > spice-gtk > > > >>>>>>> > > > > work? maybe it is easier to start from that? are gtk > > > >>>>>>> libraries > > > >>>>>>> > > available on > > > >>>>>>> > > > > android? not talking about X. spice-gtk has objects for > > > >>>>>>> connection and > > > >>>>>>> > > > > channels > > > >>>>>>> > > > > that afaik don't do any output, that's separate from the > > > >>>>>>> actual widget > > > >>>>>>> > > that > > > >>>>>>> > > > > uses X. Also, gtk 3 has backends - did anyone do a > > backend > > > >>>>>>> for android? > > > >>>>>>> > > > > > > > >>>>>>> > > > > Since going forward we plan to ditch the spicec client, > > that > > > >>>>>>> would be > > > >>>>>>> > > > > really > > > >>>>>>> > > > > preffered. Now that I see what you have planned it sounds > > > >>>>>>> good, but > > > >>>>>>> > > better > > > >>>>>>> > > > > to use spice-gtk. > > > >>>>>>> > > > > > > > >>>>>>> > > > > of course that's not to say we won't love to see this > > working > > > >>>>>>> anyway :) > > > >>>>>>> > > > > > > > >>>>>>> > > > > > spicec is entangled in the hierarchical system in C++! > > So > > > >>>>>>> my plan is > > > >>>>>>> > > > > this: > > > >>>>>>> > > > > > first split the spicec into two parts,data and > > UI,transform > > > >>>>>>> the data > > > >>>>>>> > > part > > > >>>>>>> > > > > > into libspicec.so;then rewrite the UI part in JAVA. > > > >>>>>>> Besides, I should > > > >>>>>>> > > > > also > > > >>>>>>> > > > > > tinker some problems caused by the Crippled NDK C++ > > support > > > >>>>>>> and the > > > >>>>>>> > > Lamed > > > >>>>>>> > > > > > bionic c lib in android . > > > >>>>>>> > > > > > And now the first step is roughly done,hence the > > change > > > >>>>>>> of the > > > >>>>>>> > > spicec > > > >>>>>>> > > > > > structure: > > > >>>>>>> > > > > > From > > > >>>>>>> > > > > > > > > >>>>>>> > > |-->playback > > > >>>>>>> > > > > > thread > > > >>>>>>> > > > > > > > > >>>>>>> > > |-->cursor > > > >>>>>>> > > > > > thread > > > >>>>>>> > > > > > spicec:spicec process（application process）-->main > > > >>>>>>> thread->|-->*record > > > >>>>>>> > > > > thread > > > >>>>>>> > > > > > * > > > >>>>>>> > > > > > > > > >>>>>>> > > |-->inputs > > > >>>>>>> > > > > > thread > > > >>>>>>> > > > > > > > > >>>>>>> > > |-->display > > > >>>>>>> > > > > > thread > > > >>>>>>> > > > > > To: > > > >>>>>>> > > > > > ===========================> > > > >>>>>>> > > > > > |-->libspicec.so:application > > > >>>>>>> thread-->main > > > >>>>>>> > > > > > thread------>| > > > >>>>>>> > > > > > | > > > >>>>>>> > > > > > | > > > >>>>>>> > > > > > | |<--display > > > >>>>>>> thread<--| > > > >>>>>>> > > > > > | > > > >>>>>>> > > > > > | |--->|<--cursor > > > >>>>>>> > > > > > thread<---|<------------------| > > > >>>>>>> > > > > > | | |<--inputs > > > >>>>>>> thread<---| > > > >>>>>>> > > > > > spicec:spicec process--->| | |<--playback > > > >>>>>>> thread<-| > > > >>>>>>> > > > > > | | > > > >>>>>>> > > > > > | | > > > >>>>>>> > > > > > | | > > > >>>>>>> > > > > > <---------------------------------------------| > > > >>>>>>> > > > > > | > > > >>>>>>> > > > > > | > > > >>>>>>> > > > > > | > > > >>>>>>> > > > > > | > > > >>>>>>> > > > > > |-->spicec:platform > > > >>>>>>> > > > > > thread------------------------------>| > > > >>>>>>> > > > > > > > > >>>>>>> > > > > > The hierarchical relationship has been unleashed with > > one > > > >>>>>>> > > thread(record > > > >>>>>>> > > > > > channel) deleted and two new threads (app and platform) > > > >>>>>>> created. The > > > >>>>>>> > > > > first > > > >>>>>>> > > > > > as the "data thread",the other as the "work thread" > > which > > > >>>>>>> is driven > > > >>>>>>> > > by > > > >>>>>>> > > > > the > > > >>>>>>> > > > > > signals from the first thread as well as its sub > > threads > > > >>>>>>> and > > > >>>>>>> > > requested to > > > >>>>>>> > > > > do > > > >>>>>>> > > > > > the UI-related work: > > > >>>>>>> > > > > > > > > >>>>>>> > > > > > platform thread：------------>blocked and waiting:-->job > > > >>>>>>> > > > > > request-<--------------| > > > >>>>>>> > > > > > | | > > > >>>>>>> > > > > > | > > > >>>>>>> > > > > > ^ | > > > >>>>>>> > > > > > | > > > >>>>>>> > > > > > | > > > >>>>>>> > > > > > | | > > > >>>>>>> > > > > > > > |<----------|-<-| > > > >>>>>>> > > > > > | > > > >>>>>>> > > > > > | > > | > > > >>>>>>> > > > > > | > > > >>>>>>> > > > > > platform thread over<----------if(job==die)<--| > > > >>>>>>> send req. > > > >>>>>>> > > blocked > > > >>>>>>> > > > > > and waiting > > > >>>>>>> > > > > > | > > ^ > > > >>>>>>> | > > > >>>>>>> > > > > > | > > > >>>>>>> > > > > > | > > | > > > >>>>>>> | > > > >>>>>>> > > > > > ^ > > > >>>>>>> > > > > > | > > | > > > >>>>>>> | > > > >>>>>>> > > > > > _________|_________ > > > >>>>>>> > > > > > | > > | > > > >>>>>>> | > > > >>>>>>> > > > > > | app/plbk/cusor > > > >>>>>>> > > > > > thd > > > >>>>>>> > > > > > |<---job done----dojob()<--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 > > > >>>>>>> > > > > > <a href="http://code.google.com/p/*android*-*vnc*-viewer/,then" target="_blank">code.google.com/p/*android*-*vnc*-viewer/,then</a> 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. > > > >>>>>>> > > > > > > > >>>>>>> > > > > See above for ideas, don't read them as a criticism, I > > think > > > >>>>>>> this is > > > >>>>>>> > > > > fantastic > > > >>>>>>> > > > > what you've done so far. I remember someone posting "we > > are > > > >>>>>>> working on > > > >>>>>>> > > > > andriod > > > >>>>>>> > > > > in our spare time" post to spice-devel, please grep the > > > >>>>>>> archive. > > > >>>>>>> > > > > > > > >>>>>>> > > > > Alon > > > >>>>>>> > > > > > > > >>>>>>> > > > > > Best regards. > > > >>>>>>> > > > > > > > >>>>>>> > > > > > _______________________________________________ > > > >>>>>>> > > > > > Spice-devel mailing list > > > >>>>>>> > > > > > <a href="mailto:Spice-devel@lists.freedesktop.org" target="_blank">Spice-devel@lists.freedesktop.org</a> > > > >>>>>>> > > > > > > > <a href="http://lists.freedesktop.org/mailman/listinfo/spice-devel" target="_blank">http://lists.freedesktop.org/mailman/listinfo/spice-devel</a> > > > >>>>>>> > > > > > > > >>>>>>> > > > > > > > >>>>>>> > > > > > >>>>>>> > > > _______________________________________________ > > > >>>>>>> > > > Spice-devel mailing list > > > >>>>>>> > > > <a href="mailto:Spice-devel@lists.freedesktop.org" target="_blank">Spice-devel@lists.freedesktop.org</a> > > > >>>>>>> > > > <a href="http://lists.freedesktop.org/mailman/listinfo/spice-devel" target="_blank">http://lists.freedesktop.org/mailman/listinfo/spice-devel</a> > > > >>>>>>> > > > > > >>>>>>> > > > > > >>>>>>> > > > >>>>>>> > _______________________________________________ > > > >>>>>>> > Spice-devel mailing list > > > >>>>>>> > <a href="mailto:Spice-devel@lists.freedesktop.org" target="_blank">Spice-devel@lists.freedesktop.org</a> > > > >>>>>>> > <a href="http://lists.freedesktop.org/mailman/listinfo/spice-devel" target="_blank">http://lists.freedesktop.org/mailman/listinfo/spice-devel</a> > > > >>>>>>> > > > >>>>>>> > > > >>>>>> > > > >>>>> > > > >>>> > > > >>>> _______________________________________________ > > > >>>> Spice-devel mailing list > > > >>>> <a href="mailto:Spice-devel@lists.freedesktop.org" target="_blank">Spice-devel@lists.freedesktop.org</a> > > > >>>> <a href="http://lists.freedesktop.org/mailman/listinfo/spice-devel" target="_blank">http://lists.freedesktop.org/mailman/listinfo/spice-devel</a> > > > >>>> > > > >>>> > > > >>> > > > >> > > > > > > > > > _______________________________________________ > > > Spice-devel mailing list > > > <a href="mailto:Spice-devel@lists.freedesktop.org" target="_blank">Spice-devel@lists.freedesktop.org</a> > > > <a href="http://lists.freedesktop.org/mailman/listinfo/spice-devel" target="_blank">http://lists.freedesktop.org/mailman/listinfo/spice-devel</a> > > > > > _______________________________________________ > Spice-devel mailing list > <a href="mailto:Spice-devel@lists.freedesktop.org" target="_blank">Spice-devel@lists.freedesktop.org</a> > <a href="http://lists.freedesktop.org/mailman/listinfo/spice-devel" target="_blank">http://lists.freedesktop.org/mailman/listinfo/spice-devel</a> </div></div></blockquote></div>