[Spice-devel] Try to port spicec into Android
Shuxiang Lim
shohyanglim at gmail.com
Tue Mar 8 19:10:03 PST 2011
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
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freedesktop.org/archives/spice-devel/attachments/20110309/e9e31dc4/attachment.htm>
More information about the Spice-devel
mailing list