465 replies to this topic

[ole2]

Slice, on Apr 7 2008, 08:40 PM, said:

I think I don't need to rewrite IONDRVFramebuffer as joblo did. The better way is to rewrite IONDRVDevice as separate kext.

EDITED:
as ATINDRV

that was my original point-out during study of IONDRVFramebuffer
it's massively using IONDRV device subclass for any hardware related issues

[Slice]

With returning, Ole2!

2 joanplanas
To have QE we need good Framebuffer but Framebuffer is not enough for QE.
I also want to have QE and I work.

[joanplanas]

if you need help to test will be attentive to the messages.

thanks!

------
HP pavilion dv5098ea
ati radeon xpress 200m
amd turion 64

[Slice]

Current state.
I don't like three thing:
1. Zero project IONDRVFramebuffer 1.4.42 doesn't work with IONDRVDevice while 1.4.3 does.
Result - KP at get MMIO.
2. I rewrite IOBootNDRV class to Radeon procedure.
Result - KP at ret = ndrv->getNextResolution.
It is better to create new class IORadeonNDRV (as ATINDRV). Rewrite all again?
3. I rewrite IONDRVFramebuffer class to include I2C members.
It is better to create new class.

I look at connectorsInfo output - no any sense in the digits. Needed investigations.

[Slice]

I am wrong
IONDRVSupport 1.4.3 doesn't work with IONDRVDevice too. So I see no mistakes in 1.4.42 zero project.
Why RadeonFB project make it?

