On Tue, Jun 11, 2013 at 8:12 PM, i iordanov <iiorda...@gmail.com> wrote:
> > 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. > Well, for historical and practical reasons, we have two modes. The windows driver (and the old Xinerama) is one surface per monitor (multiple display channels), while the new xorg/xrandr is actually one surface for multiple monitors. The SpiceDisplay widget handles this in update_monitor_area() using the display channel "monitors" property (in theory, there could be various monitors regions per display channel, but in practice it's either multiple channels or multiple monitors for 1 channel) > 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 have been reading from this page that it was the Linux scancode event: http://source.android.com/tech/input/keyboard-devices.html Hmm, if it's unreliable it's because the hardware is somehow broken and fixed higher up in the input stack, which sounds wrong.. Btw, there is a hardcoded Xkeysym in the spice-gtk git keymaps.csv, but it's really a bad hack (there is no other option to support browser inputs atm). This won't work well on non-english layout for example. > > - 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? > Afaik, the same code is used for all archs. We will need to fix the generator. -- Marc-André Lureau
_______________________________________________ Spice-devel mailing list Spice-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/spice-devel
