ATI Framebuffer development

[dong]

I found new developer for the project

http://forum.insanelymac.com/index.php?sho...p;hl=MobilityFB

The author, erudified, has several posts here already. He has the same goal as me.

I notice some strange problem in porting Linux sources to MacOSX.

in Linux DisplayModeRec doesn't contain BitsPerPixel. It is property of ScreenInfo. So we can't switch modes with different bpp on the same screen?

What to do? Use always 32?

I did not test linux driver on my machine, don't know if switchMode and change bpp are separated or combined together. But it looks like it's separated. Both Callisto and Caretta codes have support for bpp switching. I noticed there is a "ATIMapFramebuffer" based on new resolution and new bpp after switch resolution in Caretta code. But this step is not seen in linux code.

In MacOS I see member

IOIndex IONDRVFramebuffer::mapDepthIndex(

IODisplayModeID modeID, IOIndex depth, bool fromDepthMode )

What is it?

I'm not very clear of this too. From the documents, it just said the depth has the same accend sequence as bpp, but the exact relationship may should be decided by each graphics driver itself.

 

By the way, only the pkg3 of xfree86 is useful for us.

[Slice]

The author, erudified, has several posts here already. He has the same goal as me.

O, sorry, I forget

I did not test linux driver on my machine, don't know if switchMode and change bpp are separated or combined together. But it looks like it's separated. Both Callisto and Caretta codes have support for bpp switching. I noticed there is a "ATIMapFramebuffer" based on new resolution and new bpp after switch resolution in Caretta code. But this step is not seen in linux code.

May be it is your problem of incorrect screen? See post 232 by dmdimoff

I'm not very clear of this too. From the documents, it just said the depth has the same accend sequence as bpp, but the exact relationship may should be decided by each graphics driver itself.

And we have no example todo. Joblo used only 32bpp.

By the way, only the pkg3 of xfree86 is useful for us.

Thanks. Did you have Apple's xserver codes for comparison?

[dong]

May be it is your problem of incorrect screen? See post 232 by dmdimoff

And we have no example todo. Joblo used only 32bpp.

I'm only testing with 32bpp like Joblo. I think dmdimoff suggestted to use 32bpp too.

Thanks. Did you have Apple's xserver codes for comparison?

No, so you think Apple's xserver is not dependent on ATI driver? I do notice there is a darwin port in xfree86 source.

[Slice]

I'm only testing with 32bpp like Joblo. I think dmdimoff suggestted to use 32bpp too.

I'll be study how bpp is used in linux.

For example I see

#define PIX24TOBPP(p) (((p) == Pix24Use24) ? 24 : \
		(((p) == Pix24Use32) ? 32 : 0))

/* X apps don't like 24bpp images, this code exposes 32bpp images */

/*
* These two functions do a full CopyArea while reformatting
* the data between 24 and 32bpp.  They try to go a bit faster
* by reading/writing aligned CARD32s where it's easy
*/

No, so you think Apple's xserver is not dependent on ATI driver?

Yes, fb*.c sources perform direct writing data to ScreenPtr (VideoMemory) that is driver independent.

I do notice there is a darwin port in xfree86 source.

We can take clear xf86 sources or choose Apple's one X11server-48.1

http://www.opensource.apple.com/darwinsource/10.5.4/

[Slice]

More Linux sources I use, more problems encounter

Linux create output array for one framebuffer. We have different framebuffers for different outputs.

I use one procedure but it calls another one that use new data structures that is created by others procedure that is harmful for me...

I think we can't use clear Linus sources even its would be compilable. But rewrite handreds of procedures !@#$%^&*(()_+~

Suggestions?

[dong]

Haha, seems a serious problem for linux sources. I wonder if it is practical that we reverse engineer the whole ATI native framebuffer driver in OSX and rewrite or subclass it for our purpose. I tried part of Caretta, the major problem will be find out the structure of DriverGlobal*. Others like Wommy will be similar.

