Hi Roderick. I've just found your project and I'm glad to know that someone is still working in a fork of rEFIt, thanks for your work!
rEFIt has a problem already discussed about the brightness control in Windows 7. I don't know if it has to be with a few mac model versions or if it's a Windows 7 stuff.
I've tested on Intel Mac Book Pro (alu 2010) and Intel iMac 27 (2012), both with Lion and Mountain Lion (and first one also with Leopard and Snow Leopard).
The problem: If you use the EFI manager to launch Windows 7 brightness buttons will show up the overlayed icon and will recognize the increments, but nothing will change in screen. Also the default brightness is set to max.
This is a rEFIt related bug since everything works right if you bypass the EFI manager and use the Bootcamp manager to launch Windows.
After trying rEFInd I've noticed that the error occurs exactly the same in your fork.
Have you already researched this issue? It would be really nice if you can solve this.
Roderick W. Smith
I wasn't aware of this problem, and I'm afraid I have no means of testing it, since my only Intel-based Mac is an ancient 1st-generation Mac Mini and I don't have Windows installed on it. I did, however, turn up this discussion thread:
There are at least three solutions described in it (on page 8, to which I've linked, and on page 9), but of course I can't guarantee that any of these will work for you:
I hope one of these suggestions will help. (I recommend trying them in the order I've presented them, since these involve increasing levels of change and, therefore, risk.) If they don't help, perhaps you'll find other suggestions in that thread -- it's 9 pages long, so I haven't read it all! A Web search on terms like "rEFIt Windows brightness" might turn up more such suggestions.
Thanks a lot for your support Roderick. I'm gonna follow your suggestions and I'll write back here when I'm done.
I'm back again. I've tried every suggestion but no luck.
Reading the forum I realized that I had already read before. Thanks to it I could see the connection between the problem and rEFIt. In fact most of the answers point rEFIt as the cause and the solution (by removing it) of the problem.
Is important to remember that it works right with the default bootcamp startup. It's not a hardware/firmware/software updates issue, It has to be with the way the system opens, or BIOS is emulated, drivers are charged... I don't know
For now if I use rEFInd, my only option to keep my eyes away from burning in hell is to use the ATI control manager to bring down the brightness value (different than system one), but to lose the functionality of F1 and F2 buttons is not an option, not better than losing the nice rEFInd startup manager.
Thanks anyway and I hope one day this will be fixed, maybe Windows 8 fixes the problem, I'll give a try.
Roderick W. Smith
I'm sorry to hear those suggestions didn't help. My only other suggestion at this point is to investigate the mm command in the EFI shell (as referenced here, for instance). You can manually set hardware registers with this command, and that might enable the video hardware to work; however, you'll have to know which registers to set, and that will require more research on your part.
If you can figure out what needs to be set, you could create an EFI script to do the job and include it in your boot process or manually launch it via rEFInd before launching Windows. In the medium term I could include a feature in rEFInd to set such registers via the rEFInd configuration file.
Hi Roderick. I've been reading about the mm command and the EFI shell and also I've tested if Windows 8 has the same behavior. After purchasing and installing Win 8 Pro I've confirmed that the error persists. At least we can say its not an isolated problem of Windows 7. Another interesting thing I've read from your last link is that the same problem happens when booting in native EFI mode (there are a couple of posts reporting the brightness problem having installed Windows in EFI mode natively, not by Bootcamp).
There's something I don't get about how rEFInd works. Please, explain me what I'm missing.
OSX boots in EFI mode so it should exist a GPT on the disk. I've checked the boot mode of Windows and either by Bootcamp and rEFInd, it boots in BIOS mode, so I guess it's also a MBR (or PMBR).
If rEFInd doesn't have a boot loader but instead uses the native ones, I guess the process consists in blessing the EFI folder to give rEFInd the control of the boot sequence. Then If you choose to start OSX, rEFInd will point the system to the native EFI bootloader, and choosing Windows, the same "native" Bootcamp BIOS emulation will fire so, how can differences exists between the same boot process (the one I get using the default startup manager or rEFInd)?
And on the other hand, how could I use a command in the EFI shell if Windows is booting in BIOS mode?
Anyway, I've been reading about the mm command and its syntax. There's not as much documentation as I expected (or I haven't been able to find it).
All I know is the base syntax I have to use, that I think it is:
mm BBDDRRRR V
Where BB = Bus, DD = Device, RRRR = Register and V = Value. Is it right?
I have also read about the pci command to detect this kind of devices and its bus based on the order of appearance. Assuming I get the graphic card detected, where can I found the equivalents of the registers and the values I should give them?
The truth is I'm new in the world of EFI. I'm a programmer and hope I'm not totally lost, but some help would be appreciated.
Finally I want to thank sincerely your help and interest.
Roderick W. Smith
Javi, your summary of the boot process is basically correct. As to how there can be a difference between the way the Mac's firmware boots something when you hit Option during boot and the way rEFInd does, I can only speculate, but my speculation is that the firmware sets hardware registers or otherwise does something different than what rEFInd does. I realize that's a vague answer, but it's the only one I've got -- without seeing Apple's proprietary code, I can't really be even remotely specific about it. (Note that there is public documentation and sample code for booting BIOS/legacy OSes on UEFI-based PCs, but this process is very different from the Mac process, and it doesn't work on Macs.)
As to the mm and pci commands, I also can't provide specific suggestions for what might work. That information will necessarily be very hardware-specific and I've not studied it in detail. You might find something on Mac forums. Broadly speaking, though, you could use those commands in an EFI shell before launching a BIOS/legacy boot loader, and with any luck whatever register changes you make will carry over into the BIOS-mode boot.
Sorry I can't provide you with better answers or solutions on this.
OK Roderick, I will research and try.
Thanks for your help, If I find an answer I'll post here.
Mmm, I also had random problems with refit and brightness control in the past.
Now that I use recent refind versions (0.4+), I never seem to have any more trouble.
OS: win7 64bit in BIOS mode, booted via refind. Bootcamp 3.3 drivers installed. MBPRo 8.2 with latest mac firmware update installed...
Roderick W. Smith
I don't recall making any changes to rEFInd's code for booting BIOS-mode OSes on Macs, so it's puzzling that rEFInd would work any differently than rEFIt on this score. (Note that rEFInd does add BIOS-booting support for UEFI-based PCs, but that's entirely separate from the Mac support.) I suppose it's conceivable that some subtle change to the way rEFInd initializes the system might have caused a difference to manifest itself, though. It's at least as likely that an updated Windows driver would have caused the problem to disappear.
Joe van Tunen
The EFI device GUID specified in the nvram parameter "efi-boot-device" when you select a Windows partition in the Startup Manager tells the Mac's EFI to use the Legacy Loader. It matches the LegacyLoaderMediaPathData in rEFInd. Is the legacy loader that rEFInd uses (ExtractLegacyLoaderPaths, StartEFIImageList) different than the one the Mac's firmware uses? This would be possible only if there was more than one to choose from.
rEFInd does have some hard coded paths for some Macs (LegacyLoaderList), but it only tries those if it failed to load a legacy loader that it did find. If there were different loaders in the same firmware then one could handle the brightness control differently than another.