03.11.2015, 18:43, "Christophe Fergeau" <cfergeau@xxxxxxxxxx>: > On Tue, Oct 27, 2015 at 08:42:03PM +0300, Anton D. Kachalov wrote: >> Hello, >> > > If I understand correctly, the encoding/decoding is all done in > hardware? Encoding & compressing is done in hardware while decompressing have to be done by the client. >> It works somehow on x86 host, but hangs on ARM after the first frame >> received. Here is the log from the server running on ARM: >> http://pastebin.com/TJjW8MYC >> Sometimes (usually) client gets invalid image warn: >> http://pastebin.com/eCBKT0cz > > 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. >> Any suggetsions and comments are welcome! > > Hmm, I guess hacking the stream detection code so that it thinks it > should always streamed the whole screen rather than a small part of it > counts as a workaround? Just rewrote a whole part on top of current upstream GIT head. Has implemented pseudo (or pass-through) canvas with "nop" routines except `draw_alpha_blend' and `read_bits'. It is only accepts IMAGE_TYPE_AST. Also I've added special image type to be send untouched to the client-side. This allows to reduce memory useage from above 40megs to just 20 megs (primary surface has almost zero size). > >> BTW, I've changed a bit "spice*.proto" to eliminate Alignment trapping >> on ARM. There were a lot of unaligned data access on received data. >> IMHO, using 16/32bit fields instead of 8/16 when applicable do not >> overload network so much. > > Main problem with that is that this breaks the wire protocol, older > clients would not be able to talk to newer servers and vice-versa. > It would be interesting to have more details about which messages are > causing alignment trapping issues. From a quick look, everything in > spice-common/common/messages.h should be fine / easy to fix as this is > read from the network through the generated C demarshallers. > I'd expect more issues from the link messages, and the vdagent/qxl > messages where the parsing is probably done by hand. I see. I'll try to rollback protocol's change and reproduce the misalignment issue. > > Ah, thanks for the links! Updated things live in the master branch: https://github.com/ya-mouse/spice/ https://github.com/ya-mouse/spice-protocol/ https://github.com/ya-mouse/spice-common/ Everything else stay untouched. 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. -- Anton D. Kachalov _______________________________________________ Spice-devel mailing list Spice-devel@xxxxxxxxxxxxxxxxxxxxx http://lists.freedesktop.org/mailman/listinfo/spice-devel