I used to get KPs frequently with Leopard. I thought it was the powered USB hub... then I looked through these forums, and then looked at the backtrace more carefully and saw DoubleCommand... :-/
Since updating from 10.5.1 to 10.5.2, though, I haven't noticed any KPs. I've been KP-free for 3 weeks now (knock on wood). Maybe 10.5.2 solved the problem?
I'm using DoubleCommand 1.6.5. (By the way, how can I check what version of DoubleCommand I'm running? I only know from looking at the backtrace.)
Get info on /Library/PreferencePanes/DoubleCommandPreferences.prefPane and you'll see the version. Glad to hear you're not getting panics anymore.
Spoke way too soon. I'm trying to apply a bunch of updates (including the keyboard firmware update) and I'm getting KPs again. Not only that, I got the black screen of death when trying to apply the keyboard firmware update. Guess I'll uninstall DoubleCommand for now. :(
Just an update -- I'm using 1.6.6b1 with the latest /Library/StartupItems/DoubleCommand file that's in subversion. No more KPs, everything is hunky-dory. Thanks Michael. :)
I use DoubleCommand (1.6.6b1 - with the updated Startup-Script) with my external Logitech diNovo Laser keyboard with Leopard 10.5.2 on a Feb. 2008 MacBook Pro.
I works great and I have no problems. Had that startup problem, but the new script from subversion resolved that. I just copied the code of the script out of the SVN webview and pastet that new code into the old script - restart - and everything was OK. No need to change permissions and such things.
Thanks for your work on that great little app.
Wow. Must be nice to have a working version of DoubleCommand... :) Would anyone be kind enough to package the mentioned changes together for the not-so-SVN-savvy users among us? Thanks!
I've taken the liberty of packaging a new build, incorporating the latest changes by Michael, for convenience:
Let me know if there are any problems.
Thanks for responding to this, I'm glad this build was able to help people out. I've just posted a new beta 1.6.6b3 which includes this and a potential fix for the issue where the Control key gets stuck on as well. Please try this out if you can and post back results.
One comment though, the change that was made was only to the loading script, not the kext, and so is not likely to solve kernel panic issues - however it does make the auto disable feature work, which might mean that DoubleCommand is still crashing once and then successfully disabling itself. Have those who report no more panics checked that it is still working?
I installed 1.6.6b3 over top of 1.6.6b1 (which was working fine for me). I have a MacbookPro that still has the enter key (not the newer "option" ones), and I use the "map enter to ctrl" option. With b3, it doesn't register as enter, so the kext is loaded and doing something, but it also doesn't act as "ctrl". It's basically a dead key. I reverted back to b1 for now; I'll troubleshoot tonight if necessary (gotta work for now <g>)
I'm experiencing troubles since I've installed DoubleCommand: when I request my MacBook Pro (Intel) to shut down, it almost powers off, just the fan keeps to spin slowly, and if I close the lid the front led lights up. I have to force power off by holding the power button, and next time I boot Leopard it says something about an improper shutdown.
I've not still tried 1.6.6b2 version above
I have exactly the same problem with my MacBook Pro. I use DoubleCommand to remap Enter (near space) to Option key. I use latest (1.6.6b3) version of DC. I'll post the trace next time I reboot. Will you be able to fix that soon?
So far no panics for me firstname.lastname@example.org but...
When I let Caps Lock act as Delete, not only does it generate a delete event, it also still acts as Caps Lock.
This means that a character is deleted, the light turns on and the next character(s) are in uppercase until another Caps Lock/Delete event is sent.
Also I would like to request an additional feature concerning a possible fix for the problem. It would be real cool if Fn-Caps *does* raise a Caps Lock event (and no Delete) when set to act as delete - giving the ability to keep using Caps Lock. The alternative seems to make Fn-Caps do forward-delete, but this is not the current situation either.
Log in to post a comment.
Sign up for the SourceForge newsletter:
You seem to have CSS turned off.
Please don't fill out this field.