Hi,
--
Marc-André Lureau
On Mon, Jun 10, 2013 at 5:40 PM, i iordanov <iiordanov@xxxxxxxxx> wrote:
great!
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.
- 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 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.
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-keysymand 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)
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.
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
_______________________________________________ Spice-devel mailing list Spice-devel@xxxxxxxxxxxxxxxxxxxxx http://lists.freedesktop.org/mailman/listinfo/spice-devel