OSStatus ATY_Caretta::doDriverIO(unsigned long cmdID, void *contents, ulong cmdCode, ulong cmdKind) {
const char* cmdName[11] = {
	"kIONDRVOpenCommand                "
	"kIONDRVCloseCommand               "
	"kIONDRVReadCommand                "
	"kIONDRVWriteCommand               "
	"kIONDRVControlCommand             "
	"kIONDRVStatusCommand              "
	"kIONDRVKillIOCommand              "
	"kIONDRVInitializeCommand          "
	"kIONDRVFinalizeCommand            "
	"kIONDRVReplaceCommand             "
	"kIONDRVSupersededCommand          "
}
ret = noErr;

 if (cmdCode - 128 <= 10) {
switch (cmdCode) {
	case kIONDRVInitializeCommand:
	case kIONDRVReplaceCommand:
	  properties = OSDynamicCast(OSArray, getProperty("aty_properties"));
	  if (properties != Null) {
		i = 0;
		while (properties->getCapacity() > i) {
			dict = OSDynamicCast(OSDictionary, properties->getObject(i));
			if (dict != Null) {
				obj = OSDynamicCast(OSObject, dict->getObject("value"));
				key = OSDynamicCast(OSString, dict->getObject("key"));
				data = OSDynamicCast(OSData, obj);
				if (data == Null) {
					num = OSDynamicCast(OSNumber, obj);
					if ( num != NULL)
						data = OSData:withBytes(&num->unsigned8BitValue(), 8);
					else {
						str = OSDynamicCast(OSString, obj);
						if (str != NULL)
							data = OSData:withBytes(str->getCStringNoCopy(), str->getLength());
					}
				}
				if (key != NULL && data != NULL) {
					getProvider()->setProperty(key, data);
				}
			}
			i++;
		}
	   }
		ret = IONDRVLibrariesInitialize(getProvider());
		if (ret != noErr) break;
	case kIONDRVFinalizeCommand:
	case kIONDRVSupersededCommand:
		data = OSDynamicCast(OSData, getProperty("AAPL,RegEntryID"));
		if (data == Null) {
			ret = 0xE00002C2;
			break;
		}
		var_44-38 = data->getBytesNoCopy();
		contents = this;
		break;
	default:
		var_2C = contents;
}
   }
if (ret == noErr)
	ret = DoDriverIO(global, 0, cmdID, contents, cmdCode&0x7F, cmdKind);
if (cmdCode == kIONDRVFinalizeCommand) {
	if (global->115B0 != NULL)
		global->115B0->63C[global->crtcI] = NULL;
	PCIRangeMapTableFree();
	IOFree(global, 0x116E0);
	global = NULL;
}
return ret;
}

OSStatus DoDriverIO(DriverGlobal* global, int val, ulong cmdID,
		 void *contents, ulong cmdCode, ulong cmdKind) {
ret = noErr;
if (global != NULL)
	global->8 = val;
if (cmdCode <= 10)
  switch (cmdCode+128) {
	case kIONDRVInitializeCommand:
		return DoInitializeCmd(global, contents);
	case kIONDRVFinalizeCommand:
		return DoFinalizeCmd(global, contents);
	case kIONDRVReplaceCommand:
		return DoReplaceCmd(global, contents);
	case kIONDRVSupersededCommand:
		return DoSuperSededCmd(global, contents);
	case kIONDRVOpenCommand:
		return DoOpenCmd(global, contents);
	case KIONDRVCloseCommand:
		return DoCloseCmd(global, contents);
	case kIONDRVKillIOCommand:
		return DoKillIOCmd(global, contents);
	case kIONDRVReadCommand:
		ret = DoReadCmd(global, contents);
	case kIONDRVWriteCommand:
		ret = DoWriteCmd(global, contents);
	case kIONDRVControlCommand:
		ret = DoControlCmd(global, contents);
	case kIONDRVStatusCommand:
		ret = DoStatusCmd(global, contents);
	default:
  }
if (cmdKind bit2 == 0)
	ret = IOCommandIsComplete(cmdID, ret);
return ret;
}

[Slice]

Great work!

