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@xxxxxxxxxx>: > On Thu, Nov 12, 2015 at 08:29:07PM +0300, Anton D. Kachalov wrote: >> Hello. >> >> 03.11.2015, 19:17, "Anton D. Kachalov" <mouse@xxxxxxxxxxxxxx>: >> > 03.11.2015, 18:43, "Christophe Fergeau" <cfergeau@xxxxxxxxxx>: >> >> 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 _______________________________________________ Spice-devel mailing list Spice-devel@xxxxxxxxxxxxxxxxxxxxx http://lists.freedesktop.org/mailman/listinfo/spice-devel