<div dir="ltr"><div>Hello!<br><br></div>I decided to start a separate thread to discuss some of the upstream changes I proposed.<br><div><div><br><div class="gmail_quote">On Mon, Jun 10, 2013 at 3:38 PM, Marc-André Lureau <span dir="ltr"><<a href="mailto:marcandre.lureau@gmail.com" target="_blank">marcandre.lureau@gmail.com</a>></span> wrote:<br> <blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div><div class="gmail_extra"><div class="gmail_quote"><div>You can modify the guest display resolution by calling spice_main_update_display().</div></div></div></div></div></blockquote><div><br></div><div>I'll look into that as soon as possible.<br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"> <div dir="ltr"><div><div class="gmail_extra"><div class="gmail_quote"><div>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?<br></div></div></div></div></div></blockquote><div><br></div><div>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.<br> </div><div><br></div><div>bVNC already works like that with UltraVNC as reported by some of my users.<br> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"> <div dir="ltr"><div><div class="gmail_extra"><div class="gmail_quote">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.<br></div></div></div></div></blockquote><div><br>From the documentation of getScanCode here:<br><a href="http://developer.android.com/reference/android/view/KeyEvent.html#getScanCode%28%29">http://developer.android.com/reference/android/view/KeyEvent.html#getScanCode%28%29</a><br> <br></div><div>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.<br> </div><div> <br><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div><div class="gmail_extra"><div class="gmail_quote"><div class="im"> <blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div>- 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.<br> </div><div><br></div></div></div></div></blockquote><div><br></div></div><div>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: <a href="http://stackoverflow.com/questions/10534367/how-to-get-ndk-gdb-working-on-android" target="_blank">http://stackoverflow.com/questions/10534367/how-to-get-ndk-gdb-working-on-android</a><br> </div></div></div></div></div></blockquote><div><br></div><div>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:<br> <br>#ifdef ANDROID<br><br></div><div>near the start, you'll see the modified code.<br><br></div><div>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?<br> </div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div><div class="gmail_extra"><div class="gmail_quote"><br><div>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.<br></div></div></div></div></div></blockquote><div><br></div><div>This makes sense.<br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"> <div dir="ltr"><div><div class="gmail_extra"><div class="gmail_quote"><div> <br></div><div>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.<br></div></div></div></div></div></blockquote><div><br></div><div>Alright.<br></div><div class="gmail_extra"><br></div><div class="gmail_extra">Many thanks!<br>iordan<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"> </blockquote></div></div></div></div>