[Spice-devel] aSPICE development discussion

[Marc-André Lureau]

On Tue, Jun 11, 2013 at 8:12 PM, i iordanov <iiordanov at 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freedesktop.org/archives/spice-devel/attachments/20130614/29d05604/attachment.html>