ertepechis Posted July 30, 2010 Share Posted July 30, 2010 Question: Has anyone tried Chameleon RC5? i was just looking at that a few minutes ago, but its too beta for me, ill try it in a few days Link to comment Share on other sites More sharing options...
ANARCHiNTOSH Posted July 30, 2010 Author Share Posted July 30, 2010 Continuing on with that train of thought.... Now forget the MS/Logitech analogy...Refer to the screen shots I have earlier in the thread and look at the highlighted sections. To me it appears as if the OS is in fact sensing a dual-display, but it is under the impression that the second port is ADC (Apple Display Connector) rather then VGA. When the bootloader senses this with the graphics_enable function it merely fails and the VGA port does not power on. With an EFI string though, the bootloader is not sensing the actual hardware, you are telling the boot loader this is EXACTLY the hardware I have. So when it tries to use that ADC port, boom, instant KP. Now if we are able to modify that EFI string (probably easiest in plist form, and again refer to earlier highlighted screen shots) and to tell the boot loader the CORRECT port designations then MAYBE this will all work. Sidenote: As far as system recovery, you are very much correct. I was just in a rush and didn't prep a drive. Very stupid especially since I didn't think about having a distro burned. Luckily I did find an old 10.5 lying around and was able to use terminal to restore my old plist. As always, let me stress this is all just theory on my part. I am no programmer, just trying to look logically at the problem. thats an interesting theory, but i know a few things about graphicsenabler that ill share. when efi-emulation was invented by the osx86 project, efistrings first became availiable to use. the creator of NVEnabler (i think it was Fassl) saw the potential for making an enabler that used efi injection to modify the registry instead of having a kext plug the data into the registry. this is cleaner, more vanilla, gives better performance etc i am under the impression that the procedure of graphicsenabler, when booting, is to detect stuff about the card (first the device-address, then if its ATI or nVidia, then the vram size etc, i dont know how it does this, but it might be something to do with reading the cards boot rom or vbios), prepare a plist from these detected values, convert the plist from xml to hex, inject it as a device-properties entry in the boot process. its a very intelligent patch, but unless im mistaken i think its too closely tied to generating an efistring to act so differently and dynamic as you think..... why i thought it was succeeding over static efistrings was not because it acted in a more dynamic way, but because graphicsenabler had wider powers that werent to do with individual injected efistring values - what about its injection of a rom, its power to mess with pci stuff (pciroot?) and other such things.... My thinking is this...perhaps graphics_enabler has more flexibility as far as erroring out to the bootloader. As I figure it graphics_enabler is like an auto-detect/plug and pray type thing. Even though the data being returned to the bootloader is wrong, there is enough fault tolerance for the 1 screen to boot. I understand what you are saying, but i have had experience with efistrings (for gtx295) which at one time only made one screen work, the other didnt work, but it was later possible to add support for dual monitors..... theres nothing different about efistrings that makes them less fault tolerant (sorry im not trying to partisan support for efistrings).... what about the boot text? old pci command - 7 boot display - 1 Not going to use bios image file Found bios image Adding binimage to the card 954f from legacy space with size 10000 maybe i am misunderstanding what you intended to say, whilst simultaneously saying something similiar...... what i think ill try next is videoing the boot text when booting verbose, as before i only video'd it in non verbose mode. perhaps this might tell us something else. er, but yeah, you're both right, trial and error isnt a very efficient method of getting it to work.... @ertepechis regarding the problem where you cant even get to bootloader, i had that when i was trying to make an efistring before i even made this topic. i solved it by deleting or changing one of the plist entries, however, im not sure that it was a proper fix. ill try and find out how i did it, ive got a bunch of experimental efistring plists that i made, ill try loading them and seeing which ones let me past the boot screen..... Chameleon RC5 does look interesting...... Link to comment Share on other sites More sharing options...
ertepechis Posted July 30, 2010 Share Posted July 30, 2010 thats an interesting theory, but i know a few things about graphicsenabler that ill share. when efi-emulation was invented by the osx86 project, efistrings first became availiable to use. the creator of NVEnabler (i think it was Fassl) saw the potential for making an enabler that used efi injection to modify the registry instead of having a kext plug the data into the registry. this is cleaner, more vanilla, gives better performance etc i am under the impression that the procedure of graphicsenabler, when booting, is to detect stuff about the card (first the device-address, then if its ATI or nVidia, then the vram size etc, i dont know how it does this, but it might be something to do with reading the cards boot rom or vbios), prepare a plist from these detected values, convert the plist from xml to hex, inject it as a device-properties entry in the boot process. its a very intelligent patch, but unless im mistaken i think its too closely tied to generating an efistring to act so differently and dynamic as you think..... why i thought it was succeeding over static efistrings was not because it acted in a more dynamic way, but because graphicsenabler had wider powers that werent to do with individual injected efistring values - what about its injection of a rom, its power to mess with pci stuff (pciroot?) and other such things.... I understand what you are saying, but i have had experience with efistrings (for gtx295) which at one time only made one screen work, the other didnt work, but it was later possible to add support for dual monitors..... theres nothing different about efistrings that makes them less fault tolerant (sorry im not trying to partisan support for efistrings).... what about the boot text? old pci command - 7 boot display - 1 Not going to use bios image file Found bios image Adding binimage to the card 954f from legacy space with size 10000 maybe i am misunderstanding what you intended to say, whilst simultaneously saying something similiar...... what i think ill try next is videoing the boot text when booting verbose, as before i only video'd it in non verbose mode. perhaps this might tell us something else. er, but yeah, you're both right, trial and error isnt a very efficient method of getting it to work.... @ertepechis regarding the problem where you cant even get to bootloader, i had that when i was trying to make an efistring before i even made this topic. i solved it by deleting or changing one of the plist entries, however, im not sure that it was a proper fix. ill try and find out how i did it, ive got a bunch of experimental efistring plists that i made, ill try loading them and seeing which ones let me past the boot screen..... Chameleon RC5 does look interesting...... im going to try rc5 in a few days Link to comment Share on other sites More sharing options...
CrazyXBMax Posted September 9, 2010 Share Posted September 9, 2010 Tried RC5 already, works through GraphicsEnabler! Link to comment Share on other sites More sharing options...
Recommended Posts