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