[Spice-devel] New SPICE client for Android

[Marc-André Lureau]

Hi,


On Mon, Jun 10, 2013 at 5:40 PM, i iordanov <iiordanov at gmail.com> wrote:

>
> 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?
>
>
You can modify the guest display resolution by calling
spice_main_update_display(). Mostly for covenience, the request can be sent
automatically to the guest agent after one second. But you can decide to
disable the update timer, and send the request whenever you want, (when
rotating the device for example) with spice_main_send_monitor_config() (the
terms display and monitors are used a bit too much interchangeably, but we
usually talk about monitors for individual client display or monitors, and
a display in spice can be associated with several monitors - sorry about
that). I don't think multi-monitor is so important for Android yet anyway
;). But when connecting to a guest with multiple monitors configured, you
should decide wether to disabled or keep the extra monitors, to the risk of
having unreachable monitors or content. Perhaps a monitor switching
mechanism would be interesting?



> 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.
>
>
great!


>> 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.
>

Ok, I had a similar discussion with tarnyko a few weeks ago about Gtk
windows build. In general, my concerns about his build process are the
same. I didn't know he was also providing Android builds. I should probably
talk to him again about cerbero, which would be cleaner all-in-one solution
to ease building on different platforms..


> 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.
>
>
Isn't getScanCode() enough? With keymaps.csv you can then translate it from
Linux to xt, which is what the spice server (and qemu) expect.


- 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.
>
>
Interesting, do you have a reproducer? Feel free to file a bug to us if you
have more informations, it's a good way to help each others. Gdb should be
pretty useful to grab the backtrace of offending code:
http://stackoverflow.com/questions/10534367/how-to-get-ndk-gdb-working-on-android

- 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.
>

The split is done this way:

- spice-glib: depends only on non-toolkit libraries, it's mainly doing IO
and rendering to memory (although there used to be a gl backend, which
could be interesting in android perhaps?). As you have seen, it offers a
session and specialize channels, and misc helpers.

- spice-gtk: provides a Gtk Widget to embed a display (or monitor :-). A
Gtk+ application interacting with a Spice server can be trivially written
in just a few lines.

- spicy, virt-viewer, virt-manager, boxes, vinagre, (and aSpice) are client
applications. Spicy is meant to play and experiment quickly with the API.
virt-viewer is the most featured client we have atm. So spicy is really not
meant to be re-used, that's a bit surprising you tried to adapt it :)

I think you should not try to mimic spice-widget or spicy too much. Instead
you should write your own application and objects based on spice-glib API.
Of course, you have similarities with spice-gtk and spicy: a canvas/display
(sort of shared with jni and java canvas), and your app.

Right now I can see it's abstracting the API a lot, so you have very few
high-level functions ((OnLoad), Connect, Disconnect, SetBitmap, KeyEvent,
ButtonEvent- and OnSettingsChanged + OnGraphicsUpdate callbacks - just for
the casual reader who would be interested)

So it looks to me like android-spicy.c and android-spice-widget.c have no
need to be splitted and you could merge them. In a word, all of src/android
should be organized in a way that suits you, and don't worry about spicy or
spice-widget at all. Just make it provide the API you need.


> - 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 :).
>
>
See my question above :)


>> 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!
>
>
I am pretty sure the rest of the team is happy with that, but I'll let them
a few days to react before I had the links :)

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


-- 
Marc-André Lureau
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freedesktop.org/archives/spice-devel/attachments/20130610/e1f45f29/attachment.html>