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