qemu-devel
[Top][All Lists]
Advanced

[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




reply via email to

[Prev in Thread] Current Thread [Next in Thread]