[reader50]

Background

Up through 10.4.8 when you hit the Eject key, the optical drive ejected immediately. This is a nuisance for notebook users, because their Eject key is close to commonly-used keys, such as the Delete key.

So Apple "solved" the problem in 10.4.9 by making you press-and-hold the Eject key before it works. This is an excellent fix for the built-in keyboard on notebooks. To be considerate to all us desktop users, and to maintain user control, Apple provided a checkbox for this behavior in the Keyboard and Mouse Prefpane.

No wait, they didn't do anything of the sort. The delay was applied to ALL keyboards. Very annoying for those who don't need the feature. They even provided a Support Page about the problem, which doesn't provide any workaround to solve it.

Investigation

I'd been waiting for TinkerTool or Onyx to discover a way around it. Or for someone to release a patch to remove the delay. It's been over a year with no solution, so I went after the problem. It only took a day to track it down. It had to be one of the files contained in the 10.4.9 update, and most of those files could be ruled out.

Some file swapping among the updated Extensions and the problem file was found.

The Solution

The delay is created in the IOHIDFamily.kext driver.

./System/Library/Extensions/IOHIDFamily.kext

This is a bundle file, and it contains a number of subfiles & plugins which do not need to be touched. Replacing the entire kext worked during brief testing, but for safest results, you should replace only the exact binary file that creates the delay:

./System/Library/Extensions/IOHIDFamily.kext/Contents/MacOS/IOHIDFamily

Under PPC, this file was last updated in the 10.4.3 delta update (97 MB).
Under Intel, this file was last updated in the 10.4.8 delta update (206 MB).

You can use Pacifist or unpkg to obtain the desired file without having to install the update somewhere. If you have an older system folder around from 10.4.3 through 10.4.8 (PPC) or 10.4.8 (Intel), then you can grab the file from there and save a download.

1. Obtain a version of the file from before 10.4.9
2. Copy the IOHIDFamily.kext to somewhere safe, so you'll have an unmodified backup.
3. Replace the "IOHIDFamily" file inside the kext with the earlier version of the file.
4. Use Disk Utility to Repair Permissions on the volume in question. Depending on what user account you used for the hack, the replaced file may have ended up with unsuitable permissions.
5. Move some random file or folder into the Extensions directory to change it's modification date. Then remove the extra file or folder. You need to do this so OSX will realize the Extensions have been modified, and they need to be reloaded on boot instead of just using the kextcache.
6. Reboot.
7. The Eject key works immediately again. Most excellent.

This solution was tested in 10.4.11 PPC. I don't have an Intel Mac to test with, so someone will need to do some testing under x86.

Someone with Leopard will need to test this too. It may work; I'm still using the Jaguar Internet Prefpane under Tiger. On the other hand, Leopard introduced code signing. You may need to resign the kext before it will be accepted.

Be very careful testing this under Leopard. I recommend using an install on a separate partition.

If the code signing rejects this file, then the OS may not be usable, even with a safe boot. If that happened and you didn't have another partition to boot from, you'd need to Archive & Install. Or do some Time Machine magic to undo the hack and restore booting.

I poked around inside the binary file, looking for some plist text that sounded like a preference key. Something that could be set with a "defaults write" command in the Terminal. But nothing looked likely. It would be better if someone found such a key, this replace-the-file trick may not work in later versions of OS X.

[ibook_steve]

Sounds like a lot of (dangerous) work for a really minor issue. Hold the button and be patient. Big deal.

Steve

[Person Man]

Originally Posted by ibook_steve 

Sounds like a lot of (dangerous) work for a really minor issue. Hold the button and be patient. Big deal.

Steve

I agree.

Also, the code signing issue is not a big one right now, but it could become one.

According to developer documentation, Leopard is pretty lax about code signing, but as time goes on, it will be more and more integrated. More code will need to be signed, and at some point there may come a time where the operating system will check the signature of system files. Not just to see if it was signed or not, but who signed it. If that happens, then game over.

You can re-sign a modified Apple application. I provided detailed instructions on how to do this in this thread. But once it's been re-signed, it's no longer an Apple-signed item. Apple's signature has been replaced with your own. So, if Apple decides to implement a check like that, you could get (at the very least) a dialog box saying one of the system files has been tampered with or it might refuse to load the modified file.

But, there may be so many changes between Tiger and Leopard that replacing the file simply won't work. But if it does work, it's only a matter of time before either the files change enough that it breaks something serious, or Apple gets more strict about code signing.

[CharlesS]

