465 replies to this topic

[dong]

1408 / 8 = 176
1056 / 8 = 132
Voila, we have a slightly larger resolution that fits the aspect ratio and now fits with the divisible by 8 timing. So either 1400x1050 displays aren't really 1400x1050 pixels, or the driver is adding some padding to the values to make them compatible and the rest of the pixels are lost to overscan.

Thanks for the analysis. It makes sense to me.

Edited:
Read some more documents. It turned out to be a Width vs. Pitch thing.
1400: display width, what we see. It is also the pixel numbers of a line of my LCD since it is the native resolution.
1408: surface pitch, the actual pixel numbers of a framebuffer line (corresponding video memory will be used to handle such a line), must dividable by 32 from ATI register document, seems can be any suitable value as far as enough video memory is available. The radeonHD driver makes it dividable by 256, thus at least be 1536.

The above analysis does not considering multiple screens, otherwise the pitch value is calculated from the whole expanded desktop width (virtual x in radeonHD driver), not from the primary display width only.

This link explains how to differentiate width from pitch: http://msdn.microsof...357(VS.85).aspx

[Slice]

I made new investigations.
I found that IOGraphics project already contains readDDBlock to get EDID from monitor. But the method return kIOReturnUnsupported except AppleDisplay. So in the method hasDDCConnect() I set return(true).
Next. Class IOFramebuffer has reading DDC by I2C as VESA standard while IONDRVFramebuffer - NO! Because it is supposed non-VESA monitor. I will suppose that my monitor is VESA compatible so I can call superclass.
Next. I found that IOI2CFamily.kext in systems 10.4.6 - 10.4.11 is PowerPC only i.e. non-working.
It is my question. Is it possible to use I2C bus on Intel computers?
I got sources from Apple and recompile its to Intel. But I still have I2C timeout. Any thoughts?

EDITED: I found Linux read-EDID sources
http://packages.ubun...eisty/read-edid
and Window EDID viewer
http://www.eldim.fr/...lite-free-tools


This is corrected sources, compiled kext and I2C framework.

[dong]

I made new investigations.
I found that IOGraphics project already contains readDDBlock to get EDID from monitor. But the method return kIOReturnUnsupported except AppleDisplay. So in the method hasDDCConnect() I set return(true).
Next. Class IOFramebuffer has reading DDC by I2C as VESA standard while IONDRVFramebuffer - NO! Because it is supposed non-VESA monitor. I will suppose that my monitor is VESA compatible so I can call superclass.

radeonHD cards use DDC2 channel, I don't know if it matters in IOFramebuffer/IOI2CFamily.

EDITED: I found Linux read-EDID sources
http://packages.ubun...eisty/read-edid
and Window EDID viewer
http://www.eldim.fr/...lite-free-tools

Worth researching on it, though the INT10 needs some library that may not available in apple. Linux radeonHD driver uses ATOMBIOS function in addition to i2c method to read EDID, I'm trying to port the ATOMBIOS part.

[Slice]

radeonHD cards use DDC2 channel, I don't know if it matters in IOFramebuffer/IOI2CFamily.
Worth researching on it, though the INT10 needs some library that may not available in apple. Linux radeonHD driver uses ATOMBIOS function in addition to i2c method to read EDID, I'm trying to port the ATOMBIOS part.

May be you would be successful. I have non-ATOM but legacyBIOS, and I know that I have no EDID in my BIOS.

[Slice]

New problems.
I checked different programs for Windows to get EDID. No success
WinI2C/DDC - no EDID
DumpEDID - failed to read
ELDIM EDID viewer - got 3 monitor infos but no dump
NIRSOFT MonitorInfo - got 8 monitor infos but no dump.

[asstastic]

I made new investigations.I found that IOGraphics project already contains readDDBlock to get EDID from monitor. But the method return kIOReturnUnsupported except AppleDisplay. So in the method hasDDCConnect() I set return(true).Next. Class IOFramebuffer has reading DDC by I2C as VESA standard while IONDRVFramebuffer - NO! Because it is supposed non-VESA monitor. I will suppose that my monitor is VESA compatible so I can call superclass.Next. I found that IOI2CFamily.kext in systems 10.4.6 - 10.4.11 is PowerPC only i.e. non-working.It is my question. Is it possible to use I2C bus on Intel computers?I got sources from Apple and recompile its to Intel. But I still have I2C timeout. Any thoughts?EDITED: I found Linux read-EDID sourceshttp://packages.ubun...eisty/read-edidand Window EDID viewerhttp://www.eldim.fr/...lite-free-toolsThis is corrected sources, compiled kext and I2C framework.

http://www.paintyour.../i2c/index.html
code for basic I2C over a DDC bus in osx, no idea if this will work on a hackintosh but it might help in figuring out how to read EDID info.

