From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1NJveK-0008L1-4S for qemu-devel@nongnu.org; Sun, 13 Dec 2009 16:06:40 -0500 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1NJveG-0008J9-H1 for qemu-devel@nongnu.org; Sun, 13 Dec 2009 16:06:39 -0500 Received: from [199.232.76.173] (port=36513 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1NJveG-0008J3-Ak for qemu-devel@nongnu.org; Sun, 13 Dec 2009 16:06:36 -0500 Received: from mx1.redhat.com ([209.132.183.28]:2004) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1NJveF-0008NJ-Hm for qemu-devel@nongnu.org; Sun, 13 Dec 2009 16:06:36 -0500 Received: from int-mx03.intmail.prod.int.phx2.redhat.com (int-mx03.intmail.prod.int.phx2.redhat.com [10.5.11.16]) by mx1.redhat.com (8.13.8/8.13.8) with ESMTP id nBDL6W3h009075 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Sun, 13 Dec 2009 16:06:32 -0500 Received: from mail05.corp.redhat.com (zmail05.collab.prod.int.phx2.redhat.com [10.5.5.46]) by int-mx03.intmail.prod.int.phx2.redhat.com (8.13.8/8.13.8) with ESMTP id nBDL6Wgc014062 for ; Sun, 13 Dec 2009 16:06:32 -0500 Date: Sun, 13 Dec 2009 16:06:32 -0500 (EST) From: Yaniv Kaul Message-ID: <575929515.1599781260738392519.JavaMail.root@zmail05.collab.prod.int.phx2.redhat.com> In-Reply-To: <1783738934.1599701260735354287.JavaMail.root@zmail05.collab.prod.int.phx2.redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Subject: [Qemu-devel] Question on QEMU's VNC Server hextile implementation List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: qemu-devel@nongnu.org According to the RFB protocol, section 6.6.4 (hextile encoding), regarding the 'ForegroundSpecified' bit, it says: 'If this bit is set then the SubrectsColoured bit must be zero.'. It doesn't seem QEMU's VNC server does that. In fact, it looks like both bits are set. I've verified against a different VNC server, and I didn't see this happening. (it may be a Wireshark dissector bug, of course). TIA, Y.