[Spice-devel] Try to port spicec into Android
Alon Levy
alevy at redhat.com
Fri Mar 18 03:52:22 PDT 2011
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
More information about the Spice-devel
mailing list