Jump to content

HD2400 Mobility Revisited

0xdeadbeef

By 0xdeadbeef,
in ATi

 Share
16 posts in this topic

Recommended Posts

0xdeadbeef
0xdeadbeef
Posted
Posted

Ok now I have some time on my hands and this HD2400M internal display thing is really beginning to {censored} me off.

 

I have a feeling that the only reason it won't work on internal display is that Iago has no way of telling that the display is even present.

 

For example on my Toshiba, the conntest utility from the linux RadeonHD driver reports no load-detect, no HPD and no DDC on the internal display connector. So it follows naturally it won't be able to tell there is a display there unless it is told so.

 

Now looking through Iago, we see that we have the capability to specify settings like "no-hotplug-detect" in the device registry through Natit as well as nice things like "override-no-connect", "connector-type", "override-no-edid", so I figure with a combination of an Injector, some EDID voodoo and maybe if necessary patching the connections tables in the driver, we can completely construct a display for Iago to play with.

 

What I would really like, is if some kind person had access to an hd2400 imac and could run the linux conntest utility on it. And, of course if anyone has any ideas ;)

Link to comment
Share on other sites
0xdeadbeef
0xdeadbeef
Posted
  • Author
Posted
welcome back deadbeef :}

 

 

Thanks, Aidass. I see some people have had progress with the Mobility 3650 while I have been hibernating ;)

 

You managed to get a 2400M working on internal without backlight?

 

My gut tells me this problem is not so much the actual connectors, but what is "connected to the connectors" :-) I think most PC Laptop manufacturers that use OEM cards don't bother to include proper sense lines on their internal displays, because it's not like the bloody display is going anywhere, is it? ;-)

 

I have disassembled every damned ATI framebuffer out there and there is nothing really in the driver that would prevent it bringing up the internal display if it knew there was one there The code is very generic ( Well except a few connector tables but hey!).

 

Iago and the other Framebuffers for example all go through all the functions like CheckLVDSConnection(), CheckTMDSConnection() CheckDAC1Connection(), CheckDAC2connection() ... they are all there, and they all depend on DDC communication and sense lines to get the display info - and if DDC and sense fails, it calls a function ForceReadEDID() that reads properties like "connector-type" and "override-no-connect" that allow manual specification.

 

Now like I said My Tosh P200 has a 2400M and running conntest from linux RadeonHD gives me this:

 

 

 

Load Detection: RHD_OUTPUT_NONE

HotPlug: RHD_HPD_NONE

DDC: RHD_DDC_NONE

 

 

 

But if there was a ddc line connected it would give something like this:

 

 

 

Load Detection: RHD_OUTPUT_NONE

HotPlug: RHD_HPD_NONE

DDC: RHD_DDC_1

LVDS Info:

18bits, dual link, LDI Panel found.

Power Timing: 0xF9F, 0x00D, 0x03, 0x19, 0x1F4

Macro: 0x0C720407, Clock Pattern: 0x0063

 

 

 

 

I think to get a good fix to this problem, this is a good place to start.

Link to comment
Share on other sites
0xdeadbeef
0xdeadbeef
Posted
  • Author
Posted

Interesting stuff reported from the alternative xf86-video-ati driver though:

 

(II) RADEON(0): Output VGA-0 using monitor section Monitor0

(II) RADEON(0): I2C bus "VGA-0" initialized.

(II) RADEON(0): Output HDMI-0 has no monitor section

(II) RADEON(0): I2C bus "HDMI-0" initialized.

(II) RADEON(0): Output LVDS has no monitor section

(WW) RADEON(0): LVDS Info:

XRes: 1440, YRes: 900, DotClock: 88750

HBlank: 160, HOverPlus: 80, HSyncWidth: 32

VBlank: 26, VOverPlus: 17, VSyncWidth: 6

(II) RADEON(0): I2C bus "LVDS" initialized.

(II) RADEON(0): Port0:

Monitor -- AUTO

Connector -- VGA

DAC Type -- Primary

TMDS Type -- None

DDC Type -- 0x7e40 <------- (1)

(II) RADEON(0): Port1:

Monitor -- AUTO

Connector -- HDMI-B

DAC Type -- None

TMDS Type -- Internal

DDC Type -- 0x7e50 <----------- (2)

(II) RADEON(0): Port2:

Monitor -- AUTO

Connector -- LVDS

DAC Type -- None

TMDS Type -- None

DDC Type -- 0xac0 <----------- (3)

(II) RADEON(0): I2C device "VGA-0:ddc2" registered at address 0xA0.

(II) RADEON(0): I2C device "VGA-0:ddc2" removed.

(II) RADEON(0): Output: VGA-0, Detected Monitor Type: 0

Dac detection success

finished output detect: 0

(II) RADEON(0): I2C device "HDMI-0:ddc2" registered at address 0xA0.

(II) RADEON(0): I2C device "HDMI-0:ddc2" removed.

(II) RADEON(0): Output: HDMI-0, Detected Monitor Type: 0

invalid output device for dac detection

finished output detect: 1

(II) RADEON(0): I2C device "LVDS:ddc2" registered at address 0xA0.

(II) RADEON(0): Output: LVDS, Detected Monitor Type: 2

