News, Discoveries, and Comments

So, I get my Latitude D830 to a place I'm really happy with and this inspires me to dive into my E520's DSDT. Well, unfortunately, it is not nearly as happy a place as the D830's DSDT. The E520/XPS410's DSDT is a pathetic showing that really disappoints me. Anyway, running into that broke my momentum of looking into hack stuff and brought me back to things in the real world. However, there are some things I would like to share.

Intel 965 Drivers

Netkas announced some great news on October 8th! The 10.6.2 beta contains 64bit drivers for Intel's IGPs, which means the X3000 and X3500 should have 64bit support soon. Now, I have not seen the driver yet which means that I can't make any guarantees. The relationship with the framebuffer is finicky enough that it may cause problems. I got the 32bit framebuffer to work, but you can't mix and match. It will be all or nothing. I'm in no rush to make a 64bit version for a couple reasons. One, I hear that the beta drivers are rather buggy. Two, I use a discrete card for normal operation.

Another thing I want to mention on this topic came to me when I was reading recent comments to a previous post. I've said this on various forums, but not yet on my blog and it is a good thing to discuss. I am not aware of any way in which the X4500(M)(HD) chipset could even theoretically work with X3100 drivers. Yes, I'm aware that people have got the X3100 framebuffer to work... but that is entirely different. Early on, I looked into getting the X4500 to work with the X3100 and I worked with others on the IRC who were attempting the same thing. I'd like to see it working. However, it soon became apparent that the architectures are just too different. Just reading the wikipedia article about GMA will explain that. However, there is another logical argument why it won't work. Apple doesn't have a history of packing multiple architectures into the same kext like Intel (Windows) does with the same driver package. You have GMA915/950 kexts (essentially the same architecture), GMA965, but nothing about X4500 anywhere. If X4500 functionality was added to X3100 kexts it would be completely uncharacteristic of Apple. The only hope for X4500 drivers, which basically isn't even a chance in hell, is for the nVidia/Intel lawsuit to force Apple into switching back to GMA. But, even if that did happen Apple would want a new IGP instead of the X4500. They already showed that it is a gutless wonder, even Steve would have a hard time selling that switch.

STAC9227 Audio

Ok, I'll admit it, Viki's legacy kext for STAC9205 on the D830 spoiled me. I like the idea of full functionality using Apple's own drivers. However, I've had a devil of a time trying to get STAC9227 to work the same way. I started by reading THe KiNG's guide and then solidified my understanding of those principals by reading Master Chief's guide, basically saying the same thing differently. The catch is that neither of them really go into pathmaps or layouts. I'm pretty confident I figured it out and created a correct pathmap and layout, but it isn't working. The reason why I think I created a valid pathmap and layout is because if I use otherwise working ones in the same kext I get the same errors. My guess is that the problem has to do with codec support, and therefore hex editing. I have no problem with that, but it isn't very "legacy." MacGirl created some legacy kexts for the 9228, which isn't a native codec either, but I can't seem to get the same type of modifications to work for the 9227. The odd thing? STAC9205 isn't natively supported either, yet it works without hex editing. I don't know, if somebody smarter than I could explain that to me I'm probably a few minutes away from providing a nice legacy kext for the E520/XPS410 - and I wasn't able to find one currently available.

I was hoping to have the legacy kext ready for a move to Snow Leopard, but being I wasn't able to figure it out I looked into VoodooHDA instead. I've used it before, but I thought that the project was largely stagnate these days. Not true. The famed Slice has adopted the project and made many recent developments. I have no complaints at the moment, though I'm not viewing it as a permanent solution yet. Many people are posting much higher functionality with this newer version. Some may already have been aware of this, but since I didn't know I thought I'd pass it along.

Also, a later post will outline my instructions for creating pathmaps and layouts. It may not be perfect, but I'm confident my understanding is functional. Being that I wasn't able to find any comprehensive guide to that part of the AppleHDA patching process, think of it as an appendage to THe KiNG's or Master Chief's guides until they post their own.

E520 Update

Currently I've modded the DSDT to enable my graphics card, correct the USB issue, show all devices, enable custom P-States, load vanilla AppleLPC, and load vanilla AHCI/ATA. However, I haven't been able to get C-States working... story of my life lately. For those of you that have the boot1h error, that is a problem with Chameleon. I talked to Kabyl about it and he said that it is likely a change introduced by RC1 in disk.c or sys.c. I compared the code of RC1-3 to 1.0.11 and I haven't been able to figure out where it is. I've sold applications I've written before, but that doesn't make me a professional coder :) I guess I'm just missing the change, I don't know. Maybe one of you is smarter than I and can figure it out. In the mean time I'm using an old 32MB flash drive I had laying around to boot Chameleon, and therefore launch OS X with the AHCI enabled.

D830 Update

Well, I think I've only got two things left to implement on this baby - then it will be as perfect if Apple made it themselves :) One would be C-States (see below). And the other would be shutdown/restart/hibernate. I'm curious as to whether graphics power management could have something to do with that, being that it happens once hardware acceleration is enabled, but I'm not sure that Apple's graphics power management kext applies to the 8 series GPUs (which the 140M is). Anyway, the thing is rockin'! It's Geekbench scores are higher than those of MacBook Pro's of comparable hardware!