Posted 16 January 2015 - 08:39 PM

Make sure you're booting with GraphicsEnabler=No and kernel flag arch=i386.

EDIT

Preliminary findings indicate that what you're seeing is the X3100 being in "broken mirror" mode

Try connecting an external display + USB mouse and keyboard and close the lid. With a little luck this should make the external display primary, allowing you to work from there.

/EDIT

I get similar behavior when hotplugging an external display on the VGA port and clicking 'detect displays'. On both displays (stuck in mirrored mode). If I boot with the external display already connected it works, but I have no rotation support on the external display which is a bummer since it's rotated.

I'm currently working on fixing those issues (display corruption and rotation) and get brightness control working as well.

*Brain dump* current status/issues

dmesg says "IG: Invalid firmware max backlight setting"

I compiled a 32-bit version of Rehabman's ACPIBacklight driver and got brightness slider + hotkeys (still need remapping) responding, the sun decal appears but brightness doesn't change. I found the backlight code in the first SSDT table but I guess it needs something done to it for ACPIBacklight.kext to work with it. If I don't load the backlight SSDT table the brightness level changes but it's busted (full brightness -> wobbly-dark -> pitch black).

I saw a DSDT patch for an HP laptop that had the Backlight methods moved into the PNLF device but I can't figure out how to do that with the code I have. But I don't think that's relevant...? The SSDT table with backlight code seems to be picked up just fine, it's just that the values are wrong, or interpreted wrong.. I think.

Every time i try to tamper with GFX0 and reboot I just get a black screen! At least it doesn't freeze, I can use the power button to reboot blind.

I see a permanent, rogue "display@2,1" outside of the GFX0 device in IOREG that I don't know how to get rid of. The internal LCD and external display, when connected, show up inside GFX0 device as you'd expect. dmesg has a line that says "Display not usable".

The T61 DSDT has duplicated code for the main 0x00020000 VID device (which is now GFX0 - I left the duplicate named VID) as well as LCD, CRT and DVI inside another device called AGP. It looks like this code is supposed to "take over" when the T61 is docked...?

The backlight SSDT table also refers to the duplicate devices inside "AGP". Next trial will be stripping or commenting out all of that and see what happens because I suspect that these duplicate displays are causing at least some of the issues I'm seeing.

I'd like to get it to work with the "duplicates" intact though because the T61 mini dock currently goes for a whopping 20 dollars on Amazon and I'd like to get one just to play around with it

The FakeSMC GPU sensors plugin does not attach to the X3100.

HWMonitor.app window graphics are corrupted, but only the blue part!

HWMonitor.app shows CPU to be running at 796MHz + multiplier x4.0 but that can't be true.

Another strange issue is that FileNVRAM.dylib (tried current 1.14 and 1.13) will sometimes generate a new nvram.plist after reboot - but with a different name - but it's not because the T61's UUID is changing, the UUID stays the same! I don't know what's wrong, but the nvram.plist does not have a .plist file extension..it has no extension...it's like the filename is too long or something, current one is named nvram.f0c3e200-f053-ff00-f053DriversPackage-1fe40 with no extension - yes it has "DriversPackage" in the name. Weird right, I've never seen that before.

... whatever... more to come.. including files, how I got Rehabman's latest ACPIBattery driver working, Chameleon cpu.c patch to correct FSB calculation, additional keys addded to FakeSMC and so on etc etc. If anyone else is interested in this old piece of sh** lol

Posted 21 January 2015 - 06:38 AM

Fixed display corruption by creating display profiles for both displays using EDID extracted from IOREG in safe mode.

Rotation on external display also works now.

The T61 normally goes to sleep when I close the lid. With the external display connected it stays awake when I close the lid and the external display automatically becomes the main display! Very cool, but of course useless without external keyboard + mouse.

CPU state switching works pretty well with MacBook5,1 model identifier and DropSSDT=y + Chameleon generated states.

I can't get any state switching to happen when I use a MacBook model identifier for a MacBook that actually has a X3100!

The downside to using MB5,1 is that AGPM now loads and complains about the GPU (the MB5,1 has Nvidia graphics, not X3100). I get some freezes on animations in the Finder and the flurry screensaver stops animating after a while. These are different glitches than before, pretty sure this is AGPM. Need to decide whether to edit or delete.