I don't see why you'd to do anything like this for Leopard. The delay in Leopard is so short that I probably wouldn't even notice it if I didn't already know about it.

[reader50]

tsk tsk CharlesS, and I just added a plug for your product. The package-extraction links were supposed to be there, but I forgot them in the original writeup. In my defense, it was written around 2AM.

This mod isn't very dangerous under Tiger, just follow the instructions and you'll be fine. I haven't messed with Leopard yet, so no personal data on if code signing will come up. I gave a warning to be on the safe side.

As for why this hack exists, I dislike it when Apple removes functionality. My Eject key started acting like it was dead. YMMV - in my case, I found their change so annoying that I've remained below 10.4.9 all the way through today. Now I can finally update, and apply all the later security fixes.

I've edited the post to add the package-extraction link, and to add the Tiger-Intel info. Hopefully, this will help other people who want their Macs to act like they used to.

[ghporter]

Since I seldom leave anything in the drive anyway, the delay is not a big issue for me. But I would like to have that checkbox back anyway, just because.

By the way, I STILL hit the eject button on my iMac keyboard when I'm aiming toward the delete key...so it really doesn't matter for old fumble-fingered me.

[olePigeon]

Would using an older IOHIDFamily file mess up using the newer keyboards where they rearranged (why?!) the FKey functions?

[Big Mac]

The delay is less than two seconds on my G5 in Leopard. I agree - non-issue.

[CharlesS]

Originally Posted by reader50 

tsk tsk CharlesS, and I just added a plug for your product.

hehe

The package-extraction links were supposed to be there, but I forgot them in the original writeup. In my defense, it was written around 2AM.

This mod isn't very dangerous under Tiger, just follow the instructions and you'll be fine.

I imagine so. I could see someone doing this on Tiger, because the delay was a bit annoying there. It's a non-issue on Leopard, though.

I haven't messed with Leopard yet, so no personal data on if code signing will come up. I gave a warning to be on the safe side.

That's another reason I probably would leave it alone on Leopard.

Originally Posted by Big Mac 

The delay is less than two seconds on my G5 in Leopard. I agree - non-issue.

Two seconds? Huh. On my MacBook Pro, it's a lot shorter than that - less than half a second, in fact. It's barely noticeable at all.

[reader50]

Some digging around on the open-source Darwin site reveals that the file we're hacking is included. If the file swap causes any problems, then you can build the latest version of the kext from source, after eliminating the delay.

Anyone can obtain the source from here. Choose your version and architecture. Pick out the IOHIDFamily project from the resulting list.

It's hardcoded to 250 miliseconds in several places. Make sure you only adjust the general delay - the file also codes a delay for the F12 eject function (if enabled), which should retain the delay. Otherwise, you may block access to Dashboard functions.

If I run into any issues with the swapped file under Tiger, I'll investigate further and provide instructions on how to compile a later version.

[billds]

Thank you! I'm a patient person, but having to train myself to treat the eject key differently was really annoying, especially when it wasn't necessary on a desktop keyboard.

[Eriamjh]

I use CMD-OPT-EJECT for instant sleep. I hated the delay when they added it. I had to hold the 3 keys for 2 or more seconds not the instant "bip" and run.

However, somewhere around 10.4.10 or 11 they eliminated the delay when used in combination with other keys. I'm happy again. i don't mind the eject delay otherwise.

[billds]

I tried the file swap in 10.5.6 (on a separate volume of course). No joy. The boot process never got past the initial screen. The spinner just spun and spun...

Some say it's a non-issue. I say it's a behavioral annoyance. If someone learns and shares how to change this in Leopard, I for one would appreciate it.

[billds]

Just found the solution to the Eject Key Delay in Leopard.
It's a little one trick pony by Takayama Fumihiko, and you can d/l it here:

http://www.pqrs.org/tekezo/macosx/ke...jectdelay.html

[vuulf]

OK, so this is a rather old post, but I figured I would post anyway. The 'fix' doesn't actually need any software to fix, just the end user getting used to doing a two step keystroke vs. simply hitting the eject key. I am not sure about Tiger, but on Leopard you simply have to hit 'Option+Eject' and your drive instantly pops in/out.

[billds]

On Mac's with multiple drives (like mine), option-eject opens/closes the alternate drive, which is great... unless you're trying to work with a disc in the primary drive.

[vuulf]

And which drive would the standard-eject key eject?

[billds]

The eject key without the option modifier key opens/closes the primary removable media drive of course, but only after holding it down for a short delay, unless one uses a solution like NoEjectDelay.