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 <[email protected]> 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 <[email protected]>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 <[email protected]> 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 <[email protected]> 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 <[email protected]> >>> 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 >>> > > > > > [email protected] >>> > > > > > http://lists.freedesktop.org/mailman/listinfo/spice-devel >>> > > > > >>> > > > > >>> > > >>> > > > _______________________________________________ >>> > > > Spice-devel mailing list >>> > > > [email protected] >>> > > > http://lists.freedesktop.org/mailman/listinfo/spice-devel >>> > > >>> > > >>> >>> > _______________________________________________ >>> > Spice-devel mailing list >>> > [email protected] >>> > http://lists.freedesktop.org/mailman/listinfo/spice-devel >>> >>> >> >
_______________________________________________ Spice-devel mailing list [email protected] http://lists.freedesktop.org/mailman/listinfo/spice-devel
