[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Qemu-devel] [PATCH 1/1] Sun4m : TCX framebuffer hardware accelerati
Re: [Qemu-devel] [PATCH 1/1] Sun4m : TCX framebuffer hardware acceleration
Thu, 29 May 2014 21:48:22 +0200
Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.5.0
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
> 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.
> 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
> 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.
- 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
The S24/TCX has a 1Meg * 26 bits framebuffer.
For each pixel, two bits are used for selecting between 256 indexed and 24bits
The RAMDAC/palette handles this selection, as well as an overlay plane for the
(with 4 additional colours).
This enable handling different "visuals" for each X11 window. Text mode is also
even on 24bits mode.
The memory is simultaneously accessible at several addresses, with different
RDFB32: Each pixel occupies 32bits. D[31:26]=0000_00, D[25:24]=MODE,
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])
01 : 16M colours "directcolor" : R=pal_r(D[ 7: 0]) G=pal_g(D[15:8])
10 : 16M colours "truecolor" gamma : R=gamma(D[ 7: 0]) G=gamma(D[15:8])
11 : 16M colours "truecolor" raw : R= D[ 7: 0] G= D[15:8]
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
- As the 24bits mode is simultaneously both a 8bits and 24bits mode, dirtying
the (smaller) 8bits area