bool
IONDRVFramebuffer::start( IOService * provider )
{
	IOService *		parent = 0;
	OSData *		data;
		
	online = false;
	IODelay(50000);

	/* If we get here, we have matched to an IONDRVDevice */
	do
	{	
		// Save it for further IOReg writings, 
		//nub = IONDRVDevice, parent = IOPCIDevice
		nub = provider;

I need not only testers (I have no alpha version yet). I need advices.

EDITED:
I can't understand yet but previously I can boot with IONDRVDevice
http://forum.insanel...o...91042&st=63

	| |   |	 +-o display@0  <class IONDRVDevice, registered, matched, active, busy 0, retain count 7>
	| |   |	 | | {
	| |   |	 | |   "IODeviceMemory" = (({"address"=0xffffffffd0000000,"length"=0x10000000}),{"offset"=0x9000,"parent"=({"address"=0x0,"length"=0x10000}),"length"=0x100},({"address"=0xffffffffc0100000,"length"=0x10000}))
	| |   |	 | |   "AAPL,gray-value" = <c38c6400>
	| |   |	 | |   "device_type" = <"display">
	| |   |	 | |   "AAPL,gray-page" = <01000000>
	| |   |	 | |   "built-in" = <>
	| |   |	 | |   "AAPL,ndrv-dev" = Yes
	| |   |	 | |   "IOFBDependentID" = 0x2adfb00
	| |   |	 | |   "display-connect-flags" = <00000000>
	| |   |	 | |   "IOFBDependentIndex" = 0x0
	| |   |	 | |   "AAPL,iokit-ndrv" = <20508a27>
	| |   |	 | |   "AAPL,RegEntryID" = <00e78d02ff1872fd656d69537a6c7552>
	| |   |	 | |   "compatible" = <"display">
	| |   |	 | |   "display-link-component-bits" = <06000000>
	| |   |	 | |   "display-type" = <"LCD">
	| |   |	 | |   "name" = <"display">
	| |   |	 | | }
	| |   |	 | | 
	| |   |	 | +-o .Display_boot  <class IONDRVFramebuffer, registered, matched, active, busy 0, retain count 10>
	| |   |	 |   | {

Why not now?
Is there anybody who can successfully boot into gui with ATILead 1.2.0 and without other Radeon drivers?

I really need to use IONDRVDevice because it is provider of ATINDRV class.

[Slice]

Continue developement.

I was fighting with numerous memory allocation errors. Now no more kernel panics.
The driver loaded and give me... black screen. But now I can make dmesg with useful debugging info.
There are plenty of other mistakes needed to resolve.
1. I can't obtain correct EDID either from DDC or BIOS. I manually inject some EDID by ATILead.

				<key>ATI,EDID</key>
				<data>
				AP///////wBaYxFpAQEBASoNAQOAKR94Kk6VoVdMlCYc
				UFS/74CpQIGAgUBxT2FZRVkxWTEKSD9AMGKwMkBAwBMA
				mDIRAAAeAAAA/wBBMjEwMzQyMDAxOTUKAAAA/QAyVR5c
				EQAKICAgICAgAAAA/ABWUDIwMWIKICAgICAgAJk=
				</data>

2. I got correct connection info from BIOS. I have three output: internal LCD, external CRT and TVOUT. But how to use these info? Probably it is needed to create three nubs of NDRVDevices one for each connections and launch three Framebuffers with own datas.
3. I got not correct resolutions info from EDID. Some simple mistakes.

To correct these mistakes it is needed huge work but not impossible.

Attached Files

•  IORadeonSupport_101src.zip   533.69K   46 downloads

[heng2006]

To Slice,

     Thank you for  your hard works.
I hope some days my AGP card (ATI 9600 pro) and mainboard (Asrock 4Dual-VSTA (VIA PT880 chipset))
would work with Leopard and QE/CI.

heng2006

[enzobelmont]

go Slice!!!

YOU ARE THE MAN!!!

[ole2]

Slice, on May 26 2008, 09:53 AM, said:

Continue developement.

I was fighting with numerous memory allocation errors. Now no more kernel panics.
The driver loaded and give me... black screen. But now I can make dmesg with useful debugging info.
There are plenty of other mistakes needed to resolve.
1. I can't obtain correct EDID either from DDC or BIOS. I manually inject some EDID by ATILead.

				<key>ATI,EDID</key>
				<data>
				AP///////wBaYxFpAQEBASoNAQOAKR94Kk6VoVdMlCYc
				UFS/74CpQIGAgUBxT2FZRVkxWTEKSD9AMGKwMkBAwBMA
				mDIRAAAeAAAA/wBBMjEwMzQyMDAxOTUKAAAA/QAyVR5c
				EQAKICAgICAgAAAA/ABWUDIwMWIKICAgICAgAJk=
				</data>

2. I got correct connection info from BIOS. I have three output: internal LCD, external CRT and TVOUT. But how to use these info? Probably it is needed to create three nubs of NDRVDevices one for each connections and launch three Framebuffers with own datas.
3. I got not correct resolutions info from EDID. Some simple mistakes.

To correct these mistakes it is needed huge work but not impossible.

according to Wikipedia:

"Some graphics card drivers have historically coped poorly with the EDID, using only its standard timing descriptors rather than its Detailed Timing Descriptors (DTDs). Even in cases where the DTDs were read, the drivers are/were still often limited by the standard timing descriptor limitation that the horizontal/vertical resolutions must be evenly divisible by 8. This means that many graphics cards cannot express the native resolutions of the most common wide screen flat panel displays and liquid crystal display televisions. The number of vertical pixels is calculated from the horizontal resolution and the selected aspect ratio. To be fully expressible, the size of wide screen display must thus be a multiple of 16×9 pixels. For 1366×768 pixel Wide XGA panels the nearest resolution expressible in the EDID standard timing descriptor syntax is 1360×765 pixels. Specifying 1368 pixels as the screen width would yield an unnatural screen height of 769.5 pixels.

Many Wide XGA panels do not advertise their native resolution in the standard timing descriptors, instead offering only a resolution of 1280×768. Some panels advertise a resolution only slightly smaller than the native, such as 1360×765. For these panels to be able to show a pixel perfect image, the EDID data must be ignored by the display driver or the driver must correctly interpret the DTD and be able to resolve resolutions whose size is not divisible by 8."

which means, EDID data may not be enough for correct display resolution recovery, but DTD should be parsed instead.

[Slice]

Thanks for warning. I know

	for (i = 0; i < 4; i++, block+= DETAILED_TIMING_DESCRIPTION_SIZE) {
		int first = 1;
		if (!(block[0] == 0x00 && block[1] == 0x00)) {
			get_detailed_timing(block, &mode[num]);
			if (first) {
				mode[num].flag |= FB_MODE_IS_FIRST;
				first = 0;
			}
			num++;
		}
	}

[JaS]

I am interested in this project also as you know I have a newer hd radeon but am willing to help out in any way I can. I know with callisto and agp in tiger I have good speed and benches I am hoping this is the missing key to finish support for ATI Radeons. I know I have a framebuffer working already but a homebrew would suite my needs better I believe as it will be designed to work with all our cards.

[Krazubu]

Wandering on the web, I found latests "ATI Displays" tools (4.5.9 last updated for G5 and X1900 iirc).
It adds a special panel in preferences, as usual, it comes with a kext for TVout kext, but - more interesting - it seems this time it's universal.
I had tried 4.5.7 not a long time ago and managed to get the tools to "see" my radeon 9250, it needs to have correct values injected (especially the board codename). However most features were greyed out because of missing intel kexts.
Maybe this time TV out is possible.
I quickly tried again with this new one and my X1600 but haven't managed, however I haven't bothered much about it. I upload it here, maybe you'll manage to get something off it.
I'll try again with my 9250 when I have some time to waste.

You can get it here

[dong]

A little progress for my X1400 mobility!
I subclassed IONDRVFramebuffer and add some code to cscGetNextResolution, now some more resolutions appeared in display preferences.
 Picture_1.png   359.83K   231 downloads
I'm using manually injected EDID to get these resolutions. The problem is that the native resolution:1400x1050 is not shown. Did not figure out the reason yet. And need add code to cscSwitchResoltion to really do the job!

Edit:
Made a mistake when assigning displayMode ID, now all resolutions that my internal LCD supported show up after fix it.
 Picture_2.png   602.3K   180 downloads

[justin1986]

Don't know that much about this, but in Post 50 (by Slice) i see a for i=4 loop, which gets the resolutions from the EDID. And you happen to get 4 resolutions. So my guess is it first passes the 4 lowest resolutions, and the script never gets to 1440, as you do have the common 640,800,1024 and 1280 ones.

So maybe changing it to i=5 or 6 might do the job?

(feel free to shoot me if this is a stupid answer)

[dong]

I'm not using Slice's source code, but rather directly based on apple's source. Actually Slice's kext is not for Radeon card beyond x800.
Also the i=4 loop is just for detailed timing modes which is the max number of this kind of modes in EDID. The 4 modes I observed is from established timing modes and standard timing modes.

After fixing the code, the two detailed timing modes: 1400x1050@60Hz and @50Hz are now listed in display preference. But I am still confused by one thing: the rowBytes gaven by boot mode of "1400x1050x32" is 5632, instead of my calculated value 5600 (1400 * 4). While for 1024x768x32 or 1280x1024x32, the two values are the same.
Where comes the extra 8 pixels in case of 1400x1050? Help is needed to clarify this.

[Slice]

Krazubu, on Jun 3 2008, 02:36 AM, said:

Wandering on the web, I found latests "ATI Displays" tools (4.5.9 last updated for G5 and X1900 iirc).
It adds a special panel in preferences, as usual, it comes with a kext for TVout kext, but - more interesting - it seems this time it's universal.

Good news! I checked it. See picture.
Yes, ATITVOut.kext is universal binary now!!!  
The only problem is to understand how to switch it on.

			<key>IOMatchCategory</key>
			<string>ATITVOut</string>

There is a real task for our development.

dong, on Jun 4 2008, 05:17 PM, said:

A little progress for my X1400 mobility!
I subclassed IONDRVFramebuffer and add some code to cscGetNextResolution, now some more resolutions appeared in display preferences.
I'm using manually injected EDID to get these resolutions. The problem is that the native resolution:1400x1050 is not shown. Did not figure out the reason yet. And need add code to cscSwitchResoltion to really do the job!

I agree. But there are 29 other cscXXX commands that might be needed to do the job.
We need to exchange informations about the commands.

dong, on Jun 4 2008, 09:03 PM, said:

Actually Slice's kext is not for Radeon card beyond x800.

Sorry! I have Radeon9000 and my kext would work for it. For beyond it is a matter for discuss.

Quote

After fixing the code, the two detailed timing modes: 1400x1050@60Hz and @50Hz are now listed in display preference. But I am still confused by one thing: the rowBytes gaven by boot mode of "1400x1050x32" is 5632, instead of my calculated value 5600 (1400 * 4). While for 1024x768x32 or 1280x1024x32, the two values are the same.
Where comes the extra 8 pixels in case of 1400x1050? Help is needed to clarify this.

I am not ready to answer your question. May be you publish your part of the codes where the value is calculated?

My results.
I manually inject EDID and got dmesg

Quote

ATIFB: videomodes to var
1600 1200 1600 1200 0 0 6172 304 64 46 1 192 3 3
Depth set : 32
1600 1200 1600 1200 0 0 6172 304 64 46 1 192 3 3
hStart = 1664, hEnd = 1856, hTotal = 2160
vStart = 1201, vEnd = 1204, vTotal = 1250
h_total_disp = 0xc7010d    hsync_strt_wid = 0x18067d
v_total_disp = 0x4af04e1    vsync_strt_wid = 0x304b0
pixclock = 6172
freq = 16202

But my LCD has mode 1024x768 but not 1600x1200 so I got black screen.
So now I return to the problem of getting good EDID.
I have no EDID in BIOS. I need to get it from I2C but I have no good procedure reliable for my hardware. Searching...

Attached Files

•  ATIDisplay.png   41.31K   145 downloads

[Krazubu]

Slice, I think you have to enable the TV out using the ATI control panel (the app you shot in your post).
That's what I was explaining before, if the rights strings are correctly injected, the card will be detected and many more options will appear, including those for TV out.
However there must be a "generic way" to enable it but it requires some more coding so maybe testing it this way would be better, before getting into something complicated maybe for nothing.
I'm gonna try again with my 9250, I had managed not long ago to enable this panel.

Edit : I'm posting a screen shot to show how it's supposed to look, I did it last time, I didn't have that intel kext yet. Look at the icons on the left.

Edit 2 : I managed to bring back the full panel. I tried several codenames, they all enabled it but only "Bugsy" brang all the features. I join the plist I used in the injecter.
I get an error at the launch of the control panel : "A problem was encountered. Unable to connect to the TVout kernel extensions. Some features are unavailable".
I join a new shot of the TV panel, however it's still greyed out since the extensions can't be "connected".
The extension is loaded successfully, maybe a problem with the device path ?
If you look closely, you'll notice I get a kind of echo, what could this mean ? I don't get this usually when only using VESA. Maybe one of my injected strings triggered something.

<dict>
				<key>@0,AAPL,boot-display</key>
				<integer>1</integer>
				<key>@0,ATY,EFIDisplay</key>
				<string>LVDS</string>
				<key>@0,compatible</key>
				<string>ATY,Bugsy</string>
				<key>@0,device_type</key>
				<string>display</string>
				<key>@0,display-dither-support</key>
				<integer>1</integer>
				<key>@0,display-link-component-bits</key>
				<integer>6</integer>
				<key>@0,display-type</key>
				<string>LCD</string>
				<key>@0,inverter-current</key>
				<integer>0</integer>
				<key>@0,name</key>
				<string>ATY,Bugsy_A</string>
				<key>@1,AAPL,boot-display</key>
				<integer>0</integer>
				<key>@1,ATY,EFIDisplay</key>
				<string>CRT2</string>
				<key>@1,compatible</key>
				<string>ATY,Bugsy</string>
				<key>@1,device_type</key>
				<string>display</string>
				<key>@1,display-dither-support</key>
				<integer>0</integer>
				<key>@1,display-link-component-bits</key>
				<integer>6</integer>
				<key>@1,inverter-current</key>
				<integer>1</integer>
				<key>@1,name</key>
				<string>ATY,Bugsy_B</string>
				<key>AAPL,backlight-control</key>
				<integer>1</integer>
				<key>AAPL00,Coherency</key>
				<integer>2</integer>
				<key>ATY,Copyright</key>
				<string>Copyright ATI Technologies Inc. 2005</string>
				<key>ATY,DeviceID</key>
				<integer>22880</integer>
				<key>ATY,EFIVersion</key>
				<string>1.3</string>
				<key>ATY,VendorID</key>
				<integer>4098</integer>
				<key>DFP1,EDID</key>
				<data>
				AP///////wAebQEAAQEBAQAQAQOAQCWWCs90o1dMsCMJ
				SEwvzgAxQEVAYUABAQEBAQEBAQEBZiFQsFEAGzBAcDYA
				xI4hAAAeDh8AgFEAHjBAgDcAP0MhAAAcAAAA/QA4Sx88
				CQAKICAgICAgAAAA/ABEQTcwWAogICAgICAgANI=
				</data>
				<key>LVDS,EDID</key>
				<data>
				AP///////wAebQEAAQEBAQAQAQOAQCWWCs90o1dMsCMJ
				SEwvzgAxQEVAYUABAQEBAQEBAQEBZiFQsFEAGzBAcDYA
				xI4hAAAeDh8AgFEAHjBAgDcAP0MhAAAcAAAA/QA4Sx88
				CQAKICAgICAgAAAA/ABEQTcwWAogICAgICAgANI=
				</data>
				<key>device_type</key>
				<string>ATY,DDParent</string>
				<key>model</key>
				<string>ATI Radeon 9250 PCI</string>
				<key>name</key>
				<string>ATY,BugsyParent</string>
			</dict>

Attached Files

•  Image_5.png   66.75K   172 downloads
•  Image_1.png   71.27K   146 downloads

[dong]

Slice, on Jun 6 2008, 04:26 AM, said:

I agree. But there are 29 other cscXXX commands that might be needed to do the job.
We need to exchange informations about the commands.

Actually cscGetVideoParameters as well as cscGetNextResolution are the two needed to show available resolutions. Not all the cscXXX control commands are needed to switch resolution in my opinion, but I do not know much at the moment.

Quote

Sorry! I have Radeon9000 and my kext would work for it. For beyond it is a matter for discuss.

Radeon9000 is older than x800. For what I know, x600 and Radeon9600 are in the same serries.

Quote

I am not ready to answer your question. May be you publish your part of the codes where the value is calculated?

In my code, I'm still using the boot mode like what IONDRVFramebuffer do since I can not change resolution now. In the cscGetVideoParameters part, rowBytes need be returned.

					if (cachedMode->modeID == pixelParams->csDisplayModeID)
					{
						pixelInfo->vpBounds.left	= 0;
						pixelInfo->vpBounds.top	= 0;
						pixelInfo->vpBounds.right	= cachedMode->HDisplay;
						pixelInfo->vpBounds.bottom	= cachedMode->VDisplay;
						pixelInfo->vpRowBytes	= fBitsPerPixel * cachedMode->HDisplay / 8;
						pixelInfo->vpPlaneBytes	= 0;
						pixelInfo->vpPixelSize	= fBitsPerPixel;
						ret = kIOReturnSuccess;
					}

In the code, I expect it as "fBitsPerPixel * cachedMode->HDisplay / 8" and it is really the case for 1024x768 and 1280x1024 when I boot in these two modes. But when boot in 1400x1050, it's not correct. I print out the "fRowBytes" that is already there from boot mode, its value is 5632.
As mentioned above, not much or any radeon related code has been added yet, but still I post my whole source here in case people are interested in reading it.
 RadeonX1000_listonly.zip   788.45K   38 downloads

Quote

But my LCD has mode 1024x768 but not 1600x1200 so I got black screen.
So now I return to the problem of getting good EDID.
I have no EDID in BIOS. I need to get it from I2C but I have no good procedure reliable for my hardware. Searching...

I have no idea how to do this too, have to put EDID in the plist file like Callisto patch.

[Slice]

I didn't get full analysis yet. Some informations:
as Dong get

Quote

cscGetVideoParameters as well as cscGetNextResolution are the two needed to show available resolutions

so cscGetCommunicationInfo give us possibility to switch on TVOut.
cscGetScaler, cscGetScalerInfo - for rotating (10.4.9 and up)
cscGetCurMode, cscGetDetailedTiming, cscGetTimingRanges, cscGetModeTiming - also for switch resolution
cscGetGamma - for color adjustments
cscGetMirror - for mirror
cscGetDDCBlock - for getting EDID
cscGetPowerState, cscSleepWake - for sleep function

Some of them was previously rewritten by Joblo. Other we must do else way.

[asstastic]

dong, on Jun 4 2008, 12:03 PM, said:

I'm not using Slice's source code, but rather directly based on apple's source. Actually Slice's kext is not for Radeon card beyond x800.
Also the i=4 loop is just for detailed timing modes which is the max number of this kind of modes in EDID. The 4 modes I observed is from established timing modes and standard timing modes.

After fixing the code, the two detailed timing modes: 1400x1050@60Hz and @50Hz are now listed in display preference. But I am still confused by one thing: the rowBytes gaven by boot mode of "1400x1050x32" is 5632, instead of my calculated value 5600 (1400 * 4). While for 1024x768x32 or 1280x1024x32, the two values are the same.
Where comes the extra 8 pixels in case of 1400x1050? Help is needed to clarify this.

After reading ole2's post on the whole divisible by 8 timing issue I tried mesing with your numbers.

1400x1050 is a 8:6 resolution ( 1400 / 1050 = 1.3333... )

1400 / 8 = 175          All good here
1050 / 8 = 131.25      This is a problem


now let's look at your horizontal pixel value of 1408. To get a matching 8:6 ratio we need a vertical resolution of 1056 pixels.
so we have 1408x1056

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.