ATI Framebuffer development

[erudified]

Why the funny face slice? You know where I can get a debugging build of xnu 9.3/4 with the TSC sync patch?

 

Dong, are you getting an actual kernel panic, or is it booting to a garbled resolution? In the trunk now, I uncommented your cscSwitchMode routine in RadeonHD.cpp so that's why it's giving a garbled resolution. It's not panicking for me. Is this what you meant? Do you have a 0x71451002 card?

[dong]

Hm, dong. As a programmer you must be more specific. At what place the KP is occured?

May be here?

	IOFree(atomDataPtr, strlen(atomDataPtr));

while

	if (!(atomDataPtr = IOMalloc(sizeof(atomDataTables)))) {

IOFree and IOMalloc must have the same size.

Frankly say, I don't know how to do KP debug. Could you explain some detail how to do it on Hackingtosh? What I read from apple website tells a debug flag or something that only exist on apple's Mac need to be set.

Yes, I noticed the IOFree warning too, and I corrected most of them already. The only one left is "IOFree(handle->ScratchBase, strlen(handle->ScratchBase))", its size is not saved anywhere. And I guess we can't add variable to the handle structure for this purpose since the structure is used in ROM's ATOMBIOS function.

 

Erudified, I'm using the old tar file you posted here. The KP screen is displayed. And yes my card is 71451002.

[erudified]

Hey Dong, as far as kernel debugging is concerned I believe we need to have a kernel built with debugging symbols in order to get a nice backtrace. I'm working on getting one built but it's kind of a pain, I'm missing a bunch of little apps that the xnu build process requires. Nothing insurmountable.

 

What do you think about making an IOPCIDevice subclass containing all of the AtomBIOS specific functions? I've started working on this a bit, but I don't have enough in it to feel committed. Do you feel it's the best way to go? Also, do you have any instant messenger accounts or anything? I'm 'erudified' on yahoo and 'evl alex' on AIM, so drop me a line on there sometime if you'd like to chat in realtime.

 

Slice, do you know anything about kernel debugging? I'm pretty much in the dark as far as this goes, so any insight would be really appreciated.

[dong]

I did not see any IOPCIDevice as well as AtomBIOS code in Carreta yet. What make you think IOPCIDevice the best place to put AtomBIOS? If for PCIConfigRead/Write, there should be a work around to solve it. Or maybe you want to do some inject thing there?

By the way, PoolAllocateResident/PoolDeallocate are used in Carreta just like malloc/free in linux. Maybe we can use them too for convenience.

[erudified]

I just thought that keeping the AtomBIOS code as close to IOPCIDevice as possible (at a lower layer than IONDRVDevice) would be the cleanest way to implement it. We could test it independently of the IONDRVDevice and IOFramebuffer implementation to make sure that things were working properly (i.e., write a little userspace app to tweak registers and check the card's state, very similar to your RadeonPCI kext). Also, (I think) this would mean that we could come up with a good API to share with Slice and reuse a lot more code in our IONDRVDevice implementations.

 

What do you think? I'm open to any suggestions, like I said I've just gotten the very basics of this done and I don't have any trouble with scrapping it.

 

I'll look into those functions also, I hadn't heard of them before!

[Slice]

Hey Dong, as far as kernel debugging is concerned I believe we need to have a kernel built with debugging symbols in order to get a nice backtrace. I'm working on getting one built but it's kind of a pain, I'm missing a bunch of little apps that the xnu build process requires. Nothing insurmountable.

You need kernel-tools.

http://kernel.macosforge.org/

But I know only one man that able to make kernel for HackOS. What about you?

What do you think about making an IOPCIDevice subclass containing all of the AtomBIOS specific functions? I've started working on this a bit, but I don't have enough in it to feel committed. Do you feel it's the best way to go?

No. RadeonPCI/RadeonDump have good access for both ATOMBIOS and LegacyBIOS.

Moreover. If you make subclass of IOPCIDevice it may influence on other PCI devices, for example ATA controller.

I look into your sources (original structure by Dong?). You have no IONDRVDevice! See the difference with my codes. And with my info.plist.

Make a report

ioreg -l -x -w 2048 >ioreg.txt

In the file you can see all your class/device structures

Slice, do you know anything about kernel debugging? I'm pretty much in the dark as far as this goes, so any insight would be really appreciated.

It's a pity no idea.

I also need to debug and I try gdb. It is only for applications. Not for kexts and not for such application as RadeonDump.

Best tools for me:

RadeonDump. Thanks again, Dong!

IOLog() inside sources - you may know where KP is occur if you insert more IOLog.

HT disassembler(debugger?No) - http://hte.sf.net

OTX disassembler - http://otx.darwinports.com/

XCode internal possibilities.

If I see KP I also see addresses where it is.

I open the kext by HT and found the address. Then I find the code in my sources. XCode may help you.

[erudified]

Yeah, I have the kernel-tools package, it doesn't have all of the required stuff though. Apparently I need to grab some solaris headers to build ctfconvert (a dtrace tool) and I have to edit the makefile in a few places. Nothing major. I think he's the only dude to build a hackintosh kernel because no one else has bothered ;P I'll get a debugging kernel built and post it, then we'll get a nice backtrace in /Library/Logs/panic.log

 

What do you think the best way to structure this will be? No direct IOPCIDevice subclass, just IONDRVDevice -> IONDRVFramebuffer -> IODisplay ?

[Slice]

Yeah, I have the kernel-tools package, it doesn't have all of the required stuff though. Apparently I need to grab some solaris headers to build ctfconvert (a dtrace tool) and I have to edit the makefile in a few places. Nothing major. I think he's the only dude to build a hackintosh kernel because no one else has bothered ;P I'll get a debugging kernel built and post it, then we'll get a nice backtrace in /Library/Logs/panic.log

It would be nice. But to create Hack kernel you need to correct sources. Hack kernel differ from XNU kernel.

What do you think the best way to structure this will be? No direct IOPCIDevice subclass, just IONDRVDevice -> IONDRVFramebuffer -> IODisplay ?

Yes, I think we need IONDRVDevice especially if we want to have two monitors.

one PCIDevice - one framebuffer, but

one PCIDevice -> two NDRVDevice -> two framebuffer.

And look my xbench results

http://forum.insanelymac.com/index.php?sho...6664&st=178

I think it is because of IONDRVDevice is present.

 

To have IONDRVDevice you need to make IONameMatch but not IOPCIMatch so you need natit-like injector.

[Slice]

Lets speak about variable fAddress.

RadeonHD project

		if (!getUInt32Property(regEntry, "address", (UInt32 *) &inst->fAddress))
		continue;

and here

		case cscGetCurMode:
		{
			VDSwitchInfoRec * switchInfo = (VDSwitchInfoRec *) params;

			//switchInfo->csData	 = kIOBootNDRVDisplayMode;
			switchInfo->csData	 = fMode;
			switchInfo->csMode	 = kDepthMode1;
			switchInfo->csPage	 = 1;
			switchInfo->csBaseAddr = (Ptr) (1 | (UInt32) fAddress);
			ret = kIOReturnSuccess;
		}
		break;

How it works?

Did you try to inject this value?

 

I did! It is ATILead.info.plist

				<key>@0,address</key>
			<integer>0xd0010000</integer>

while my IODeviceMemory = 0xd0000000.

And I got the shift on the screen. Look part of boot screen on the top of my screen.

It means screen address=0xd0000000

desktop address=0xd0010000.

Someone is not success with my ATILead. Yes, he has another screen address!

So I think we need to write in property not "address" but "fboffset" and then calculate

fAddress = fboffset + inst->FBMap->getPhysicalAddress()

but then set screen to the same address

OUTREG(DISPLAY_BASE_ADDRESS, fAddress);

 

Why I need the shift?

I have strange calculation about RingBuffer that is badly overlap with FrameBuffer.

 

EDITED:

I found ioreg from PowerMac3,4 with Radeon9000

	| |	 | |   "AAPL,vram-memory" = <9c00000004000000>
| |	 | |   "depth" = <00000020>
| |	 | |   "display-type" = <"CRT">
| |	 | |   "linebytes" = <00001200>
| |	 | |   "driver,AAPL,MacOS,PowerPC" = 
| |	 | |   "height" = <00000360>
| |	 | |   "device_type" = <"display">
| |	 | |   "width" = <00000480>
| |	 | |   "address" = <9c008000>

The offset is present!

[dong]

I'm not very clear of the framebuffer, ringbuffer, and screen address thing. In RadeonHD, I saw "ScanOutStart", "ScanOutSize", "FreeStart", "FreeSize". What will be their relationship?

[Gord]

http://forum.insanelymac.com/index.php?sho...mp;#entry860375

 

This is a link to a post and a kext that I just tried. Works, albeit with lots of tearing.

 

Hope it helps, or gives some clue as to what is going on.

 

 

Cheers,

Gord.

[dong]

Gord, the kext in the link was originally posted by me in a x1300/x1400 topic and it's the same as the one I posted here. Funny thing I can not see how it works for your resolution.

[Gord]

Gord, the kext in the link was originally posted by me in a x1300/x1400 topic and it's the same as the one I posted here. Funny thing I can not see how it works for your resolution.

 

Any command line stuff I can do that would output something you could decipher?

[dong]

Maybe the output of "dmesg" and "ioreg -l -w 1024" would give me some information.

Please post them as files.

[Slice]

I'm not very clear of the framebuffer, ringbuffer, and screen address thing. In RadeonHD, I saw "ScanOutStart", "ScanOutSize", "FreeStart", "FreeSize". What will be their relationship?

If you have screen 1440x1050x32 it occupy ~6Mb. All other Video memory is free. So

	unsigned int		FbFreeStart;
unsigned int		FbFreeSize;

/* visible part of the framebuffer */
unsigned int		FbScanoutStart;
unsigned int		FbScanoutSize;
...
rhdPtr->FbScanoutStart = rhdPtr->FbFreeStart;
rhdPtr->FbScanoutSize = RHD_FB_CHUNK(pScrn->displayWidth * pScrn->bitsPerPixel *
				 pScrn->virtualY / 8);
IOLog("ScanoutBuffer at offset 0x%08X (size = 0x%08X)\n",
	 rhdPtr->FbScanoutStart, rhdPtr->FbScanoutSize);

rhdPtr->FbFreeStart = rhdPtr->FbScanoutStart + rhdPtr->FbScanoutSize;
rhdPtr->FbFreeSize -= rhdPtr->FbScanoutSize;
....

But I encounter on

   unsigned long fb_offset;
  unsigned long mmio_offset;
  unsigned long ring_offset;
  unsigned long ring_rptr_offset;
  unsigned long buffers_offset;
  unsigned long gart_textures_offset;
} drmRadeonInit;

And I know that @700 calculated inside ATIRadeon8500/9700/X1000.

RB means RingBuffer.

#define CP_RB_CNTL							 0x0704  
#define CP_RB_BASE							 0x0700  
#define CP_RB_RPTR_ADDR						0x070C  
#define CP_RB_RPTR							 0x0710  
#define CP_RB_WPTR							 0x0714  
#define CP_RB_WPTR_DELAY					   0x0718

But not in Linux while variables are present.

 

2 Gord

Make digital photo as I did!

[Gord]

Ok here are my screen shots and dump files:

 

Anything else that might be handy?

 

 

Cheers,

Gord.

dmesg.txt

ioreg.txt

[Gord]

FYI:

 

I have tested some resolution things to verify that I actually have the display indicated.

 

If I take a screenshot of the entire desktop, the resolution of that picture is 1400x1050

 

If I take a finder window and drag the corners to fill the screen, except the menu bar the application capture resolution is 1480x1108

 

Kinda strange, I think that there is some display discrepancy here and that I don't really have 1680x1050, even though everything reports it as such. Perhaps it is the internal driver scaling it to 1400x1050?

 

Cheers,

Gord.

[dong]

Just a quick reply.

Since you have a T60, it's possible that RadeonHD detect the 1680x1050 mode and set it as the virtual width and virtual height. The scanout and scansize are set accordingly. Thus although IONDRVSupport only provide a 1400x1050 mode, somehow the full 1680x1050 framebuffer is used and get displayed. Details remains unknown yet. I will look at the files you provide later.

[Slice]

I just want to repeat for those for didn't understand my previous posts

Expected result if you don't use Radeon registers

Namely you need a procedure like that

/*
* Apply a video mode. This will apply the whole register set, including
* the PLL registers, to the card
*/
static void radeon_write_mode (struct radeonfb_info *rinfo,
                              struct radeon_regs *mode, int regs_only)
{
int i;
int primary_mon = PRIMARY_MONITOR(rinfo); //MT_CRT

/*if (nomodeset)
	return;*/

if (!regs_only)
	radeon_screen_blank(rinfo, FB_BLANK_NORMAL, 0);

radeon_fifo_wait(31);
for (i=0; i<10; i++)
	OUTREG(common_regs[i].reg, common_regs[i].val);

/* Apply surface registers */
for (i=0; i<8; i++) {
	OUTREG(SURFACE0_LOWER_BOUND + 0x10*i, mode->surf_lower_bound[i]);
	OUTREG(SURFACE0_UPPER_BOUND + 0x10*i, mode->surf_upper_bound[i]);
	OUTREG(SURFACE0_INFO + 0x10*i, mode->surf_info[i]);
}

OUTREG(CRTC_GEN_CNTL, mode->crtc_gen_cntl);
OUTREGP(CRTC_EXT_CNTL, mode->crtc_ext_cntl,
	~(CRTC_HSYNC_DIS | CRTC_VSYNC_DIS | CRTC_DISPLAY_DIS));
OUTREG(CRTC_MORE_CNTL, mode->crtc_more_cntl);
OUTREGP(DAC_CNTL, mode->dac_cntl, DAC_RANGE_CNTL | DAC_BLANKING);
OUTREG(CRTC_H_TOTAL_DISP, mode->crtc_h_total_disp);
OUTREG(CRTC_H_SYNC_STRT_WID, mode->crtc_h_sync_strt_wid);
OUTREG(CRTC_V_TOTAL_DISP, mode->crtc_v_total_disp);
OUTREG(CRTC_V_SYNC_STRT_WID, mode->crtc_v_sync_strt_wid);
OUTREG(CRTC_OFFSET, 0);
OUTREG(CRTC_OFFSET_CNTL, 0);
OUTREG(CRTC_PITCH, mode->crtc_pitch);
OUTREG(SURFACE_CNTL, mode->surface_cntl);

radeon_write_pll_regs(rinfo, mode);

if ((primary_mon == MT_DFP) || (primary_mon == MT_LCD)) {
	radeon_fifo_wait(10);
	OUTREG(FP_CRTC_H_TOTAL_DISP, mode->fp_crtc_h_total_disp);
	OUTREG(FP_CRTC_V_TOTAL_DISP, mode->fp_crtc_v_total_disp);
	OUTREG(FP_H_SYNC_STRT_WID, mode->fp_h_sync_strt_wid);
	OUTREG(FP_V_SYNC_STRT_WID, mode->fp_v_sync_strt_wid);
	OUTREG(FP_HORZ_STRETCH, mode->fp_horz_stretch);
	OUTREG(FP_VERT_STRETCH, mode->fp_vert_stretch);
	OUTREG(FP_GEN_CNTL, mode->fp_gen_cntl);
	OUTREG(TMDS_CRC, mode->tmds_crc);
	OUTREG(TMDS_TRANSMITTER_CNTL, mode->tmds_transmitter_cntl);
}

if (!regs_only)
	radeon_screen_blank(rinfo, FB_BLANK_UNBLANK, 0);

radeon_fifo_wait(2);
OUTPLL(VCLK_ECP_CNTL, mode->vclk_ecp_cntl);

return;
}

[Slice]

Some useful investigations for R500 (ATIRadeonX1000).

If I know that for R300 switch mode performed by

#define RADEON_CRTC_OFFSET 0x0224

#define RADEON_CRTC_PITCH 0x022c

#define RADEON_CRTC_H_TOTAL_DISP 0x0200

#define RADEON_CRTC_V_TOTAL_DISP 0x0208

 

and so on

then I found in ATIRadeon9700

loc_160EB:		; CODE XREF: __ZN13ATIRadeon970025set_display_mode_and_vramEv+64Ej
		; __ZN13ATIRadeon970025set_display_mode_and_vramEv+6ABj
	mov	ebx, [esi+854h]  //MMIO access
	mov	edi, [ebx+224h]
	and	edi, 0FFFFFFFh
	mov	eax, [ebx+22Ch]
	and	eax, 7FFh
	shl	eax, 3
	mov	[ebp+var_60], eax
	mov	eax, [ebx+200h]
	mov	edx, [ebx+208h]

Then I found the same place in ATIRadeonX1000

loc_167B2:		; CODE XREF: __ZN14ATIRadeonX100025set_display_mode_and_vramEv+3ECj
		; __ZN14ATIRadeonX100025set_display_mode_and_vramEv+449j
	mov	edx, [esi+880h]	//MMIO access
	mov	eax, [edx+6110h] 
	cmp	eax, [esi+0B74h]
	jz	short loc_167DE
	mov	eax, [edx+6110h]
	mov	[esi+0B10h], eax
	mov	eax, [edx+6120h]
	mov	[esi+0B14h], eax

and look for definitions in rhd_regs.h

	/* D1GRPH registers */
D1GRPH_ENABLE				  = 0x6100,
D1GRPH_CONTROL				 = 0x6104,
D1GRPH_LUT_SEL				 = 0x6108,
D1GRPH_SWAP_CNTL			   = 0x610C,
D1GRPH_PRIMARY_SURFACE_ADDRESS = 0x6110,
D1GRPH_PITCH				   = 0x6120,
D1GRPH_SURFACE_OFFSET_X		= 0x6124,
D1GRPH_SURFACE_OFFSET_Y		= 0x6128,
D1GRPH_X_START				 = 0x612C,
D1GRPH_Y_START				 = 0x6130,
D1GRPH_X_END				   = 0x6134,
D1GRPH_Y_END				   = 0x6138,
D1GRPH_UPDATE				  = 0x6144,

 

But a problem

		mov	ecx, [esi+880h]
	mov	ebx, [ecx+16C4h]

I have no definition for 0x16c4 register neither in Linux sources nor in ATI documents.

 

your set_mode is here rhd_crtc.c

/*
*
*/
static void
DxFBSet(struct rhdCrtc *Crtc, CARD16 Pitch, CARD16 Width, CARD16 Height,
int bpp, CARD32 Offset)
{
...
/* R5xx - RS690 case is GRPH_CONTROL bit 16 */

RHDRegWrite(Crtc, RegOff + D1GRPH_PRIMARY_SURFACE_ADDRESS,
	rhdPtr->FbIntAddress + Offset);
RHDRegWrite(Crtc, RegOff + D1GRPH_PITCH, Pitch);
RHDRegWrite(Crtc, RegOff + D1GRPH_SURFACE_OFFSET_X, 0);
RHDRegWrite(Crtc, RegOff + D1GRPH_SURFACE_OFFSET_Y, 0);

 

Strange question:

Why set_display_mode performed by accelerator while we expect it in ATINDRV?

Or there is some connection through GA.plugin?

[dong]

RadeonHD was initially a framebuffer driver without acceleration. So all modesetting procedures including PLL register writing are already there. If I am not getting it wrong, the asm code you posted here are all reading register values instead of writing, is it a function to save mode and vram properties to variable values in some structure like DriverGlobal in ATINDRV?

 

Gord, I checked the files. RadeonHD only detected the 1680x1050 resolution from BIOS. From the source, I can see the driver will only provide this resolution when osx inquiry on available resolutions, however will provide old "1400x1050" when osx inquiry current resolution if it's the boot resolution.

I'd like to know how does your mouse cursor look like? Does it come with an artifact white line all the time or not? And how is the desktop looking like?

[Slice]

It is my oversight. ATINDRV.kext contains not only ATY_Caretta but also ATINDRV that is works too.

Here is register writings.

		add	ax, 6110h
	movzx	edx, ax
	mov	eax, [ebp+var_2C]
	mov	[esp+0C8h+var_C0], eax
	mov	[esp+0C8h+var_C4], edx
	mov	eax, [ebp+arg_0]
	mov	[esp+0C8h+var_C8], eax
	call	_regw32

New asm file for you.

ATINDRV.asm.zip

[Gord]

The cursor is a little messed, and the screen is ok so long as I don't move the mouse. When I do move it I get horizontal garbage all across the display that coincides with the mouse movement. At first I thought it was screen tearing, but it isn't, I have mouse locator installed and it is cleaning up a small area around the cursor.

 

Gord.

 

RadeonHD was initially a framebuffer driver without acceleration. So all modesetting procedures including PLL register writing are already there. If I am not getting it wrong, the asm code you posted here are all reading register values instead of writing, is it a function to save mode and vram properties to variable values in some structure like DriverGlobal in ATINDRV?

 

Gord, I checked the files. RadeonHD only detected the 1680x1050 resolution from BIOS. From the source, I can see the driver will only provide this resolution when osx inquiry on available resolutions, however will provide old "1400x1050" when osx inquiry current resolution if it's the boot resolution.

I'd like to know how does your mouse cursor look like? Does it come with an artifact white line all the time or not? And how is the desktop looking like?

[dong]

The cursor is a little messed, and the screen is ok so long as I don't move the mouse. When I do move it I get horizontal garbage all across the display that coincides with the mouse movement. At first I thought it was screen tearing, but it isn't, I have mouse locator installed and it is cleaning up a small area around the cursor.

 

Gord.

This make sense to me. So part of OSX think it as 1680x1050, and part think it as 1400x1050. The two resolutions have different pitch values: 1728 vs. 1408. Obviously the mouse cousor background are updated with a pitch value different from the background desktop.

Presently I have no good suggestion for you. Hopefully further investigation of the driver will give a solution to all.

 

Slice, the ATINDRV code has been combined into Carreta or wommy in 10.5, that means no more ATINDRV executable in the kext. I'm actually now reverse engineering the latest Carreta which contains all framebuffer procedures.

[Slice]

Slice, the ATINDRV code has been combined into Carreta or wommy in 10.5, that means no more ATINDRV executable in the kext. I'm actually now reverse engineering the latest Carreta which contains all framebuffer procedures.

Did you prepare your own asm file? Great!

I am looking into AppleNDRV/{ATI ROM Xtender, ATIDriver.bundle, ATIRuntimeDriver.bundle}

Yes, it is PowerPC analog of ATINDRV for low-end Radeon. I can understand PowerPC Codes but Machonist doesn't work with these files and HexEdit prepare bad output. It is not a reliable way.

Continue creating driver from existing sources

ATIFB: fb_phys_base=d0000000 fb_local_base=38000000
ATI: Found Intel x86 BIOS ROM Image
ATIFB: Legacy BIOS detected:
Found ATI 5835 named ATI MOBILITY RADEON 9000 IGP
ATIFB: Bios Connector table: 
ATIFB: Port0: DDCType-0x60, DACType-2, TMDSType-1, ConnectorType-1
ATIFB: Port4: DDCType-0x0, DACType-0, TMDSType-0, ConnectorType-7
ATIFB: Port5: DDCType-0x0, DACType-2, TMDSType-0, ConnectorType-5
ATIFB: Retreived PLL infos from BIOS
ATIFB: Reference=14.32 MHz (RefDiv=6) Memory=300.00 Mhz, System=165.00 MHz
ATIFB: PLL min 20000 max 35000
ATIFB: radeon_get_moninfo: bios 4 scratch = 1000004
ATIFB: biosEDID @0000
ATIFB: LCD,EDID injected
ATIFB: radeon_check_modes
ATIFB: Panel ID string: 1024x768                
ATIFB: Panel Size from BIOS: 1024x768
ATIFB: BIOS provided dividers will be used.
ATIFB: LVDS Info:
XRes: 1024, YRes: 768, DotClock: 65000
HBlank: 320, HOverPlus: 16, HSyncWidth: 136
VBlank: 38, VOverPlus: 2, VSyncWidth: 6
ATIFB: Setting up default mode based on panel info
fb_edid_to_monspecs
edid_checksum OK
edid_check_header OK
========================================
Display Information (EDID)
========================================
  EDID Version 1.3
  Manufacturer: @@@
  Model: 00000000
  Serial#: 00000000
  Year: 1990 Week 0
  Display Characteristics:
     Monitor Operating Limits:    Detailed Timings
     65 MHz 1024 1040 1176 1344 768 768 768 806 -HSync -VSync

  Supported VESA Modes
     640x480@60Hz
     800x600@60Hz
     1024x768@60Hz
     Manufacturer's mask: 0
  Standard Timings
     640x480@60Hz
     800x600@60Hz
     1024x768@60Hz
  Detailed Timings
Extrapolated
          H: 30-48KHz V: 60-60Hz DCLK: 65MHz
     Analog Display Input: Input Voltage - 0.700V/0.300V
     Sync: Serration on 
     Max H-size in cm: 40
     Max V-size in cm: 30
     Gamma: 1.0
     DPMS: Active yes, Suspend yes, Standby yes
     Non-RGB Multicolor Display
     Chroma
        RedX:     0.000 RedY:     0.000
        GreenX:   0.000 GreenY:   0.000
        BlueX:    0.000 BlueY:    0.000
        WhiteX:   0.000 WhiteY:   0.000
     First DETAILED Timing is preferred
  Detailed Timings
     65 MHz 1024 1040 1176 1344 768 768 768 806 -HSync -VSync

  Supported VESA Modes
     640x480@60Hz
     800x600@60Hz
     1024x768@60Hz
     Manufacturer's mask: 0
  Standard Timings
     640x480@60Hz
     800x600@60Hz
     1024x768@60Hz
  Detailed Timings
  modes from EDID extracted
========================================
ATIFB: found 8 modes
ATIFB: Mode 1024x768 added 
ATIFB: Mode 640x480 added 
ATIFB: Mode 640x480 added 
ATIFB: Mode 800x600 added 
ATIFB: Mode 1024x768 added 

Then freeze without KP.