[Spice-devel] aspeed: video frames pass-through

[Anton D. Kachalov]

Hello.

consume_* in parse_msgc_display_init()

and a number of:

spice_marshaller_add_int32
spice_marshaller_add_uint16
spice_marshaller_add_uint64
spice_marshaller_add_uint32

in marshallers' functions like spice_marshall_msg_display_draw_copy()

So, for the packed structs, there are always unaligned access after first 8/16 bit consume/spice_marshaller_add.

To eliminate this behaviour we have two(?) ways:

1. Break compatibility and avoid 8/16 bit fields in packed structures.
2. Rewrite consume_*/spice_marshaller_add_* routines to make it aligned access. This might degrade the overall performance.


BTW, SPICE_TICKET_PUBKEY_BYTES definiton is unaligned too (1024 / 8 + 34) eq 162 (40 and a half double words). Used in SpiceLinkReply.


16.11.2015, 16:39, "Christophe Fergeau" <cfergeau at redhat.com>:
> On Thu, Nov 12, 2015 at 08:29:07PM +0300, Anton D. Kachalov wrote:
>>  Hello.
>>
>>  03.11.2015, 19:17, "Anton D. Kachalov" <mouse at yandex-team.ru>:
>>  > 03.11.2015, 18:43, "Christophe Fergeau" <cfergeau at redhat.com>:
>>  >>  Hmm, not very familiar with ARM, and not sure this has seen a lot of
>>  >>  testing. Maybe getting a backtrace would shed more light?
>>  >
>>  > I'll try rewritten version with original proto spec (packed int8/int16) to check what we have now.
>>
>>  Framerate is low. Very low (~0.5 FPS). Like a slideshow for video
>>  streaming. Each frame's update traps:
>>
>>     http://pastebin.com/Hz2k8gSJ
>
> Hmm, would you have a way to get a backtrace when this happens? Maybe
> there are only a few places which needs to be fixed to avoid these
> traps?
>
>>  Would it be enough to disable "packed" attribute for structures?
>>  Marshall/demarshall code just add/consume data of the requested size
>>  direct from/to the fields. No casts / memcpy. Chunks are fine too?
>
> As far as I know, the marshalling/demarshalling code uses the structs
> from spice-common/common/messages.h which are not packed.
>
>>  >
>>  > One more thing that I would like to raise.
>>  > I'm doing keycode/scancode pass to the emulated USB HID. USB
>>  > scancodes is different to XT codes. Is there exists any general
>>  > mapping functionality? I mean the following mapping:
>>  > https://www.win.tue.nl/~aeb/linux/kbd/scancodes-14.html for the US
>>  > layout.
>>
>>  I've added hardcoded keymaps for US layout using keymaps.csv file. It looks a little ugly.
>
> Not very familiar with this, this issue did not seem to happen for
> spice-clients/qemu+spice-server. I assume because the kernel or qemu are
> doing some remapping for us(??)
>
> Christophe

-- 
Anton D. Kachalov

ITO, System Architect
Tel: 7 (495) 739-70-00 ext.7613