Haha, seems a serious problem for linux sources. I wonder if it is practical that we reverse engineer the whole ATI native framebuffer driver in OSX and rewrite or subclass it for our purpose. I tried part of Caretta, the major problem will be find out the structure of DriverGlobal*. Others like Wommy will be similar.

				ret = 0xE00002C2;
....
	case kIONDRVControlCommand:
		ret = DoControlCmd(global, contents);
	case kIONDRVStatusCommand:
		ret = DoStatusCmd(global, contents);
	default:
  }
if (cmdKind bit2 == 0)
	ret = IOCommandIsComplete(cmdID, ret);
return ret;
}

If you want to know

#define kIOReturnBadArgument	 iokit_common_err(0x2c2) // invalid argument

 

But one problem in this way. The driver uses interrupts to work

		err = CallTVector( /*AddressSpaceID*/ 0, (void *)commandID, contents,
										  (void *)commandCode, (void *)commandKind, /*p6*/ 0,
										  fDoDriverIO );

Did you find switchMode? Till now I have it only with Joblo's sources but they have different structures. So I am thinking what is better: rewrite Joblo's sources or rewrite Linux's sources.

But ATY_Wormy is not for me at all.

 

Yes, you see all ATY_Caretta::functions definitions and can subclass its. But what function you want to rewrite to make the driver working?

 

Your I2C method (from Linux) works. But it is not similar to

//// IOLowLevelDDCSense

void IOFramebuffer::setDDCClock( IOIndex /* connectIndex */, UInt32 /* value */ )
{}

void IOFramebuffer::setDDCData( IOIndex /* connectIndex */, UInt32 /* value */ )
{}

that I want to rewrite to make sure that high-level calls would work. I tried but fails.

[JuzzMann]

Hi all,

 

Great work you guys are doing!! really!

 

I'm a "noob," but i really would like to help you guys out somehow.

 

I have a ati x700(5d52)

 

Im not exactly sure how to help, but if someone tells me what they need from me, i would be glad to be a part of this, and i could easily check back and report to you guys everyday as it is summer vacation here and so i'm not in school at the moment.

 

Feel free to let me know what you need from me.

 

Hope i can help!!

[Slice]

Hi all,

 

Great work you guys are doing!! really!

 

I'm a "noob," but i really would like to help you guys out somehow.

 

I have a ati x700(5d52)

 

Im not exactly sure how to help, but if someone tells me what they need from me, i would be glad to be a part of this, and i could easily check back and report to you guys everyday as it is summer vacation here and so i'm not in school at the moment.

 

Feel free to let me know what you need from me.

 

Hope i can help!!

Dunno if you can help. Read the thread, try different thing we upload here and report what is good or fails. All information may be useful.

[makwanad]

So whatever comes about of all this, will it help in the production of a driver for the radeon xpress series?

Many thanks

Dan

[erudified]

Hey guys, I've got the AtomBIOS parser built and working except for the read and write PCI registers (which should be just drop-in replacements to the IOKit equivs). It's detecting my modeline now!

 

The code is available at http://erudified.com/RadeonHD.tar

 

This site is being flaky, so please contact me at alex@erudified.com -- I'd like to setup a sourceforge project for this so we can have subversion and collaborate a bit better without having to rely on this flaky forum.

 

