From mboxrd@z Thu Jan  1 00:00:00 1970
Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43)
	id 1Md5at-0004T0-4D
	for qemu-devel@nongnu.org; Mon, 17 Aug 2009 13:02:03 -0400
Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43)
	id 1Md5an-0004No-OA
	for qemu-devel@nongnu.org; Mon, 17 Aug 2009 13:02:02 -0400
Received: from [199.232.76.173] (port=57368 helo=monty-python.gnu.org)
	by lists.gnu.org with esmtp (Exim 4.43) id 1Md5an-0004Ne-J6
	for qemu-devel@nongnu.org; Mon, 17 Aug 2009 13:01:57 -0400
Received: from mail.gmx.net ([213.165.64.20]:43006)
	by monty-python.gnu.org with smtp (Exim 4.60)
	(envelope-from <Reimar.Doeffinger@gmx.de>) id 1Md5am-0003pM-OO
	for qemu-devel@nongnu.org; Mon, 17 Aug 2009 13:01:57 -0400
Date: Mon, 17 Aug 2009 19:01:54 +0200
From: Reimar =?iso-8859-1?Q?D=F6ffinger?= <Reimar.Doeffinger@gmx.de>
Message-ID: <20090817170154.GA1893@1und1.de>
References: <20090817155814.GA1665@1und1.de>
 <4A8989C9.8060302@gnu.org>
MIME-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <4A8989C9.8060302@gnu.org>
Subject: [Qemu-devel] Re: [PATCH] sdl.c: support 32 bpp cursors
List-Id: qemu-devel.nongnu.org
List-Unsubscribe: <http://lists.nongnu.org/mailman/listinfo/qemu-devel>,
	<mailto:qemu-devel-request@nongnu.org?subject=unsubscribe>
List-Archive: <http://lists.gnu.org/pipermail/qemu-devel>
List-Post: <mailto:qemu-devel@nongnu.org>
List-Help: <mailto:qemu-devel-request@nongnu.org?subject=help>
List-Subscribe: <http://lists.nongnu.org/mailman/listinfo/qemu-devel>,
	<mailto:qemu-devel-request@nongnu.org?subject=subscribe>
To: qemu-devel@nongnu.org

On Mon, Aug 17, 2009 at 06:48:09PM +0200, Paolo Bonzini wrote:
> On 08/17/2009 05:58 PM, Reimar Döffinger wrote:
> > The thing I am unsure about though is which byte is the unused one and
> > should be skipped, the first or the last - for the black-and-white
> > cursors I tested it doesn't make a difference...
> 
> You could skip the one that is always zero.  If none is, then one of the 
> bytes is the alpha and you should either skip no byte, or set src _just 
> to that_ byte.

There is no alpha, there is already a mask that defines transparency,
the 4th byte is only padding and should be ignored, just like for the
framebuffer (where that issue even made it into the FAQ since some
library incorrectly treated that as alpha which gave strange effects).
Well, at least that's how I am convinced it should be, I have not yet
found a specification or even proper documentation for this stuff (I
admit I haven't looked too hard).