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

[Olivier Danet]

On 25/05/2014 22:28, Mark Cave-Ayland wrote:
> On 25/05/14 14:20, Olivier Danet wrote:
> 
>> Here is the original patch, I have changed email settings since then, it 
>> should work better.
>> Alas, I have not merged latest QEMU changes (your CG3/TCX patches), so it 
>> will probably not compile as-is...
> 
> Thanks for this - don't worry about my latest patches for the moment as they 
> are still awaiting review. As it was, I still had to modify the patch by hand 
> to get it to apply to master, I think because of the extra parameter added to 
> graphic_console_init().
> 
> Once applied, I tested the patch with NetBSD 6.1.3 which is what I had lying 
> around in my test suite, along with your binary QEMU,tcx.bin ROM.
> 
> First impressions are good in that your work fixes the missing white 
> background on NetBSD boot. I did notice a problem with the text colour though 
> in that the main console text in that it appears green until the welcome 
> banner appears, at which point it correctly changes to black. I wonder if 
> this is the same problem with the DAC programming I had on the cg3 where you 
> can have byte accesses to the DAC registers, and not just 32-bit accesses? 
> Have a look at the cg3 source for more information.

[snip]

> I think in summary that while the patch appears to work well (indeed it 
> managed to boot into my Solaris 8 installer with TCX in both 8 and 24 bit 
> modes!), the colour problem in NetBSD may need some further investigation and 
> the patch needs to be broken down into more manageable chunks and rebased on 
> master.
> 
> As a starting point I would suggest a breakdown like this:
> 
> 1) Reorganisation of memory region dirty handling
> 2) Tidy-ups/comments (please avoid unnecessary whitespace changes!)
> 3) Cursor functionality
> 4) Remaining hardware registers
> 
> Before resubmitting, please also run the patchset through 
> scripts/checkpatch.pl which should catch most of the changes that don't match 
> the QEMU coding style.
> 
> 
> ATB,
> 
> Mark.
> 
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