From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:41828) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1X65e1-0005hM-H9 for qemu-devel@nongnu.org; Sat, 12 Jul 2014 18:19:54 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1X65dw-0002j4-3D for qemu-devel@nongnu.org; Sat, 12 Jul 2014 18:19:49 -0400 Received: from mout.gmx.net ([212.227.15.15]:60996) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1X65dv-0002gw-PO for qemu-devel@nongnu.org; Sat, 12 Jul 2014 18:19:44 -0400 Message-ID: <53C1B566.1000606@caramail.com> Date: Sun, 13 Jul 2014 00:23:34 +0200 From: Olivier Danet MIME-Version: 1.0 References: <5301468E.2020509@caramail.com> <5381BCE8.5030503@ilande.co.uk> <5381EE20.9000907@caramail.com> <5382526C.3070509@ilande.co.uk> <53878F06.5030902@caramail.com> <53BC8156.6080907@ilande.co.uk> In-Reply-To: <53BC8156.6080907@ilande.co.uk> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] [PATCH 1/1] Sun4m : TCX framebuffer hardware acceleration List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Mark Cave-Ayland , qemu-devel , Blue Swirl , Artyom Tarasenko On 09/07/2014 01:40, Mark Cave-Ayland wrote: > On 29/05/14 20:48, Olivier Danet wrote: > >> Hello Mark >> >> - Don't you like green ? >> It looks fine for me : http://temlib.org/pub/boot_netbsd6.jpg >> >> - "checkpatch.pl" did not find anything wrong with this patch. I will adjust style and spacings anyway. >> >> - AFAIU, it is impossible to implement exactly this video board on QEMU with reasonable performance. >> >> The S24/TCX has a 1Meg * 26 bits framebuffer. >> >> For each pixel, two bits are used for selecting between 256 indexed and 24bits truecolor. >> The RAMDAC/palette handles this selection, as well as an overlay plane for the cursor >> (with 4 additional colours). >> This enable handling different "visuals" for each X11 window. Text mode is also 8bits indexed >> even on 24bits mode. >> >> The memory is simultaneously accessible at several addresses, with different alignment : >> >> RDFB32: Each pixel occupies 32bits. D[31:26]=0000_00, D[25:24]=MODE, D[23:0]=Colour >> DFB24 : Each pixel occupies 32bits. D[31:24]=0000_0000, D[23:0]=Colour >> DFB8 : Each pixel occupies 8bits, mapped to D[7:0] of the framebuffer. >> >> MODE=D[25:24] (-> datasheet ATT20C567) >> 00 : 256 colours "pseudocolor" : R=pal_r(D[ 7: 0]) G=pal_g(D[ 7:0]) B=pal_b(D[ 7:0]) >> 01 : 16M colours "directcolor" : R=pal_r(D[ 7: 0]) G=pal_g(D[15:8]) B=pal_b(D[23:16]) >> 10 : 16M colours "truecolor" gamma : R=gamma(D[ 7: 0]) G=gamma(D[15:8]) B=gamma(D[23:16]) >> 11 : 16M colours "truecolor" raw : R= D[ 7: 0] G= D[15:8] B= D[23:16] >> >> QEMU cannot directly imitate this behavior, so : >> - The RDFB32 area is only used for the MODE bits >> - 8 colours applications are expected to write only in the DFB8 area >> - 24 colours applications are expected to write only in the DFB24 area >> - the blitter and stippler accelerators update all areas simultaneously in 24bits mode >> - As the 24bits mode is simultaneously both a 8bits and 24bits mode, dirtying the (smaller) 8bits area >> is sufficient. >> >> Olivier > > Hi Olivier, > > So sorry for the delay on this - I just realised replying to another email earlier today that I'd totally forgotten about this one :/ > > Please find attached what I believe is your patch rebased onto git master, which when applied to my local repository (and using your binary QEMU,tcx.bin from http://temlib.org/pub/QEMU,tcx.bin) gives me the green text when booting NetBSD 6.1.3 as can be seen at http://www.ilande.co.uk/tmp/netbsd.png. > > Can you double-check and make sure that I haven't accidentally broken anything during the rebase? It required quite a bit of work to fix up by hand. > > > ATB, > > Mark. > Thank you Mark for updating this patch. I found no regression, acceleration seems to work both in 8bits and 24bits modes for NetBSD and Solaris. As [barely] visible in this photo, text should be green until the "root file system type: ffs" sentence is displayed : http://temlib.org/pub/boot_netbsd6.jpg The modified OpenBIOS QEMU,tcx.bin file is necessary because of several quirks : - Change a few addresses to match actual hardware. - Remove the "address" property from TCX, because of some almost-bug in NetBSD when detecting framebuffers. (actual TCX has no address property, so it works by chance on real hardware) - Add the hardware cursor properties (see http://temlib.org/pub/openbios_tcx.diff) The hardware cursor is the only part that should concern Linux (which uses Xorg drivers). Regards Olivier