Reference Clock: i
FUNCTION: RHDLUTsInit
FUNCTION: RHDConnectorsInit
FUNCTION: RHDAtomBiosFunc
FUNCTION: rhdAtomConnectorInfoFromObjectHeader
FUNCTION: rhdAtomConnectorInfoFromSupportedDevices
AtomBIOS Connector[0]: VGA Device: CRT1 Output: 1 HW DDC 0 NO HPD
AtomBIOS Connector[1]: PANEL Device: LCD1 Output: 4 GPIO DDC NO HPD
AtomBIOS Connector[2]: SVIDEO Device: TV1 Output: 2 NO DDC NO HPD
AtomBIOS Connector[3]: DVI-I Device: DFP1 Output: 3 HW DDC 1 HPD 0
AtomBIOS Connector[4]: DVI-I Device: CRT2 Output: 2 HW DDC 1 NO HPD
Connector[0] {RHD_CONNECTOR_VGA, VGA CRT1, RHD_DDC_0, RHD_HPD_NONE, { RHD_OUTPUT_DACA, RHD_OUTPUT_NONE } }
Connector[1] {RHD_CONNECTOR_PANEL, PANEL LCD1, DDC_NONE, RHD_HPD_NONE, { RHD_OUTPUT_LVTMA, RHD_OUTPUT_NONE } }
Connector[2] {RHD_CONNECTOR_TV, SVIDEO TV1, DDC_NONE, RHD_HPD_NONE, { RHD_OUTPUT_DACB, RHD_OUTPUT_NONE } }
Connector[3] {RHD_CONNECTOR_DVI, DVI-I DFP1 CRT2, RHD_DDC_1, RHD_HPD_0, { RHD_OUTPUT_TMDSA, RHD_OUTPUT_DACB } }
Call to AtomBIOS Get Connectors succeeded
FUNCTION: RHDHPDSave
FUNCTION: RHDHPDSet
RHDConnectorsInit: 0 (VGA CRT1) type 1, ddc 0, hpd 0
FUNCTION: RHDI2CFunc
FUNCTION: RHDDACAInit
FUNCTION: RHDOutputAdd
Attaching Output DAC A to Connector VGA 1
RHDConnectorsInit: 1 (PANEL LCD1) type 4, ddc 255, hpd 0
FUNCTION: RHDLVTMAInit
FUNCTION: RHDAtomBiosFunc
FUNCTION: rhdAtomLvdsInfoQuery
LVDS SEQ Dig onto DE: i
FUNCTION: RHDAtomBiosFunc
FUNCTION: rhdAtomLvdsInfoQuery
LVDS SEQ DE to BL: i
FUNCTION: RHDAtomBiosFunc
FUNCTION: rhdAtomLvdsInfoQuery
LVDS Off Delay: i
FUNCTION: RHDAtomBiosFunc
FUNCTION: rhdAtomLvdsInfoQuery
LVDS Duallink: 0x1
FUNCTION: RHDAtomBiosFunc
FUNCTION: rhdAtomLvdsInfoQuery
LVDS 24Bit: 0x0
FUNCTION: RHDAtomBiosFunc
FUNCTION: rhdAtomLvdsInfoQuery
LVDS FPDI: 0x0
FUNCTION: RHDAtomBiosFunc
FUNCTION: rhdAtomLvdsInfoQuery
LVDS Temporal Dither : 0x40
FUNCTION: RHDAtomBiosFunc
FUNCTION: rhdAtomLvdsInfoQuery
LVDS Spatial Dither : 0x20
FUNCTION: RHDAtomBiosFunc
FUNCTION: rhdAtomLvdsInfoQuery
LVDS Grey Level: 0x8
AtomBIOS returned 8 Grey Levels
Detected a 18bit dual link panel.
Printing LVDS paramaters:
MacroControl: 0x0C720407
TXClockPattern: 0x0063
PowerDigToDE: 0x001E
PowerDEToBL: 0x00FA
OffDelay: 0x01F4
PowerRefDiv: 0x0F9F
BlonRefDiv: 0x0000
FUNCTION: RHDOutputAdd
Attaching Output LVDS to Connector PANEL
RHDConnectorsInit: 2 (SVIDEO TV1) type 5, ddc 255, hpd 0
FUNCTION: RHDDACBInit
FUNCTION: RHDOutputAdd
Attaching Output DAC B to Connector TV SVIDEO
RHDConnectorsInit: 3 (DVI-I DFP1 CRT2) type 2, ddc 1, hpd 1
FUNCTION: RHDI2CFunc
FUNCTION: RHDTMDSAInit
FUNCTION: RHDOutputAdd
Attaching Output TMDS A to Connector DVI-I 1
Attaching Output DAC B to Connector DVI-I 1
FUNCTION: RHDHPDRestore
FUNCTION: rhdModeLayoutSelect
FUNCTION: DACASense
DACSense: DAC: 0x00
FUNCTION: DACBSense
DACSense: DAC: 0x00
FUNCTION: RHDHPDCheck
RHDHPDCheck returned: 1 mask: 1
FUNCTION: TMDSASense
TMDSASense: Disconnected
FUNCTION: DACBSense
DACSense: DAC: 0x00
FUNCTION: RHDMonitorInit
FUNCTION: RHDAtomBiosFunc
FUNCTION: rhdAtomLvdsGetTimings
FUNCTION: rhdAtomLvdsTimings
rhdAtomLvdsTimings: LVDS Modeline: 1440x900  96300  1440 (1440) 1504 1536 (1760) 1760  900 (900) 903 906 (912) 912
Call to AtomBIOS Get Panel Mode succeeded
FUNCTION: RHDAtomBiosFunc
FUNCTION: rhdAtomLvdsGetTimings
Query for AtomBIOS Get Panel EDID: failed
rhdMonitorPanel: No panel mode information found.
Unable to attach a monitor to connector "PANEL"
Failed to detect a connected monitor

