[Spice-devel] Try to port spicec into Android
Shuxiang Lim
shohyanglim at gmail.com
Sun Mar 20 21:01:43 PDT 2011
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:
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:
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.
On Fri, Mar 18, 2011 at 6:52 PM, Alon Levy <alevy at redhat.com> wrote:
> On Fri, Mar 18, 2011 at 06:26:09PM +0800, Shuxiang Lim wrote:
> > Hi,
> > 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.
>
> 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.
>
> > On Fri, Mar 18, 2011 at 5:15 PM, Alon Levy <alevy at redhat.com> 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 <
> shohyanglim at gmail.com
> > > >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 <
> shohyanglim at gmail.com
> > > >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 <
> > > attila.sukosd at gmail.com>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 <
> shohyanglim at gmail.com
> > > >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 <
> shohyanglim at gmail.com
> > > >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 <
> > > shohyanglim at gmail.com>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 <alevy at redhat.com>
> > > 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 <
> alevy at redhat.com>
> > > > >>>>>>> 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 <
> > > alevy at redhat.com>
> > > > >>>>>>> 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
> > > > >>>>>>> > > > > > 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.
> > > > >>>>>>> > > > >
> > > > >>>>>>> > > > > 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
> > > > >>>>>>> > > > > > Spice-devel at lists.freedesktop.org
> > > > >>>>>>> > > > > >
> > > http://lists.freedesktop.org/mailman/listinfo/spice-devel
> > > > >>>>>>> > > > >
> > > > >>>>>>> > > > >
> > > > >>>>>>> > >
> > > > >>>>>>> > > > _______________________________________________
> > > > >>>>>>> > > > Spice-devel mailing list
> > > > >>>>>>> > > > Spice-devel at lists.freedesktop.org
> > > > >>>>>>> > > >
> http://lists.freedesktop.org/mailman/listinfo/spice-devel
> > > > >>>>>>> > >
> > > > >>>>>>> > >
> > > > >>>>>>>
> > > > >>>>>>> > _______________________________________________
> > > > >>>>>>> > Spice-devel mailing list
> > > > >>>>>>> > Spice-devel at lists.freedesktop.org
> > > > >>>>>>> > http://lists.freedesktop.org/mailman/listinfo/spice-devel
> > > > >>>>>>>
> > > > >>>>>>>
> > > > >>>>>>
> > > > >>>>>
> > > > >>>>
> > > > >>>> _______________________________________________
> > > > >>>> Spice-devel mailing list
> > > > >>>> Spice-devel at lists.freedesktop.org
> > > > >>>> http://lists.freedesktop.org/mailman/listinfo/spice-devel
> > > > >>>>
> > > > >>>>
> > > > >>>
> > > > >>
> > > > >
> > >
> > > > _______________________________________________
> > > > Spice-devel mailing list
> > > > Spice-devel at lists.freedesktop.org
> > > > http://lists.freedesktop.org/mailman/listinfo/spice-devel
> > >
> > >
>
> > _______________________________________________
> > Spice-devel mailing list
> > Spice-devel at lists.freedesktop.org
> > http://lists.freedesktop.org/mailman/listinfo/spice-devel
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freedesktop.org/archives/spice-devel/attachments/20110321/d31e0574/attachment.htm>
More information about the Spice-devel
mailing list