On Tue, Jun 11, 2013 at 8:12 PM, i iordanov <iiordanov@xxxxxxxxx> wrote:
I have been reading from this page that it was the Linux scancode event: http://source.android.com/tech/input/keyboard-devices.html
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 ANDROIDnear 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@xxxxxxxxxxxxxxxxxxxxx http://lists.freedesktop.org/mailman/listinfo/spice-devel