[Spice-devel] New SPICE client for Android

[i iordanov]

Hi Marc-Andre, Christophe,

I will reply to both of you in one message because Marc's reply contains
Christophe's message :). I am in Canada, so there is a time-zone difference
too.

On Mon, Jun 10, 2013 at 8:26 AM, Marc-André Lureau <
marcandre.lureau at gmail.com> wrote:
>
> Fantastic news! I played with it a bit on an Ace2, and I found it great.
> Thanks for your hard work!
>

You're welcome! It's a pleasure when I get such a positive response from
everyone.


>
> I am mostly missing guest auto-resize and sound support :) Did you hit
> technical problems or limitations from Android, or with enough time all
> should be solvable?
>

I think so. For the guest auto-resize, it was not immediately clear what I
have to do to make it happen. The client (aSPICE) certainly "knows" what
resolution it "wants" to get from the server, so it's just a matter of
expanding the API between Java and native to include a request for the
remote side to resize. Once that request is put in, everything else will be
automatic. The native layer will get a call to "primary_create", and will
then request a new bitmap from Java to draw into. Can you please point me
to the relevant code in spice-gtk to shorten my search?

Sound support is not yet coded in the Java layer. I've made sure not to
excise it from spice-gtk, in that I built celt051 for it and have included
the sound channel code in the library I build for Android. It is definitely
a planned feature, and I expect I should get working on it relatively soon.


> Btw, there is no build instructions I could find, but it looks like
> ndk-build from command line should do it.
>
>
> However, you use many prebuilt static libraries from /opt/android. How did
> you get those? (at some point I started looking at cerbero from the
> gstreamer-sdk to be able to build spice-gtk from scratch for different
> platforms)
>

Yes, apart from all those pre-built libraries in /opt/android, the build
instructions are simply "ndk-build", that part couldn't get any simpler.
The real challenge is getting some sort of coherent documentation put
together on how to build the rest. I got glib 2.28 pre-built from tarnyko.
He was also gracious enough to provide me the source and some quick notes
that he put together for building it. Please note that he says he is very
busy at the moment, so we should try not to bother him.

He has placed the source code here:
http://www.tarnyko.net/repo/agcc-glib.tar.lzma

The notes he sent me by email were:
================================================
- I used the old Mozilla r4c0moz3 ndk, like in the guy's mail. v7 gave me
troubles. The "cross-compiler" folder contains corresponding agcc.pl ;
- The build notes are in "compiler_glib/z_android-glib.
txt".
- The same folder contains static x86 versions of "glib-compile-schemas"
and "glib-genmarshal", which are needed for the process.

Please note that I'm very busy at the moment, and while I'd like to help
you, I may do it with sensible delays. I want to provide a full buildenv
myself at one time. ================================================


>
>> Oh, this is nice, thanks for the announcement. Did you need to make a lot
>> of changes to spice-gtk? I assume some of these changes could be
>> integrated upstream to make things easier for people wanting to use SPICE
>> on Android?
>>
>>
> Yes, feel free to propose changes in spice-gtk to make your life easier,
> or to improve Android support.
>

OK, you guys asked for it ;). Here are some things that I've come up
against while making aSPICE, and this is not an exhaustive list, I will
probably add to it over time:

- There is no xkeysym (used for VNC, basically an (almost) complete
mapping) to linux keycode mapping in keymaps.csv. I have put in my enormous
TODO file the following lead to follow up on in an effort to add it, but
I've simply run out of cycles up to this point. There appears to be a
method we can add the mapping programatically here:


http://stackoverflow.com/questions/10157826/xkb-how-to-convert-a-keycode-to-keysym

and I would appreciate any assistance in that matter. At the moment, aSPICE
uses win32 virtual key codes to do what should be done with xkeysyms.

- I am experiencing some alignment issues on the ARM architecture with
non-aligned access to 64-bit values that are causing SIGBUS-es. I would
like to find a solution to them.

- There is no clear delineation between the spice library used to
communicate with the server and the GTK client. Or at least I couldn't find
it documented anywhere. In order to craft the Android client, I had to hack
away a bunch of code from the GTK client (with some ideas from shohyanglim
at gmail). I've tried to keep the modifications where they belong, so over
time, we can clean them up. To summarize:

The android-spice-widget.* files are modified versions of spice-widget.*

The android-spicy.c file is a modified version of spicy.c.

- Don't even bother looking at the keymap-gen-with-android.pl and
keymaps-with-android.csv files, as they are an early idea to add the
android key-codes to keymaps.csv. That will not work right, because for
many characters there is no android keycode - we basically get a unicode
value from the KeyEvent. That unicode value has a well-established and
open-source way of being mapped to an xkeysym, which brings me back to the
first point on this list :).


> Should your client be featured on spice-space.org? it's GPL and code is
> available, so I guess it could.
>

It would be great if you would feature me on spice-space.org. I would be
honored!

Thanks for all the support and positive comments! I look forward to our
future collaboration.

Cheers!
iordan
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freedesktop.org/archives/spice-devel/attachments/20130610/14bef720/attachment.html>