Dell XPS 1340 mostly working with OSX 10.5.6,10.5.7

[bcc9]

because everest is reporting the values correctly....................When i press the battery button after some seconds I get NO LED now...when everest reported 25% wear level it was 1 Led, that is perfectly obvious......5 leds each led = 20% when I had 25% it was 1 LED now that i have 13% its 0 LEDS...everest is reporting the correct info extracted from the battery chip.........my battery is simply {censored}ed up! lol

54135 mWh is 86.2% of 62837 mWh so you're down 13.8% with wear. So if everest is reporting 25% wear, or reporting that the wear level is getting better (less), then that's some funny math or confusing definition of wear. So I'd still discount what everest is claiming.

13.8% wear may be reasonable if you're daily discharging&recharging your battery. Last laptop warranty I looked at explicitly didn't cover normal battery wear so good luck with dell

 

Back on topic... I think you had some kextunloading panic you were going to look into...

[pmcnano]

Eh, everest is reporting 13% now...os its fine what its reporting....

 

Back on topic, yea im having a kextunload panic, I tried unloading VoodooPS2Trackpad kext and it panniced, it happened after I tried this new VoodooPS2 kexts (that btw work fine..no problems with keys you can try em..) Its in their forums...a random user updated them

[bcc9]

beware, netkas pcefi V10 wont let me boot Leopard......

I just tried pciefi v10 and it worked fine on my 1340. You do have to have a DSDT.aml installed.

One benefit of pciefiv10 over the chameleon beta under 10.5.x is that pciefiv10 fixes the "ERROR: FireWire unable to determine security-mode; defaulting to full-secure" problem from the chameleon beta. This error reportedly leads to firewire performance issues, per: http://forum.voodooprojects.org/index.php/topic,200.0.html

[ErnestBursa]

Hello,

I have read old thread (11 pages) and now I know that audio wasnt working correctly. Did something changed in these time? How about 9500?

 

Thanks You in advantage,

Best regards,

Ernest

[Gambit642]

NEW FIX!!!

Working Tilda (the "~" key the the right of the number "1").

 

Had some time; got my hands on the source for VoodooPS2Controller.kext; fixed the key-mapping.

 

This fix is for the users that are using and have "properly installed" VoodooPS2Controller v0.98

(Which meant also deleting ApplePS2Nub.kext and ApplePS2Controller.kext both located in /System/Library/Extensions):

 

instructions:

Download the Patched VoodooPS2Keyboard.kext below:

 

Delete:

/System/Library/Extensions/VoodooPS2Controller.kext/Contents/PlugIns/VoodooPS2Keyboard.kext

(Only delete the VoodooPS2Keyboard.kext plug-in, leave the others)

 

