[Spice-devel] Try to port spicec into Android
Shuxiang Lim
shohyanglim at gmail.com
Wed Mar 9 16:57:01 PST 2011
Yes,my said spicec is the spicec-gtk because I changed to for it's safer
than the C++ spicec.
On Wed, Mar 9, 2011 at 6:26 PM, Alon Levy <alevy at redhat.com> wrote:
> On Wed, Mar 09, 2011 at 06:18:50PM +0800, Shuxiang Lim 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 *
>
> Cool.
>
> Just one thing - you keep saying spicec, the spicec is the name of the
> executable
> and package for the old-and-planned-to-be-phased-out-non-glib-client, so
> you are
> actually working with the spice-gtk repo now, right? git://
> gitorious.org/spice-gtk/spice-gtk.git?
>
> > 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
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freedesktop.org/archives/spice-devel/attachments/20110310/f3f442ad/attachment-0001.htm>
More information about the Spice-devel
mailing list