Re: [Qemu-devel] [PATCH 1/1] Sun4m : TCX framebuffer hardware acceleration

[Olivier Danet <odanet@caramail.com>]

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