[dong]

Great job! erudified. I'll test it on my laptop.

I'm still in reverse engineering Caretta. Hope a combination of all efforts will come to a solution.

[erudified]

Hey Dong,

 

I created a sourceforge project at https://sourceforge.net/projects/ioradeonhd/

 

Is this okay with you? Do you have a SourceForge account? I didn't want to stick with the name RadeonHD because, well, it's already taken. IORadeonHD seemed descriptive and simple. If you're not comfortable with this I won't use it, I just thought it'd be good to make what we've got available and get a subversion repo up so we can really collaborate instead of passing around tarballs.

 

This is very close to working, imo. We just need to hack in the IOPCIDevice::configWrite32 / configRead32 etc bits into the AtomBIOS parser and finish up the IONDRVDevice interface (or just skip it and use IOFramebuffer directly). We can actually just use the X windows style merged framebuffer approach initially rather than doing fancy multihead using the device tree. I dunno about you, but I'm mostly wanting native resolution on my panel! =)

 

Also, when using IOFree, do you know if I can do IOFree(handle->BIOSbase, strlen(handle->BIOSbase)) ? Do I need to add +1 to the strlen or should I use sizeof(), I'm not sure. Hahha, kinda giving myself away as a noob programmer here, I'm not very good withC /C++, I'm just winging it

 

P.S. If you have or create a SF.net account I'll transfer ownership of the project to you

[dong]

Well, I don't have any account like you said. Just go ahead what you have done. It's all ok with me.

Actually I am a starter of C++ too, so for your question, I'm not sure either. "strlen() + 1" is used because I think it's the size of a string including the ending '0'.

[erudified]

Okay, cool, it'll be 1-3 days before the SourceForge project is approved.

 

