@everybody: Are there any known issues with bitmap decompression, or with bitmap drawing in the X11 client? In this case it's 16bpp, if this makes a difference.
Long version: To make sure we all talk about the same packages, please see the file attached. Let me outline the communication sequence (skip to #51 for the short version): Preconnection information - packet 1: preconnection blob with VM id Establish secure connection - packets 2-5: SSL handshake - packets 6-10: CredSSP … stuff. Let's just assume it works, because there is a lot of communication afterwards. Connection initiation, basic settings exchange - packets 11 & 12: X.224 Connection Request & Confirm - packets 13 & 14: Connect-Inital PDU with GCC Conference Create Request & Connect-Response Channel connection - packet 15: Erect Domain Request - packets 16 & 17: Attach User Request & Confirm - packets 18-21: two Join Channel Requests and Confirms Secure settings exchange, licensing - packet 22: Client Info PDU - packet 23: License Error PDU Capabilities exchange - packet 24: Demand Active PDU (interesting: the server requests 32 bpp although the client declared it cannot handle 32 bpp) - packet 25: Confirm Active PDU (interesting: the client honors the 32 bpp request) Connection finalization - packets 26-34: server's Synchronize PDU, server's Cooperate Control PDU, client's Synchronize PDU, client's Cooperate Control PDU, client's Request Control PDU, server's Granted Control PDU, client's Persistent Key List PDU, client's Font List PDU, server's Font Map PDU Deactivation-reactivation sequence - packet 35: Deactivate All PDU - packets 36-46: repetition of packets 24-34, except shareId is now 0x000203ea instead of 0x000103ea and preferredBitsPerPixel is now 16 instead 32. So the 32 bpp from packets 24 and 25 do not matter anymore. - packet 47: Save Session Info (login notification) RDP payload messages - packet 48 & 49: Fast-Path Input events (tab key released & sync event) - packet 50: Fast-Path Update with the cursor image (the cursor is drawn fine btw.) - packet 51: Fast-Path Update with the first bitmap from the server (it's 16bpp) If I stop FreeRDP from processing any further fast-path bitmap updates at this point, I end up with a distorted little rectangle in the upper left corner of the screen. So obviously something goes wrong in decoding or drawing the rectangle. The communication before that point looks ok to me. So let's have a look at the bitmap decompression and drawing. Any ideas? Any known issues? On Jul 23, 2012, at 8:18 AM, nikhil wrote: > Yes you are right, graphics is badly distorted. > I captured few packets to look in to them. After 3-way handshaking, the first > packet that is sent from client looks good. > At least it's format is exactly the same as they have pointed out in the open > specification. > But the packet that is sent after this one is different when compared with the > one that is sent from the windows client. > > any ideas on this? > > > ------------------------------------------------------------------------------ > Live Security Virtual Conference > Exclusive live event will cover all the ways today's security and > threat landscape has changed and how IT managers can respond. Discussions > will include endpoint security, mobile security and the latest in malware > threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ > _______________________________________________ > Freerdp-devel mailing list > Freerdp-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/freerdp-devel ------------------------------------------------------------------------------ Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ _______________________________________________ Freerdp-devel mailing list Freerdp-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freerdp-devel
