[Spice-devel] Try to port spicec into Android
Shuxiang Lim
shohyanglim at gmail.com
Wed Mar 9 17:07:55 PST 2011
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 <attila.sukosd at gmail.com>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 <shohyanglim at gmail.com>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 <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/b6398f9b/attachment-0001.htm>
More information about the Spice-devel
mailing list