Please let me know how the AtomBIOS changes are working for you - I'd love some feedback on it, just your dmesg output would be great. I'm still stepping through it and adding quite a bit more debug output. It's obviously still not detecting my attached panel on the PANEL connector or getting the EDID, so figuring these two things out are my priority right now. I have a feeling it's something pretty simple that I'm just overlooking. And for some reason quite a bit of the IOLog output in RHDPreInit() isn't getting to the console (even though it's obviously getting pretty far into the function) - no idea why this is happening. Again, I think it's something pretty simple. I didn't change too much!

 

On the sizeof() versus strlen()+1 thing, I think the deal is that we can (and should) use sizeof() where the length that we need to allocate will be determined at compile time. Like the BIOS image length is static I believe. I'll play with it. I need to figure out how to build the XNU kernel so I can get debugging going on OSX.

 

I started to get a Linux debugging environment set up, and I'll probably finish it, but it's just a pain! None of the distros make it particularly easy to get rolling with this, so I may just end up doing a Gentoo build specifically to get some traces.

[erudified]

SWEET! Okay, with a bit of modification I got it to attach the panel. This is a hack, and I'm still not getting the EDID for my monitor, but if I can get it to switch modes properly I don't think I care very much about whether or not I have EDID! Is it really necessary for flat panel monitors where you only want one resolution?

 

It currently has cursor corruption that's fixed by using Expose. Switching modes doesn't give me a black screen or crash! It's like a 'virtual desktop' with Xorg, the actual resolution of the display doesn't change, it stays at 1152x864, but WindowServer thinks that it's drawing on to a 1440x900 framebuffer, so obviously this is still broken, but it is good progress! I'm going to hack on this a bit more tonight, clean it up so it still works somewhat if it *does* get an EDID (it currently ignores EDID altogether in my tree) and I'll post something in the morning.

 

The output got truncated at the start unfortunately, dmesg will only hold so much!

 

nector[3]: DVI-I Device: DFP1 Output: 3 HW DDC 1 HPD 0
AtomBIOS Connector[4]: DVI-I Device: CRT2 Output: 2 HW DDC 1 NO HPD
Connector[0] {RHD_CONNECTOR_VGA, VGA CRT1, RHD_DDC_0, RHD_HPD_NONE, { RHD_OUTPUT_DACA, RHD_OUTPUT_NONE } }
Connector[1] {RHD_CONNECTOR_PANEL, PANEL LCD1, DDC_NONE, RHD_HPD_NONE, { RHD_OUTPUT_LVTMA, RHD_OUTPUT_NONE } }
Connector[2] {RHD_CONNECTOR_TV, SVIDEO TV1, DDC_NONE, RHD_HPD_NONE, { RHD_OUTPUT_DACB, RHD_OUTPUT_NONE } }
Connector[3] {RHD_CONNECTOR_DVI, DVI-I DFP1 CRT2, RHD_DDC_1, RHD_HPD_0, { RHD_OUTPUT_TMDSA, RHD_OUTPUT_DACB } }
Call to AtomBIOS Get Connectors succeeded
FUNCTION: RHDHPDSave
FUNCTION: RHDHPDSet
RHDConnectorsInit: 0 (VGA CRT1) type 1, ddc 0, hpd 0
FUNCTION: RHDI2CFunc
FUNCTION: RHDDACAInit
FUNCTION: RHDOutputAdd
Attaching Output DAC A to Connector VGA 1
RHDConnectorsInit: 1 (PANEL LCD1) type 4, ddc 255, hpd 0
FUNCTION: RHDLVTMAInit
FUNCTION: RHDAtomBiosFunc
FUNCTION: rhdAtomLvdsInfoQuery
LVDS SEQ Dig onto DE: i
FUNCTION: RHDAtomBiosFunc
FUNCTION: rhdAtomLvdsInfoQuery
LVDS SEQ DE to BL: i
FUNCTION: RHDAtomBiosFunc
FUNCTION: rhdAtomLvdsInfoQuery
LVDS Off Delay: i
FUNCTION: RHDAtomBiosFunc
FUNCTION: rhdAtomLvdsInfoQuery
LVDS Duallink: 0x1
FUNCTION: RHDAtomBiosFunc
FUNCTION: rhdAtomLvdsInfoQuery
LVDS 24Bit: 0x0
FUNCTION: RHDAtomBiosFunc
FUNCTION: rhdAtomLvdsInfoQuery
LVDS FPDI: 0x0
FUNCTION: RHDAtomBiosFunc
FUNCTION: rhdAtomLvdsInfoQuery
LVDS Temporal Dither : 0x40
FUNCTION: RHDAtomBiosFunc
FUNCTION: rhdAtomLvdsInfoQuery
LVDS Spatial Dither : 0x20
FUNCTION: RHDAtomBiosFunc
FUNCTION: rhdAtomLvdsInfoQuery
LVDS Grey Level: 0x8
AtomBIOS returned 8 Grey Levels
Detected a 18bit dual link panel.
Printing LVDS paramaters:
MacroControl: 0x0C720407
TXClockPattern: 0x0063
PowerDigToDE: 0x001E
PowerDEToBL: 0x00FA
OffDelay: 0x01F4
PowerRefDiv: 0x0F9F
BlonRefDiv: 0x0000
FUNCTION: RHDOutputAdd
Attaching Output LVDS to Connector PANEL
RHDConnectorsInit: 2 (SVIDEO TV1) type 5, ddc 255, hpd 0
FUNCTION: RHDDACBInit
FUNCTION: RHDOutputAdd
Attaching Output DAC B to Connector TV SVIDEO
RHDConnectorsInit: 3 (DVI-I DFP1 CRT2) type 2, ddc 1, hpd 1
FUNCTION: RHDI2CFunc
FUNCTION: RHDTMDSAInit
FUNCTION: RHDOutputAdd
Attaching Output TMDS A to Connector DVI-I 1
Attaching Output DAC B to Connector DVI-I 1
FUNCTION: RHDHPDRestore
FUNCTION: rhdModeLayoutSelect
FUNCTION: DACASense
DACSense: DAC: 0x00
FUNCTION: DACBSense
[Parallels] Parallels Hypervisor started.
DACSense: DAC: 0x00
FUNCTION: RHDHPDCheck
RHDHPDCheck returned: 1 mask: 1
FUNCTION: TMDSASense
TMDSASense: Disconnected
FUNCTION: DACBSense
DACSense: DAC: 0x00
FUNCTION: RHDMonitorInit
FUNCTION: RHDAtomBiosFunc
FUNCTION: rhdAtomLvdsGetTimings
FUNCTION: rhdAtomLvdsTimings
rhdAtomLvdsTimings: LVDS Modeline: 1440x900  96300  1440 (1440) 1504 1536 (1760) 1760  900 (900) 903 906 (912) 912
Call to AtomBIOS Get Panel Mode succeeded
FUNCTION: RHDAtomBiosFunc
FUNCTION: rhdAtomLvdsGetTimings
Query for AtomBIOS Get Panel EDID: failed
Connector "PANEL" uses Monitor "LVDS Panel":
   Bandwidth: 96MHz
   Horizontal timing:
       54 - 54kHz
   Vertical timing:
       59 - 59Hz
   DPI: 0x0
   Allows reduced blanking.
   Uses Fixed Modes.
   Attached modes:
       Modeline "1440x900"  96  1440 1504 1536 1760  900 903 906 912\M-p\M-(u\^E
Listing modesetting layout:

CRTC 1: tied to PLL 1 and LUT A:
	Outputs: LVDS (PANEL)

CRTC 2: unused

	Unused Outputs: DAC A, DAC B, TMDS A

Validating Fixed Modes from Monitor "LVDS Panel"
 on Connector "PANEL"
FUNCTION: rhdModeValidateCrtc
FUNCTION: DxFBValid: CRTC 1
DxModeValid: CRTC 1
FUNCTION: LVDSModeValid
FUNCTION: RHDGetVirtualFromModesAndFilter
FUNCTION: DxFBValid: CRTC 1
FUNCTION: DxFBValid: CRTC 2
Using 96x96 DPI.
Using 1440x900 Framebuffer with 1472 pitch
ScanoutBuffer at offset 0x00000000 (size = 0x0050E000)
Free FB offset 0x0050E000 (size = 0x07AF2000)
RadeonHD: Display resolutions detected: 
RadeonHD: 1440 X 900 @ 59Hz

[InferiorYeast]

@erudified - just out of curiosity, what happens when you click "detect displays"? does it freeze up, actually detect displays, or just do nothing?

 

thanks for the great work everyone

[erudified]

Okay, the SourceForge project is up.

 

You can grab it by doing:

 

svn co https://ioradeonhd.svn.sourceforge.net/svnr...oradeonhd/trunk ioradeonhd

 

Dong, I'll make you the project owner or admin or just give you full privileges on the SVN repo or whatever you'd like (ditto for Slice). XCode makes it nice and easy to integrate with subversion so hopefully we can get a nice workflow going.. I'm not sure about the best practices for hosting an XCode project in subversion so I guess we'll play this by ear.

[Slice]

Great work, erudified!

Congratulation with the progress.

I afraid you may go by a wrong way.

Linux OS has macrokernel with drivers included. Or you may add new driver independent on existing. So the Linux driver contains all function needed for graphic.

Mac OS has microkernel and extensions (kexts) which have dependencies one on another. We need no and we can't copy all linux sources if thou you can make it working.

Linux driver creates outputs. We already have its! IONDRVSupport.kext that we subclass.

 

Yes, you finally got LVDS info from ATOM BIOS! I have the same from Legacy BIOS. Together we have all?!

You can't get EDID for LVDS? It is not exists! You can work only in one mode obtained from panel info or use some other EDID injected by natit. Why not?

I prefer create list of modes

one - boot resolution

second - from panel_info

3,4,5.. - from some injected EDID.

 

You say that you can't get access to Radeon Registers methods INREG and OUTREG? See my project openati (at topic) where I already do it. The same about configRead32.

Remember device tree:

IOPCIBridge (it is bus)->IOPCIDevice (VGA Card)->IONDRVDevice (it is connector)->IONDRVFramebuffer (resolutions)->IODisplay (actual output)

configRead32 is possible only for IOPCIDevice but not for IONDRVDevice of beyond.

We write a class IONDRV that is friend class for Framebuffer but not located at device tree. It is helper where we can write any procedures that is not included in Framebuffer class.

Switching modes doesn't give me a black screen or crash! It's like a 'virtual desktop' with Xorg, the actual resolution of the display doesn't change, it stays at 1152x864, but WindowServer thinks that it's drawing on to a 1440x900 frame

It is expected result if you don't use Radeon registers for switch resolution.

We can actually just use the X windows style merged framebuffer approach initially rather than doing fancy multihead using the device tree.

If you do that you get driver for X11 environment but not for system at all.

 

My next attempt fails because of many contradictions between Linux sources and MacOSX. And I returned to last working project. I wish to correct Joblo sources and do not use Linux procedures tree. Only get useful procedures to interpret BIOS and EDID. From reverse engineering I know better Radeon flush then proposed by Linux.

[erudified]

I think you're overestimating the trouble with using the Linux driver sources. Pretty much what I've got in mind right now is to put the AtomBIOS specific stuff in a IOPCIDevice subclass (which makes sense to me because the AtomBIOS portion is doing the majority of the register tweaking etc). Then we can do IONDRVDevice on top of that and inherit all of our AtomBIOS (and perhaps legacyBIOS) goodness and from there do IOFramebuffer and IODisplay. In the long term I'd like to get dimming and hardware cursor acceleration, display sensing, proper multihead, etc., working within the OSX model (IOI2CDevice and everything).

 

But initially, I believe we can at least get modesetting working with pretty minor changes using the big monolithic Linux codebase. It's close. I'm kinda tired of messing with it right now, but I think I can get my monitor displaying 1440x900 by the end of the week. I'd bet cash on it!

 

You're spot on about injecting the biggest usable VESA mode into the beginning of the mode list, I need to add that.

 

I'm not very concerned with multihead right now, for me and for most users, I think native resolution on our panels would be good enough initially. It's definitely a priority though. I just meant that we can do a naive MergedFB style approach for multihead to test display sensing etc., and get something that roughly works. It won't play nice with the OSX device tree and having multiple displays and setting their properties etc and the Dock would be stretched across the center, there are a lot of problems with it, but for a first pass I think it'd be alright.

[Slice]

Sounds good. Don't know what you mean about multihead (2 GPU or 2 Display) but I agree that first of all we need to create very simple driver that able to set non-standart resolution as a test of working principle.

I wish information exchange will be useful for all participants. As well as ideas and mistakes. Welcome to discuss!

[dong]

The new RadeonHD caused a KP for my laptop, may need tweak to make it work. IOLog has a limited buffer for output, that's why some debug information is lost when a large amount push out at the same time.

[Slice]

The new RadeonHD caused a KP for my laptop, may need tweak to make it work. IOLog has a limited buffer for output, that's why some debug information is lost when a large amount push out at the same time.

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.

[erudified]

Hey guys, I'm working on getting a debug build of XNU working (as well as upgrading to 10.5.4, cuz I'm still on 5.3), I'll post a copy of it somewhere when I get it up. That ought to help us out quite a bit!

 

I'll also try to figure out how to increase the dmesg buffer length, it's annoying getting the output cut off

[Slice]