HWMonitor CPU readout is strange, it shows 6x multiplier for 546Mhz. Either the multiplier should be 3 or the CPU freq should be 1092. Some mult/freq combos are correct, others are not.

Undid Chameleon cpu.c patch, it caused sound issues. I can live with the bus freq. being 182Mhz (supposedly due to IDA) this makes max CPU speed 2093Mhz.

USB is completely dead after waking from sleep. Probably easy to fix in DSDT.

To Do:

Get fakesmc gpusensors to attach

Figure out what's wrong with FileNVRAM.dylib (it saves several plists a day with no extension and "DriversPackage" in the name and I lose settings across reboots...no 32-bit support?)

I still see a phantom "display" device outside of the X3100 in ioreg. After I switching to MB5,1 it even has AGPM attached to it, while the entry for my external display does not!

Figure out how to get ACPIBacklight.kext to work with the backlight code in the first SSDT table.

Posted 21 January 2015 - 09:38 PM

bronxteck

InsanelyMac Geek

Members

228 posts

tune fakesmc plist to use the MacBook5,1 model smbios identifiers. use smc rev numbers from here http://support.apple.../en-us/HT201518 replacing the fake smc default one's should be in 3 places and see if that helps with your glitches.

Posted 22 January 2015 - 12:07 AM

I always change the smc rev keys accordingly when changing model identifiers. Now that you mention it I forgot to change smc-santarosa to smc-mcp. So I did, but it made no difference.

Glitches/freezes are gone after removing AppleGraphicsPowerManagement.kext but I'd rather use MacBook4,1 (exact same Santa Rosa platform, T8100 CPU, X3100 GPU) ..there must be a way..

I discovered today that good old natit.kext works for property injection. everything I inject goes into main VID@2 device, but also into the phantom display@2,1 device lol

I'm starting to think that this phantom display is the main issue here, no idea how to eliminate it. It's weird how the X3100 shows as two separate devices in LSPCI. Both on the T61 and LSPCI from other machines, including the MacBooks that use it. Except in the MacBook IOREG there is no display@2,1 outside the GFX0 device of course.. meh

While I could inject everything from the MacBook3,1 DSDT when using the MacBook5,1 identifier, display corruption (identical to photos in 1st post) returned after switching model identifier back to MacBook3,1 or 4,1. I'm currently trying to figure out exactly what injected data causes the display corruption to happen.

Back to MB4,1 and removed the display overrides. Display corruption gone, re-adding data to Natit.kext plist line by line, rebooting each time. boooooooooring

Posted 26 January 2015 - 05:41 PM

Gringo Vermelho

The Jan Bird fix

Supervisors

6,224 posts

Gender:Male

Location:Brazil

I have Clover on a flash drive, still trying to learn how to use it. Right now I'm using it for emergencies only (read: when I f**k up). I have some doubts and ran into some issues that I can't find an answer to in the FAQ. The whole auto-configuring thing is of course convenient but I'm not happy that I have close to no idea what is actually being auto-configured.

I had Clover installed to the hard drive (root of the OS partition, not EFI) but it seemed like Clover was unable to write to its own folder, no changes that I made in the boot GUI would stick. Maybe because I was missing the HFS+ driver? Also Clover Configurator, which is very helpful when you're a Clover noob, does not run on 10.7.5.

What model identifier are you using on the 1525?

The MacBook4,1 is literally identical to my T61, same CPU, chipset and the X3100 but ACPI_SMC_PlatformPlugin blocks speedstepping. I don't like to do it this way but it seems to work once I delete MacBook4_1.plist from inside. Using Chameleon generated SSDTs, dropping original T61 CPU power management SSDTs.

Trouble is it looks like this leaves the X3100 in a lower power state because some animations are still choppy, for example the desktop as it zooms in after startup.

Latest Chameleon 2.3 svn + FileNVRAM module fixes my nvram.plist issue. Also I suspect copying it to /Extra/Modules using cp -R this time may have something to do with it

I found a MacBook4,1 IOREG dump - as it turns out, the MacBook4,1 also has a "phantom display" outside of the GX0 device..! One step forward, two steps back..

Posted 27 January 2015 - 02:24 AM

Gringo Vermelho