Use OSX86Tools to install the patched VoodooPS2Keyboard.kext in to the Extensions folder (its not a VoodooPS2Controller.kext plug-in, it's a standalone driver).

 

Use OSX86Tools to clear your extension cache, and reboot.

Enjoy.

 

Keyboard fail after sleep is inherent to the Voodoo driver so it is still an issue.

You can use InsomniaX to keep your machine from sleeping as a work around.

Studio_13_Patched_Tilda_v1.0.dmg

[bcc9]

NEW FIX!!!

Working Tilda (the "~" key the the right of the number "1").

Sounds great, I'll have to try it. Can you post your source code changes so I can see what the problem was?

Keyboard fail after sleep is inherent to the Voodoo driver so it is still an issue.

You can use InsomniaX to keep your machine from sleeping as a work around.

If voodoops2controller still breaks after sleep, and cannot be reloaded with kextunload/kextload like the old ApplePS2Trackpad kext can, then I'd rather have working sleep than trackpad gestures. Wait, I just tried it myself and VoodooPS2Trackpad.kext unload&reloads no problem. Just need to stick the trackpad reload in /etc/rc.wakeup. Beats disabling sleep for sure.

[bcc9]

So I just installed snow leopard beta on my laptop and I can confirm that the atheros ar9280/5009 802.11 wireless is working.

 

Hello,

I have read old thread (11 pages) and now I know that audio wasnt working correctly. Did something changed in these time? How about 9500?

I think I covered these concerns in post #1. Is there something I need to clarify?

[bcc9]

So I have found that voodoops2 still *will* panic the system but it depends upon the timing of the kextunload/kextload commands. Currently it is working for me with a sleep of 1 between the two operations. Here are what my /etc/rc.sleep & /etc/rc.wakeup scripts currently look like, for use with sleepwatcher.

 

Note that I've switched over to the newer kext installation scheme, supported by chameleon, of placing modified kexts into /Extra/Extensions, so my script reflects that. Update the paths in the script if your install differs.

 

[update: voodoops2 unloading no longer necessary with my touchpad fix; script updated accordingly. Script moved to post #1.]

[Gambit642]

Sounds great, I'll have to try it. Can you post your source code changes so I can see what the problem was?

Sure, I followed a tutorial by Macgirl for a related but different issue using:

VoodooPS2Controller v0.98 - Source Code

 

Offending code was in ApplePS2ToADBMap.h, the header which controls keyboard input-to-ASCII mappings.

 

I wasn't quite sure how to compile as a plugin, so I did a generic driver build, but you have to blow out the plugin in the original VoodooPS2Controller v0.98 distro.

 

FYI, the VoodooPS2Trackpad.kext source is in there too.

 

Swapped Tilda with an unused key

 

Before

0xa0,  // 29  `~
        0x38,  // 2a  Left Shift
        0x2a,  // 2b  \|
        0x06,  // 2c  Z
        0x07,  // 2d  X
        0x08,  // 2e  C
        0x09,  // 2f  V
        0x0b,  // 30  B
        0x2d,  // 31  N
        0x2e,  // 32  M
        0x2b,  // 33  ,<
        0x2f,  // 34  .>
        0x2c,  // 35  /?
        0x3c,  // 36  Right Shift
        0x43,  // 37  Keypad *
        0x3a,  // 38  Left Alt
        0x31,  // 39  Space
        0x39,  // 3a  Caps Lock
        0x7a,  // 3b  F1
        0x78,  // 3c  F2
        0x63,  // 3d  F3
        0x76,  // 3e  F4
        0x60,  // 3f  F5
        0x61,  // 40  F6
        0x62,  // 41  F7
        0x64,  // 42  F8
        0x65,  // 43  F9
        0x6d,  // 44  F10
        0x47,  // 45  Num Lock
        0x6b,  // 46  Scroll Lock
        0x59,  // 47  Keypad Home
        0x5b,  // 48  Keypad Up
        0x5c,  // 49  Keypad PgUp
        0x4e,  // 4a  Keypad -
        0x56,  // 4b  Keypad Left
        0x57,  // 4c  Keypad 5
        0x58,  // 4d  Keypad Right
        0x45,  // 4e  Keypad +
        0x53,  // 4f  Keypad End
        0x54,  // 50  Keypad Down
        0x55,  // 51  Keypad PgDn
        0x52,  // 52  Keypad Insert
        0x41,  // 53  Keypad Del
        0x44,  // 54  SysReq / Custom Calc
        0x46,  // 55 Custom Logout
        0x32,  // 56 º\ª (Spanish)

 

After:

0x32,  // 29  `~
         0x38,  // 2a  Left Shift
         0x2a,  // 2b  \|
         0x06,  // 2c  Z
         0x07,  // 2d  X
         0x08,  // 2e  C
         0x09,  // 2f  V
         0x0b,  // 30  B
         0x2d,  // 31  N
         0x2e,  // 32  M
         0x2b,  // 33  ,<
         0x2f,  // 34  .>
         0x2c,  // 35  /?
         0x3c,  // 36  Right Shift
         0x43,  // 37  Keypad *
         0x3a,  // 38  Left Alt
         0x31,  // 39  Space
         0x39,  // 3a  Caps Lock
         0x7a,  // 3b  F1
         0x78,  // 3c  F2
         0x63,  // 3d  F3
         0x76,  // 3e  F4
         0x60,  // 3f  F5
         0x61,  // 40  F6
         0x62,  // 41  F7
         0x64,  // 42  F8
         0x65,  // 43  F9
         0x6d,  // 44  F10
         0x47,  // 45  Num Lock
         0x6b,  // 46  Scroll Lock
         0x59,  // 47  Keypad Home
         0x5b,  // 48  Keypad Up
         0x5c,  // 49  Keypad PgUp
         0x4e,  // 4a  Keypad -
         0x56,  // 4b  Keypad Left
         0x57,  // 4c  Keypad 5
         0x58,  // 4d  Keypad Right
         0x45,  // 4e  Keypad +
         0x53,  // 4f  Keypad End
         0x54,  // 50  Keypad Down
         0x55,  // 51  Keypad PgDn
         0x52,  // 52  Keypad Insert
         0x41,  // 53  Keypad Del
         0x44,  // 54  SysReq / Custom Calc
         0x46,  // 55 Custom Logout
         0x0a,  // 56 º\ª (Spanish)

 

Just inverted 0x0a & 0x32. You can drop the fix in the first post.

 

VoodooPS2Trackpad.kext unload&reloads no problem.

Yes, the entire driver was not failing, just the trackpad plugin. In fact Keyboard and external USB mouse continued to work after sleep, even before any sleep fix.

I'll give your solution a try so I can boot InsomniaX. Also, I mentioned above, the trackpad source is available, might be able to work out a driver level solution with that.

[bcc9]

Other problems with voodoops2 on this system include:

Lots of "Unknown extended scan code" errors logged in /var/log/system.log. Most any special key causes this including home, pg up/down, arrow keys.

 

As with the older keyboard drivers, we still don't have proper ps2 keyboard bindings (modifier keys for mac command/option map wrong).

 

And damn, most importantly, I'm still having panic problems so it looks like I'm back to good old appleacpips2nub&appleps2controller.

[Gambit642]

Other problems with voodoops2 on this system include:

Lots of "Unknown extended scan code" errors logged in /var/log/system.log. Most any special key causes this including home, pg up/down, arrow keys.

 

As with the older keyboard drivers, we still don't have proper ps2 keyboard bindings (modifier keys for mac command/option map wrong).

 

And damn, most importantly, I'm still having panic problems so it looks like I'm back to good old appleacpips2nub&appleps2controller.

What would be sweet is a standalone TrackPad Driver; not a VoodooPS2Controller.kext plugins like it is currently (source which is included) working with the Vanilla Appleacpips2nub & ApplePS2Controller. Problem there is I have not worked with preference panes extensions, which allows you to manipulate the trackpad driver behavior. I noticed the logs entries (can prob be easily traced in the source). I stuck with Voodoo because I was happier with the trackpad capability over Vanilla.

[pmcnano]

bcc9, you have panics with voodoops2? But with normal use? Or when sleep/wake?

 

I had never have panics while normal use.....that would be strange...

[bcc9]

bcc9, you have panics with voodoops2? But with normal use? Or when sleep/wake?

The kernel panics are only with sleep/wake. Which is normal use for me :pirate2:

[Gambit642]

So I have found that voodoops2 still *will* panic the system but it depends upon the timing of the kextunload/kextload commands. Currently it is working for me with a sleep of 1 between the two operations. Here are what my /etc/rc.sleep & /etc/rc.wakeup scripts currently look like, for use with sleepwatcher.

 

Note that I've switched over to the newer kext installation scheme, supported by chameleon, of placing modified kexts into /Extra/Extensions, so my script reflects that. Update the paths in the script if your install differs.

We might be able to take the source of VoodooPS2Trackpad.kext plugin (Trackpad not the entre controller driver; which is the problem) along with "Kernel Debug Kit 10.5.7 build 9J61" available on the Apple Development Center site (yes you need at least a free developer account to DL) to trace and fix the logs (sould be able to trace the console-out routines in the source) and the panics (using the kernel debug kit) while compiling as a stand-alone driver (not a plugin, as I did for the Tilda fix). The ideal solution is a fixed 1340 driver, not a work around to a problematic/incompatible driver.

 

My only beef is I can't get Voodoo to panic. Is it happening only after sleep? I don't sleep.

[bcc9]

We might be able to take the source of VoodooPS2Trackpad.kext plugin (Trackpad not the entre controller driver; which is the problem) along with "Kernel Debug Kit 10.5.7 build 9J61" available on the Apple Development Center site (yes you need at least a free developer account to DL) to trace and fix the logs (sould be able to trace the console-out routines in the source) and the panics (using the kernel debug kit) while compiling as a stand-alone driver (not a plugin, as I did for the Tilda fix). The ideal solution is a fixed 1340 driver, not a work around to a problematic/incompatible driver.

 

My only beef is I can't get Voodoo to panic. Is it happening only after sleep? I don't sleep.

I don't think one should need to trace the logs from the kernel side to debug this. Should be pretty easy to debug from the driver code. Just discouraging that such basic functionality as scan codes and driver suspend aren't working right in voodoops2 which is used by so many...

 

If I'm going to roll up my sleeves with "voodoo" source, personally I'd rather focus on the HDA code, as I don't think the old 10.5.3 HDA driver is going to work with snow leopard.

 

The panics are with kextunload/kextload. "Does it unload properly?" is one of the criteria in the "Basic Quality Control" section of the I/O Kit device driver design guide

[pmcnano]

Yea, sleep/wake will make it panic....well not sleep wake..just manually unload and load it...it will panic..I think the first time it doesnt..but the second time will make it panic for sure!

[Gambit642]

I don't think one should need to trace the logs from the kernel side to debug this. Should be pretty easy to debug from the driver code...

We said the same thing, re-read my statement:

"and fix the logs (should be able to trace the console-out routines in the source)".

 

If I'm going to roll up my sleeves with "voodoo" source, personally I'd rather focus on the HDA code, as I don't think the old 10.5.3 HDA driver is going to work with snow leopard.

I'll give the Voodoo a shot; HDA is up to you, I got about free week for summer break from class. I have never debugged a kernel for a driver issue (on any OS) but I'll use my C++/PHP/JS/Java/General-OOP skizzils to try and figure it out. Mac driver debugging sounds like something I would want to try before leaving this earth (yea, right). Any feedback specific to driver debugging would be helpful.

 

The panics are with kextunload/kextload. "Does it unload properly?" is one of the criteria in the "Basic Quality Control" section of the I/O Kit device driver design guide

I have no idea what that means (Ref: "I have never debugged a kernel for a driver issue") in reference to the the BQC or how the I/O Kit's work but I will use your terms to hopefully path a solution. I hope your suspicion is well-advised. It will be my baseline for what I research while hunting the cause.

 

 

Anyone reading ever use any version of Apple's debugging kernel? Send me a PM if so.

 

I'm still in vote of fixing VoodooPS2 panic vs Vanilla PS2 simply because it sounds like Voodoo already has the working routines for full use of all the features (scrolling/tap/pg-up/pg-dwn/sensitivity/etc.) of the dell touchpad (being it was home-brewed specifically for the Dell TP), so its just finding the cause of the panic. My interpretation of Vanilla driver is that it doesn't have that same logic for a Synaptics TP

(I don't know if PowerBooks use Synaptics parts really), but it sounds like less work and a stronger fix.

Any rebuttals?

[bcc9]

Setting up a debugging kernel is not a pre-req for debugging a device driver. You can even remote gdb the driver without setting up a debugging kernel. That's part of what I did to figure out the AppleACPIPlatform bug.

[Gambit642]

Yea, sleep/wake will make it panic....well not sleep wake..just manually unload and load it...it will panic..I think the first time it doesnt..but the second time will make it panic for sure!

Yea, I for sure never done that. Once I realized my TP was dead after sleep, I disabled sleep. Consequently, I never have experienced a VoodooPS2 related panic.

 

Setting up a debugging kernel is not a pre-req for debugging a device driver. You can even remote gdb the driver without setting up a debugging kernel.

You got a ref for documentation on how to set that up? Keep in mind I only have one Hackint0sh. I am under the impression that remote debug requires another Leo box.

[bcc9]

You got a ref for documentation on how to set that up? Keep in mind I only have one Hackint0sh. I am under the impression that remote debug requires another Leo box.

You probably should sign up for a free developer apple ID & start reading the docs. I don't necessarily know the best documentation for remote kext debugging with gdb, but a starting point is:

http://developer.apple.com/documentation/d...eviceDriver.pdf

 

You'll need 1 other OSX machine besides the xps 1340 for remote gdb. Contrary to the docs, the controlling machine doesn't even need to be running the same version of OSX as the client.

 

Not that you necessarily even need gdb to debug the panic - it may be obvious from the source code what objects the driver is failing to release.

 

For extra credit you could just make VoodooPS2Trackpad respond to suspend/resume events appropriately, instead of leaving the touchpad hung Then we wouldn't care if the driver unloaded right or not.

 

For extra credit you could just make VoodooPS2Trackpad respond to suspend/resume events appropriately, instead of leaving the touchpad hung Then we wouldn't care if the driver unloaded right or not.

On this I couldn't resist and took a peek. I notice that the voodoo driver does a dumb IOSleep(1000) in setDevicePowerState(), assuming that the device will be back in 1 second after reset. In the linux driver, there is a comment that "Some devices (Synaptics) peform the reset before ACKing the reset command, and so it can take a long time before the ACK arrrives.", and so the code waits for up to 4 seconds for the ACK to arrive...

[bcc9]

So I rebuilt voodoop2trackpad with this sleep bumped from 1 to 4 seconds, and viola the trackpad works across sleep/resume, no kextunload/kextload required.

 

Edit: Here's a full VoodooPS2Controller kext that includes the above change and Gambit's fix for the tilde key.

I also turned off swapping of the alt&windows keys, this was a simple config variable that was on by default in VoodooPS2Keyboard's Info.plist. Doh.

VoodooPS2Controller.kext.zip

[Gambit642]

So I rebuilt voodoop2trackpad with this sleep bumped from 1 to 4 seconds, and viola the trackpad works across sleep/resume, no kextunload/kextload required.

 

Edit: Here's a full VoodooPS2Controller kext that includes the above change and Gambit's fix for the tilde key.

I also turned off swapping of the alt&windows keys, this was a simple config variable that was on by default in VoodooPS2Keyboard's Info.plist. Doh.

So you told the system to wait a lil longer for an Acknowledgment from the Trackpad after a power-state change...Booya!

 

Your prob. right, I could have spotted that without debugging if I had just looked at the source.

I also I handled the key ALT/Win-Key swapping through the OS; completely forgot about it and neglected a driver based solution. Nice touch-up.

 

HDA time? (Still don't know why we need a 10.5.6 driver when the old one sounds fine)

[pmcnano]

rawr..im ancious to try it!....Been so busy lately..that I just not only DONT help, I cant even try it...lol

[bcc9]

So you told the system to wait a lil longer for an Acknowledgment from the Trackpad after a power-state change...Booya!

Right, as is typical the harder part was figuring out what to change not actually making the change. A better fix would be to do more like the linux driver and only wait until the controller state change completes, not a fixed amount of time. But the 4s wait in the trackpad thread doesn't seem to slow down system wakeup at all.

Your prob. right, I could have spotted that without debugging if I had just looked at the source.

I also I handled the key ALT/Win-Key swapping through the OS; completely forgot about it and neglected a driver based solution. Nice touch-up.

Yes, I no longer care about the kextunload issue as this obviates the need for that. I was real surprised to see from the source that those modifier keys were being swapped by default as shipped. At least it was already made into a user option.

HDA time? (Still don't know why we need a 10.5.6 driver when the old one sounds fine)

voodoops2keyboard is still causing scancode errors for the arrow keys, etc., if you want to figure that out.

 

Under 10.5.6/7, the 10.5.3 HDA breaks shutdown (I know that can be worked around), has the speaker mute issue, and the built-in mic doesn't work. Under snow leopard, the 10.5.3 HDA either doesn't load or panics the system (at least for me so far). The 10.5.3 version also lacks 64 bit kernel support.

[Gambit642]

@Bcc9, I think your distro is problematic. You tried sleep, but did you try reboot?

 

I didn't get a panic but I got a looping COUT on boot "waiting for device" (I assume for the TP). When I tried reverting back to my Trackpad plug-in build, the entire VoodooPS2Controller.kext still failed to load and no non-USB inputs were allowed; this led me to believe that another plug-in or plist was causing the "waiting for device" on boot.

Anyway, this is what worked for me. I reverted to the original stock voodoo v0.98 and mixed in the Trackpad.kext plug-in which included my Tilda fix and your timeout adjustment and its all working. I didn't spend enough time for a definitive diagnosis but the only thing I didn't include was your ALT/Win-Key fix, I resolved this through the OS anyway:

(System Preferences->Mouse & Keyboard -> Modifier Keys ->[invert Control & Command])

back in February and forgot all about a driver related fix. The possible offender; but like I said, I didn't diagnose comprehensively, I just tested and it all seemed working.

 

So I kept all the original stock voodoo kext (not the recompiled stuff) and only blew-out and replaced our modified VoodooPS2Trackpad.kext in plugins and I got a booting/sleep/Tilda working solution.

 

Anyone else have trouble booting (not sleep/wake) with the previous fix?

My working solution is attached.

 

What worked for me; the Tilda Fix (Gambit) & Sleep/Wake Fix (Bcc9) working in a single driver w/plug-in solution is attached that the bottom of my post!

 

Under 10.5.6/7, the 10.5.3 HDA breaks shutdown...

I believe I recall reading somewhere that this was an unload issue on shutdown. Being that most stale drivers manifest a shutdown/sleep issue perhaps apple deprecated an old API call everyone was using to unload. Perhaps a general function/object alias solution could resolve all these stale driver power-state issues. Something like some logic for general legacy power-state compatibility .

 

rawr..im ancious to try it!....Been so busy lately..that I just not only DONT help, I cant even try it...lol

Lol, as long as there is progress....

VoodooPS2_1340_Fix_v2.dmg