VESA open standards including EDID specs are available here:https://vesa.sharedwork.com/
(site doesn't work in firefox for me, safari is ok)
for email use: public@vesa.org
Password is: stds2007

[Slice]

http://www.paintyour.../i2c/index.html
code for basic I2C over a DDC bus in osx, no idea if this will work on a hackintosh but it might help in figuring out how to read EDID info.

Thank for very smily project! Really it is for native Mac

/* Locate all available I2C buses */
	if((dict = IOServiceMatching(kIOI2CInterfaceClassName)))
	{

As I previously mentioned the interface isn't working.
Nontheless I got new information

/* Addressing seems to work a little wonky in OSX; I2C addresses are
	   supposed to be 7 bits, but it appears that the IOI2C* functions
	   include the subsequent read/write bit within the address fields,
	   making for an 8-bit value (address is shifted left by one).  But
	   now, the Mindsensors servo controller claims to have a default
	   address of 0xb0 (and even indicates such in its startup blink),
	   which exceeds the 7-bit address range.  I believe the servo
	   controller is treating the address and subsequent bit similarly.
	   So the left-shift isn't performed if the high bit is set. */
	request.sendAddress = request.replyAddress =
	  (address & 0x80) ? address : (address << 1);

In IOGraphics there is address 0xa0.
but here

static const short
	i2cAddress = 0x50,	   /* 1010AAA as per Microchip specs */

???????
This is OK?! 0x50 << 1 = 0xa0

[ole2]

on the following site of reading tool for DDC/CI, I found following note:

DDC/CI device seems is a client at I2C bus address 0x37 (0x6e for write transactions, 0x6f for read).

0x6e is itself, 0x37 shifted left for 1 bit, where right-most bit zeroed for i2C writing command, or set to 1 for i2C reading

Data being sent/received is formatted in frame, each frame has a fixed prefix byte, followed by length of the payload, payload itself and checksum made of XORing submitted/received I2C message. The initial XOR value depends on operation attempted, it's equal to I2C address submitted on the wire and seems to be fixed value for read transaction. For details see ddcci-tool sources.

and another note from same pase seems to be practical to take in account:

Once loaded it's a good idea to scan I2C busses using i2cdetect program (launch it with no args to see the list of I2C busses). Your monitor should answer at least at address 0x50 (EDID reading) and 0x37 (DDC/CI). The 0x37 is mandatory for runnig program. If it does not answer - try other busses as well. My Radeon exposes 4 busses - crt, vga, dvi and monid. It's therefore answers at 0xa0 at vga and dvi (as expected) and at 0x37 at vga bus only.

[ole2]

Thank for very smily project! Really it is for native Mac

/* Locate all available I2C buses */
	if((dict = IOServiceMatching(kIOI2CInterfaceClassName)))
	{

As I previously mentioned the interface isn't working.

isn't workign, as you having dict empty?

correct me, if I'm wrong: we could do this call from the UserSpace too?

how nVidia guys performing such call to get access to i2c of GPU?

[Slice]

2 Dong
Only two month needed for me to make your RadeonPCI works
Thank you again! Now I can control Radeon registers in the new way.

0x0140: 32002002 1305657A 3FFF3800 43FF4000 0009000F 01FFFFFF 5060006A 3FFF3800
0x0160: 00000040 00000000 0000001B 00000606 3C000000 000E0000 306009E1 86868686

Here I make some improvements to format output.

void radeon_dump_io( void *map, CARD32 start, CARD32 end )
{
	int i, j;
	for (j = start; j <= end; j+=32)
	{
		printf("0x%4.4X: ",j);
		for (i=0; i<31; i+=4)
		{
			CARD32 val = RegRead(map, (i + j));
			printf(" %8.8X", val);
		}
		printf("\n");
	}
}

May be insert other function here? (DDC, OpenGL command )

Apple's SimpleUserClient works too... Dunno what is changed in my system. May be X11 libraries?

2 ole2
Thanks for new link.
How can you compile the tool?

ddcci-tool.c:34:27: error: linux/i2c-dev.h: No such file or directory
ddcci-tool.c: In function 'i2c_write':
ddcci-tool.c:102: error: storage size of 'msg_rdwr' isn't known
ddcci-tool.c:103: error: storage size of 'i2cmsg' isn't known
ddcci-tool.c:114: warning: implicit declaration of function 'ioctl'
ddcci-tool.c:114: error: 'I2C_RDWR' undeclared (first use in this function)

Other interesting link with i2c-dev.h
http://xgoat.com/wp/...space-in-linux/
I afraid it is far from our needs...

[ole2]

here it is, how they getting access to i2C interfaces list:

int main( int argc, char * argv[] )
{
	kern_return_t kr;
	io_service_t  framebuffer, interface;
	io_string_t	  path;
	IOOptionBits  bus;
	IOItemCount	  busCount;
	Boolean	  save;

this part is getting access to IONDRV API. probably a NUB one, as it's a typedef

framebuffer = CGDisplayIOServicePort(CGMainDisplayID());
	{
		kr = IORegistryEntryGetPath(framebuffer, kIOServicePlane, path);
		assert( KERN_SUCCESS == kr );
		fprintf(stderr, "\n/* Using device: %s */\n", path);

this part retrieve list of i2C busses accesible in GPU

kr = IOFBGetI2CInterfaceCount( framebuffer, &busCount );
	assert( kIOReturnSuccess == kr );
	
	for( bus = 0; bus < busCount; bus++ )
	{
		IOI2CConnectRef  connect;

		fprintf(stderr, "/* Bus %ld: */\n", bus);

this part retreive handle (address???) to i2C host interface, probably a NUB one, same type as IONDRV interface

kr = IOFBCopyI2CInterfaceForBus(framebuffer, bus, &interface);
		if( kIOReturnSuccess != kr)
		continue;

this part connecting to selected i2C interface

kr = IOI2CInterfaceOpen( interface, kNilOptions, &connect );
	
		IOObjectRelease(interface);
		assert( kIOReturnSuccess == kr );
		if( kIOReturnSuccess != kr)
		continue;
	
		save = (argc > 1) && (argv[1][0] == 's');

this part passing connection reference to EDID reader/parser

EDIDRead( connect, save );
		
		IOI2CInterfaceClose( connect, kNilOptions );
	}
	}

	exit(0);
	return(0);
}

the rest of the code is here
reference to this code is taken from nVidia EDID handling discussion MSG on forum

maybe, all we need, reuse already distributed IOGraphics package?

by the way, following components are also there:

IOBootFramebuffer.c

IONDRV.cpp
IONDRV.h

IOI2CInterface.cpp

etc.

[Slice]

OK!
But the code will work if system will have I2C driver and I2C registry entries. Namely for that I recompile IOI2CFamily.kext and framework. I am not sure that it is enough.

[Slice]

New achievements.
I2C works

ATIFB: aper_base: 38000000 MC_FB_LOC to: 3fff3800, MC_AGP_LOC to: 47ff4000ATIFB: radeon_get_moninfo: bios 4 scratch = 1000004ATIFB: Bios Connector table: ATIFB: Port0: DDCType-0x60, dac_type-1, tmds_type-0, connector_type-1ATIFB: Port4: DDCType-0x0, dac_type--1, tmds_type--1, connector_type-7ATIFB: Port5: DDCType-0x0, dac_type-1, tmds_type--1, connector_type-5ATIFB: Port6: DDCType-0x0, dac_type-0, tmds_type-0, connector_type-0ATIFB: found connection from BIOS:ATIFB: Retreived PLL infos from BIOSATIFB: Reference=14.32 MHz (RefDiv=6) Memory=300.00 Mhz, System=165.00 MHzATIFB: PLL min 20000 max 35000ATIFB: PLL foundATIFB: pci registeredStarting monitor auto detection...IONDRVFramebuffer::getEDIDIONDRVFramebuffer::createI2CI2C created   defaultI2CTimingIONDRVFramebuffer::getEDID fromI2C OKATIFB: I2C (port 2) ... found LVDS panelIONDRVFramebuffer::getEDIDIONDRVFramebuffer::createI2CI2C created   defaultI2CTimingIONDRVFramebuffer::getEDID fromI2C OKATIFB: I2C (port 3) ... found LVDS panelATIFB: probe screen end ATIFB: biosEDID @0000

but the result

| | | | "I2C,EDID" = <aa000000000000000000000000000000000000000000000000000000000000000000000000000
00000000000000000000000000000000000000000000000000000000000000000000000000000000
00000000000000000000000000000000000000000000000000000000000000000000000000000000
0000000000000000>

In the attempt I change the address of I2C write
0x6e instead of 0xa0 as I saw in Joblo's project.
More investigations needed. I have no much time for that.

[ole2]

ATIFB: Port0: DDCType-0x60, dac_type-1, tmds_type-0, connector_type-1

any chance to have Port address also printed?

[Slice]

We have 4 buses for I2C (4 ports, connectIndexes). But 8 connections?!

void IONDRVFramebuffer::setDDCData( IOIndex connectIndex, UInt32 value  )
{
	val = INREG(rinfo->i2c[connectIndex].ddc_reg) & ~(VGA_DDC_DATA_OUT_EN);
	
/*There is connectIndex assumes to be 0..3
	rinfo->i2c[0].ddc_reg	= GPIO_MONID;
	rinfo->i2c[1].ddc_reg	= GPIO_DVI_DDC;
	rinfo->i2c[2].ddc_reg	= GPIO_VGA_DDC;
	rinfo->i2c[3].ddc_reg	= GPIO_CRT2_DDC;
*/

These are general Radeon registers 0x60, 0x64, 0x68, 0x6c.
In Apple's IONDRVSupport sources this method is empty. IOReturnUnsupported.
After the replacement we would expect I2C/DDC to be working... For me no
I still have no good connectionsInfo from BIOS (linux procedure is wrong) and can't get EDID neither from BIOS nor from I2C. Any other ideas or sources?
Dong, can you modify RadeonPCI to read I2C? Just copy I2C routines from RadeonFB and make Client "./RadeonDump -i bus,addr,length". Hex output to screen.

Bad, bad, bad...
I got black screen even if I comment out all RadeonFB additions. So the project is damaged at basis.

Return to initials. But all my corrections in Radeon's procedures are actual.

[dong]

I still have no good connectionsInfo from BIOS (linux procedure is wrong) and can't get EDID neither from BIOS nor from I2C. Any other ideas or sources?

I found this: http://www.defyne.org/dvb/driver.html
Take a look at the "Generic I²C interfaces" part, maybe it can be used.
I also found the source link from its forum: http://rapidshare.co...38/dvb.zip.html
The I2C souce is located in folder "driver".

Dong, can you modify RadeonPCI to read I2C? Just copy I2C routines from RadeonFB and make Client "./RadeonDump -i bus,addr,length". Hex output to screen.

I'll take a look at it to see if I can do anything here.

Bad, bad, bad...
I got black screen even if I comment out all RadeonFB additions. So the project is damaged at basis.
Return to initials. But all my corrections in Radeon's procedures are actual.

I'm stucking at the very beginning too, whenever a struct variable with protocol defined in radeonHD header file is initialized or visited in my RadeonX1000.cpp, I got a kernel panic even without doing anything else. Did not figure out any clue yet.

Edited:
Well, I found a very interesting thing. A hot reboot will always cause the kernel panic but if I power off and boot, sometimes no kernel panic. What could be the problem?

[enzobelmont]

Hi guys i am very happy somebody is still working on this.

i would like to help but i have no skills programming.

In phoronix forums there is an thread called "Ask ATI devs" there are ati devs answering to linux users.

maybe this could be useful.

link here!

[Slice]

Take a look at the "Generic I²C interfaces" part, maybe it can be used.
I also found the source link from its forum:
The I2C souce is located in folder "driver".

I have different linux sources and even MacOSX sources. Thanks for other one.
Wow! I see sources of PhilipsSAA7146! My TVTuner is 7133. Some new chance!
Now I need testing variants. I need ./RadeonDump

I'll take a look at it to see if I can do anything here.

You need to call
IONDRVFramebuffer::doI2CRequest(
but may be change class to something else
and also include all dependencies.
Joblo use
req.replyTransactionType = kIOI2CSimpleTransactionType
I think it is an error, we need kIOI2CDDCciReplyTransactionType

I'm stucking at the very beginning too, whenever a struct variable with protocol defined in radeonHD header file is initialized or visited in my RadeonX1000.cpp, I got a kernel panic even without doing anything else. Did not figure out any clue yet.

Edited:
Well, I found a very interesting thing. A hot reboot will always cause the kernel panic but if I power off and boot, sometimes no kernel panic. What could be the problem?

The problem is in dynamic memory allocation. RadeonFB uses IOMalloc in internal procedure. So variables created temporary and randomly destroyed or pointer attached to wrong address. In my latest sources I change many of these errors. Now I have no KP.

[dong]

Now I need testing variants. I need ./RadeonDump
You need to call
IONDRVFramebuffer::doI2CRequest(
but may be change class to something else
and also include all dependencies.

I put these codes in RadeonDump.c and changed some functions with user space version. Don't know if it will cause any unexpected results. I just failed to dump any I2C data. You may play with it.
 RadeonDump.c.zip   5.56KB   11 downloads

Joblo use
req.replyTransactionType = kIOI2CSimpleTransactionType
I think it is an error, we need kIOI2CDDCciReplyTransactionType

I saw you did not has I2CReadDDCciData yet, thus I did not take care of it.

The problem is in dynamic memory allocation. RadeonFB uses IOMalloc in internal procedure. So variables created temporary and randomly destroyed or pointer attached to wrong address. In my latest sources I change many of these errors. Now I have no KP.

Did you mean IOMalloc in an static function will cause such problem?

[Phoenix23]

Just a side question maybe a little bit offtopic. In another thread I read that in the very first stages of the 10.5 generation GL/QE/CI worked with old cards. Is this true?

If so, what if the problem would not be the drivers itself but instead the whole GL/CI/QE framwork system, which could be rewritten at a later point of the beta development to match new requirements?