The Jan Bird fix

Supervisors

6,224 posts

Gender:Male

Location:Brazil

Thank you, I'll dive into that as soon as I am done celebrating here

Lion only talks to 8-bit (and lower) EC registers. This is why a ton of DSDT patching has to be done in order to use Rehabman's ACPIbattery.kext. Luckily his repository has a patch for the Thinkpad X220 that only needs a tiny change (see my next post) to work on the T61 as well.

I found out how to use one of the calculation methods used by the X220 battery patch to fix ACPIMonitor.kext fan RPM reading on the T61. The HFN1 (fan RPM) EC register must be split into two separate 8-bit registers.

This is my favorite T61 discovery so far. Thanks to bcc9, Rehabman, THe KiNG, Sebinouse and Silencer for lighting the way.

/EDIT

Rehabman's X220 Battery patch will actually fix this too if you already have the fan control patch in your DSDT before applying the battery patch. lol I can see what this looks like, I'm not trying to take credit for this at all, I had applied the battery patch before discovering the fan control patch. Turns out I'm inventing things that were already discovered and documented by others long ago.

Posted 27 January 2015 - 03:00 AM

The X220 ACPIBattery patch splits the 16-bit HWAK into WAK0 and WAK1 but the patch is not fully applied due to HWAK being in _L18 instead of _L1D on the T61.

I verified everything else the best I could. The offset on the two 128-bit registers match, there are no _IRC or _PLD to replace and all the EC registers that get split by the patch are present in the T61 DSDT, except for SBBM.

Posted 08 February 2015 - 09:01 PM

I'd known about this patch for a while but I had only seen older pre-patched binaries for download and I was determined not to use drivers or anything else from Snow Leopard.

I didn't know until today that there was a patch available for Lion. It was very easy to apply the patch with 0xED.

Both slider and hotkeys work. Brightness drops a level when unplugging AC and goes back up when plugging in. I'd like to see if I can get a wider range but for now I'm perfectly happy with what I've got.

This is with PNLF and LCD1234 added to DSDT, there's no 3rd party brightness driver installed.

Posted 14 February 2015 - 07:12 PM

The X220 ACPIBattery patch splits the 16-bit HWAK into WAK0 and WAK1 but the patch is not fully applied due to HWAK being in _L18 instead of _L1D on the T61.

I verified everything else the best I could. The offset on the two 128-bit registers match, there are no _IRC or _PLD to replace and all the EC registers that get split by the patch are present in the T61 DSDT, except for SBBM.

The T61 has brightness control methods hidden away in the attached SSDT table. It seems like everything is there, but I don't understand what's missing for it to work.

I tried moving it into DSDT under the PNLF device like I've seen others do but I couldn't figure it out how to do that properly.

I did something right; once I moved PNLF into the same scope as VID0, ACPIBacklight started complaining about about invalid data in the BQC method, I guess this means that ACPIBacklight can see the SSDT table at least.

I'm surprised that I haven't found any examples of anyone using that SSDT anywhere. All I see are patched X3100 framebuffer kexts.

Some related information I've collected that I'm not smart enough to know what to do with.

Posted 15 February 2015 - 03:11 PM

Thanks for stopping by and sorry about spamming your blog, I didn't know how else to contact you. I assumed your inbox here would be full..

(\_GPE) or (_GPE) ? I didn't even notice that. I don't know why that has changed in my patched DSDT. Maybe IASL does that? I know I didn't do it.

I added your code above and applied the patch to a fresh DSDT with MacIASL, it looks good to go, no compiler errors and everything is in the right place.

Thanks for the confirmation. I'll commit the changes into the repo.

Another thing while you are here, I've been meaning to ask you if there's a way to make ACPIBacklight.kext work with this:T61_Backlight_SSDT.dsl.zip

The T61 has brightness control methods hidden away in the attached SSDT table. It seems like everything is there, but I don't understand what's missing for it to work.

Generally, we ignore the OEM brightness methods and simply replace them with "Brightness Fix (Haswell)" or "Brightness Fix (HD3000/HD4000)". There is no need to move things around. Simply add PNLF to the SSDT with the GFX0 device. That's for hardware as old as 1st gen Intel HD (Arrandale). Not sure about really old hardware (such as X3100).