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

Tue Nov 3 08:17:08 PST 2015

03.11.2015, 18:43, "Christophe Fergeau" <cfergeau at redhat.com>:
> 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