[Spice-devel] aSPICE development discussion

[i iordanov]

Hello!

I decided to start a separate thread to discuss some of the upstream
changes I proposed.

On Mon, Jun 10, 2013 at 3:38 PM, Marc-André Lureau <
marcandre.lureau at gmail.com> wrote:

> You can modify the guest display resolution by calling
> spice_main_update_display().
>

I'll look into that as soon as possible.


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

So when you say that I have to decide, you mean that the client tells the
server what to do with the configured monitors? Why can't it simply put all
configured monitors in one large bitmap and send them over? That way,
they'll all be visible at the same time, and arranged as they are logically
configured on the server-side. Then, the Android user can zoom in wherever
they see fit, and there will be no unreachable content. Also, this way
there is no need for any switching.

bVNC already works like that with UltraVNC as reported by some of my users.


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

>From the documentation of getScanCode here:
http://developer.android.com/reference/android/view/KeyEvent.html#getScanCode%28%29

It seems the value is unreliable and hardware-dependent... getKeyCode, and
getCharacters (in the case where a keyCode does not exist for the pressed
key), appear to be the "reliable" method. I already have a reliable
mechanism of converting them to an X keysym, which is why I'm suggesting we
add a keysym -> xt mapping to keymaps.csv.


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

I know exactly where it is happening, and there is already a workaround put
in place for it. If you look into the file
"common/generated_client_demarshallers.c", and look for:

#ifdef ANDROID

near the start, you'll see the modified code.

This brings me to the next question. Do the generated_.*marshallers.c vary
from architecture to architecture? I've generated this file by running
"configure" on an amd64 system, but am compiling it for ARM. How bad is
this if at all?


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

This makes sense.


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

Alright.

Many thanks!
iordan

>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freedesktop.org/archives/spice-devel/attachments/20130611/22818d8c/attachment.html>