[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Qemu-devel] [PATCH 1/1] Sun4m : TCX framebuffer hardware accelerati
From: |
Olivier Danet |
Subject: |
Re: [Qemu-devel] [PATCH 1/1] Sun4m : TCX framebuffer hardware acceleration |
Date: |
Sun, 13 Jul 2014 00:23:34 +0200 |
User-agent: |
Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 |
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