Jump to content
Welcome to InsanelyMac Forum

Register now to gain access to all of our features. Once registered and logged in, you will be able to contribute to this site by submitting your own content or replying to existing content. You'll be able to customize your profile, receive reputation points as a reward for submitting content, while also communicating with other members via your own private inbox, plus much more! This message will be removed once you have signed in.


  • Content count

  • Joined

  • Last visited

About 0xdeadbeef

  • Rank
    InsanelyMac Protégé

Contact Methods

  • Website URL

Profile Information

  • Location
  1. RME HDSP MacOSX (x86) drivers released

    GPL'ing the 1.73 driver itself and EOL'ing support would be the honourable thing to do - help legacy users and enthusiasts get every last mile out of their trusted hardware and get an unbelievable amount of goodwill. I don't think there is so much secret-sauce über-valuable intellectual property contained in a coreaudio driver, but getting any audio company to open-source anything is like getting blood out of a stone - it's just in their corporate nature to maintain control over everything. That said, there is a working open-source ALSA driver ( and even a totalmix clone! ) for linux, so it's not beyond the realms of possibility that some guru with enough driver experience and a bit of time could come up with an open-source coreaudio driver. The internal structure and logic of the xilinx chip must be exposed in that ALSA driver. It's been done before for other hackintosh hardware, why not for RME?
  2. RME HDSP MacOSX (x86) drivers released

    I was toying with making an attempt at patching latest drivers for PCI use - as far as I can tell the only difference in the audio path for the older cards is the driver contains an integer-to floating-point conversion routine (PCI cards supply the audio data as integer and the driver converts to float, and the newer cards do this conversion in hardware, so the routine is now missing from the driver). However this is not a trivial job at all and would likely involve users having to upgrade their PCI firmware to the latest version using windows AND there would be no guarantee the mac driver would recognise the card. I CAN'T be responsible for users bricking their cards just because they want a Lion/64-bit upgrade, and I'm reluctant to take the risk of bricking my OWN card during development of the patch I shall definitely look at the possibilities though, unfortunately my development hackintosh is dead at the moment. Stay tuned, and I shall post what I find, when I find it. It really sucks that RME have hung Mac users with PCI expansions and hackintoshers out to dry - I gave them hell about it before they released the one working driver. Unfortunately EOL'ing a 10+ year old card isn't actually that bad for a company, what really gets me is that of course it is still supported in windows, and dropping the PCI support from the Mac driver involved removing 5 lines of C++ source code. I mean for God's sake, what is wrong with these people!
  3. Mobility Radeon HD 2400 XT

    Remove AppleIntelCPUPowerManagement.kext if it is causing problems. I will try to get the patched ATIFramebuffer to you tomorrow.
  4. Mobility Radeon HD 2400 XT

    Ok I shall try to supply you a patched ATIFramebuffer.kext for 10.6.7, see if we can get your displays to switch on.
  5. Mobility Radeon HD 2400 XT

    I can't guarantee we can find a solution for 10.6 - I have tried looking at OpenGL but so far failed. However if 10.6.8 includes the same graphics architecture as was in the 10.6.7 MBP update, we may have better luck. would be nice to get 10.5 working for you guys too though.
  6. Mobility Radeon HD 2400 XT

    Well I got the Framebuffer working on 10.6.7 no problem, but there's a known problem with OpenGL that means we can't have CI/QE. I'm not sure what it is, but 10.6 works on 2400 iMacs so there should be a workaround somehow.
  7. Mobility Radeon HD 2400 XT

    Hmm this is most annoying. I'd like to get this sorted soon and move onto finding a fix for openGL/CL on 10.6, because the 10.6.7 MBP drivers themselves are much more tolerant of connection variations. I will try to dig some more for you guys.
  8. Mobility Radeon HD 2400 XT

    I just realised the no-hotplug-support and no-hotplug-interrupt flags could be messing things up too - could you try again with these removed too?
  9. Mobility Radeon HD 2400 XT

    Could both you guys make sure that you are not using @0,display-link-component-bits?
  10. Mobility Radeon HD 2400 XT

    I know already there's no image, what I want to know is if the internal backlight is on? that is important from a driver connector point of view. It would be really much easier to work with this if you guys had osxvnc installed.
  11. Mobility Radeon HD 2400 XT

    I can't test DVI, because I don't have one, but is the backlight on in internal even if the display is off after booting with VGA plugged in?
  12. Mobility Radeon HD 2400 XT

    if only one of your monitors are going to sleep, it might be possible to alter a _DSS method in DSDT to enable proper switching, but not if both are asleep I suspect. Let me get this straight - if you boot with an external plugged in, they both goto sleep? Is the backlight on in the internal panel, even though the display is off?
  13. Mobility Radeon HD 2400 XT

    Yes that's the display going to sleep when it goes black. if it does that then ATINDRV is loading. If you have a setting in your BIOS that allows you to select only external monitor when it is plugged in (usually called "Auto select" or somthing) try booting like that with all the kexts (including GA etc, except ATY_Init of course) and your dummy plug or an external. This is what works for me (The external has to be plugged in for the internal to later switch on. working on that )
  14. Mobility Radeon HD 2400 XT

    Okay definitely something wrong with the injector - it appears to have loaded but not injected all the correct keys. do you get messages from ATY_Init loading in the log while using this configuration? You can try to remove ATY_Init, then make an EFI string for chameleon with EFI studio or something including the properties that are listed in the 2400 ATY_Init personality. Then try to load all the kexts I supplied except ATY_Init.
  15. Mobility Radeon HD 2400 XT

    Forcing Iago to load on PCIMatch will do you no good either. it must match on a device type item of type "display" which has "compatible" key with value "ATY,Iago" Also, there can be only one class (or superclass) of "IOFramebuffer" loaded by IOGraphics at one time - it is loading the default apple vesa ioframebuffer instead of Iago. That is why X2000 goes all disco. What you also can try is booting with and without ATY_Init only and dumping ioreg for IODevicetree, see if there's anything wrong there.