(II) RADEON(0): EDID data from the display on output: LVDS ----------------------

(II) RADEON(0): Manufacturer: LPL Model: a002 Serial#: 0

(II) RADEON(0): Year: 2007 Week: 0

(II) RADEON(0): EDID Version: 1.2

(II) RADEON(0): Digital Display Input

(II) RADEON(0): Max Image Size [cm]: horiz.: 37 vert.: 23

(II) RADEON(0): Gamma: 2.20

(II) RADEON(0): No DPMS capabilities specified

(II) RADEON(0): Supported color encodings: RGB 4:4:4 YCrCb 4:4:4

(II) RADEON(0): First detailed timing is preferred mode

(II) RADEON(0): redX: 0.590 redY: 0.349 greenX: 0.327 greenY: 0.547

(II) RADEON(0): blueX: 0.154 blueY: 0.138 whiteX: 0.312 whiteY: 0.328

(II) RADEON(0): Manufacturer's mask: 0

(II) RADEON(0): Supported additional Video Mode:

(II) RADEON(0): clock: 88.8 MHz Image Size: 367 x 230 mm

(II) RADEON(0): h_active: 1440 h_sync: 1520 h_sync_end 1552 h_blank_end 1600 h_border: 0

(II) RADEON(0): v_active: 900 v_sync: 917 v_sync_end 923 v_blanking: 926 v_border: 0

(WW) RADEON(0): Unknown vendor-specific block 0

(II) RADEON(0): LGPhilipsLCD

(II) RADEON(0): LP171WP4-TLB4

(II) RADEON(0): EDID (in hex):

(II) RADEON(0): 00ffffffffffff00320c02a000000000

(II) RADEON(0): 00110102802517780a1c909759538c27

(II) RADEON(0): 23505400000001010101010101010101

(II) RADEON(0): 010101010101ab22a0a050841a305020

(II) RADEON(0): 16046fe6100000190000000000000000

(II) RADEON(0): 00000000000000000000000000fe004c

(II) RADEON(0): 475068696c6970734c43440a000000fe

(II) RADEON(0): 004c503137315750342d544c42340090

finished output detect: 2

finished all detect

 

 

Detects the LVDS DDC no problem ( although in a different way to the VGA and HDMI ). Damn wish I had some HDMI capable equipment.

 

 

So we have a DDC sense: must check out the _atom_ReadEDIDFromHWAssistedI2C & DDCGet/SetSense functions in Iago.

Link to comment
Share on other sites
0xdeadbeef
0xdeadbeef
Posted
  • Author
Posted
good to see you again :wacko:

 

Hey, thanks mate :D Hope the winter isn't killing you up there! Nice to be back - having to work is a pain lol.

 

 

That said, it looks like my job will be covering a MBP for me soon, it'll be proper kernel debugging from now on - much nicer than having to reboot the hack for every patch :P

 

After more digging around a bit more in the Iago framebuffer, I find this rather interesting bit of code:

 

void __cdecl HW_InitLVDS()
{
;
}

 

 

Hardly surprising that it has trouble bringing up the internal display, eh? haha. This is actually supposed to be the init code for TMDSB, so using my trusty R600 register reference I have patched in this:

 

int __cdecl HW_InitLVDS(int a1)
{
 int value;

 v2 = regr32(a1, 0x7A80);
 return regw32(a1, 0x7A80, value & 0xFFFFFCFF | 0x100);
}

 

 

Which should fire it up.

 

Funnily enough all the rest of the LVDS code is still in there, so there's a chance we might be getting somewhere.

Unfortunately, the DDC is still failing on my internal, so no actual display yet, but here's hoping :P

Link to comment
Share on other sites
Boombeng
Boombeng
Posted
Posted
What I would really like, is if some kind person had access to an hd2400 imac and could run the linux conntest utility on it. And, of course if anyone has any ideas :(

 

Hi 0xdeadbeef, Nice project!

 

There is also an interesting thing with some Toshiba laptops (A300) with radeon HD3650M and HD3450M. Megalodon Framebuffer seems to recognise their internal display whereas on other laptops with the same cards it doesn't work...

May be a Linux conntest on these special Toshiba could help you in your research?

 

Salutations

Link to comment
Share on other sites
0xdeadbeef
0xdeadbeef
Posted
  • Author
Posted
Hi 0xdeadbeef, Nice project!

 

There is also an interesting thing with some Toshiba laptops (A300) with radeon HD3650M and HD3450M. Megalodon Framebuffer seems to recognise their internal display whereas on other laptops with the same cards it doesn't work...

May be a Linux conntest on these special Toshiba could help you in your research?

 

Salutations

 

 

 

Actually a better idea than the conntest is if anyone with a mobility Radeon on PC or radeon-tooled iMac could download a linux livecd with the xf86-video-ati driver instead of the radeonhd one (the ati driver uses atombios to get the connector tables, so it's more accurate) and boot with that - then post the file /var/log/Xorg.0.log from the boot along with and ioreg dump and their model.

 

One such distro is at Backtrack But I suppose any distro will give some info.

 

Once I have a handle on these :| connectors, I'll have a better idea what's going on.

Link to comment
Share on other sites
  • 2 weeks later...
  • 2 weeks later...
 Share
Go to topic listing
×
×
  • Create New...