Jump to content

Injecting EDID into DSDT


  • Please log in to reply
8 replies to this topic

#1
banini_jeque

banini_jeque

    InsanelyMac Sage

  • Members
  • PipPipPipPipPip
  • 303 posts
I was wondering, when laptop users with 950 or 3100 graphics inject their EDID data into their dsdt, does it stick after sleep? I have a different experimental setup that I'm doing, and after sleep it tries to redetect the screen, and loses my edid data. It also does it if I hit "detect displays" in the displays pref pane. Would putting in the "built-in" fix this? Thanks

#2
CharredPC

CharredPC

    InsanelyMac Sage

  • Members
  • PipPipPipPipPip
  • 302 posts
I have yet to successfully inject EDID data from my DSDT (X3100). If you figure out a way, please let me know. Are you sure that it's "losing" the EDID data, and the screen / video simply isn't being notified properly after sleep? Have you tried checking with ScreenResX before and after (via screen sharing, for example) to see if the EDID changes? If that is in fact the case, you could fix it with a display override. Otherwise, it's a standard "black screen after sleep" GMA issue.

#3
banini_jeque

banini_jeque

    InsanelyMac Sage

  • Members
  • PipPipPipPipPip
  • 303 posts
Yeah it definitely changes. I have a slightly different problem than anyone else does, but basically all I want to say in order to avoid confusing people, is that it is not possible for my display to communicate any data to my video card. When I inject the EDID into the dsdt, it thinks it is getting that data, and ioregexplorer shows the proper EDID, and ProductID and VendorID. Once I sleep or "Detect Displays", it changes it to the unknown display override, and the proper EDID, and everything else in ioregexplorer are also gone. I know that I've seen stuff like Device (CRT) and stuff, and I'm kind of hoping one solution might be to add a Device (CRT) to my DSDT, and inject the ProductID and VendorID into it. If the address was right, I think it might then always load the correct display override when it tried to detect the display.

I have been able to put the right EDID data into the "unknown" override file, and that worked, but I would rather figure out how to do it this way.

#4
CharredPC

CharredPC

    InsanelyMac Sage

  • Members
  • PipPipPipPipPip
  • 302 posts

I have been able to put the right EDID data into the "unknown" override file, and that worked, but I would rather figure out how to do it this way.


Good luck with that. The main problem is that (in my experience) OSX usually just locates its own display devices, and ignores any listed in the DSDT, except for a properly addressed videocard. I've got LCD, CRT, etc in mine too, and they don't matter a bit. All can be removed, or edited, and there's no change. Maybe your system is set up different enough to work.

In theory, this sort of DSGT method can be inserted to inject EDID via DSDT:

Method (_DSM, 4, NotSerialized)
			 {
			  Store (Package ()
			  {
			   "AAPL01,EDID", 
			   Buffer (0x80)
				{
				  /* 0000 */	0x00, 0xFF, 0xFF, 0xFF, 0xFF, 0xFF, 0xFF, 0x00, 
				  /* 0008 */	0x32, 0x0C, 0x00, 0xDF, 0x00, 0x00, 0x00, 0x00, 
				  /* 0010 */	0x00, 0x11, 0x01, 0x03, 0x80, 0x21, 0x15, 0x78, 
				  /* 0018 */	0x0A, 0xE9, 0xD5, 0x99, 0x59, 0x53, 0x8E, 0x28, 
				  /* 0020 */	0x26, 0x50, 0x54, 0x00, 0x00, 0x00, 0x01, 0x01, 
				  /* 0028 */	0x01, 0x01, 0x01, 0x01, 0x01, 0x01, 0x01, 0x01, 
				  /* 0030 */	0x01, 0x01, 0x01, 0x01, 0x01, 0x01, 0xDE, 0x21, 
				  /* 0038 */	0xA0, 0x70, 0x50, 0x84, 0x1F, 0x30, 0x20, 0x20, 
				  /* 0040 */	0x56, 0x00, 0x4B, 0xCF, 0x10, 0x00, 0x00, 0x18, 
				  /* 0048 */	0xDE, 0x21, 0xA0, 0x70, 0x50, 0x84, 0x1F, 0x30, 
				  /* 0050 */	0x20, 0x20, 0x56, 0x00, 0x4B, 0xCF, 0x10, 0x00, 
				  /* 0058 */	0x00, 0x00, 0x00, 0x00, 0x00, 0xFE, 0x00, 0x4B, 
				  /* 0060 */	0x52, 0x35, 0x31, 0x35, 0x00, 0x31, 0x35, 0x34, 
				  /* 0068 */	0x57, 0x50, 0x31, 0x0A, 0x00, 0x00, 0x00, 0xFE, 
				  /* 0070 */	0x00, 0x23, 0x33, 0x3D, 0x48, 0x65, 0x84, 0xAA, 
				  /* 0078 */	0xFF, 0x02, 0x01, 0x0A, 0x20, 0x20, 0x00, 0xA3
				   }
				  }, Local0)
				  DTGP (Arg0, Arg1, Arg2, Arg3, RefOf (Local0))
				  Return (Local0)
				 }
			 }

In reality, I've never gotten it to work. I can place it under the videocard (GFX0), and the data is seen (shows up under ioreg), but it's seen under the videocard, not any display, so is never used. And as I said, all display device data is ignored in my DSDT, so adding it there does nothing either. You may have better luck if your videocard and display devices are under the same hardware address. I'm still seeking a DSDT (or at least EFI-based) solution, but am stuck using a modified default display override with the proper EDID injected into it.

#5
banini_jeque

banini_jeque

    InsanelyMac Sage

  • Members
  • PipPipPipPipPip
  • 303 posts
I see. Well I know mine at least works before I sleep or "Detect Displays" as it comes up with the right name for the display ("iMac") and limits it to the right three settings options (640x480@117, 800x600@95 and 1024x768@75). Yes, I've built a hackintosh in a G3 iMac using the original monitor. Anyway, I can still use the display after it gets redetected as unknown, it just gives me all the other options that I don't need. I was like I said able to get a display override to keep it at the three options even then though.

Anyway, so what about putting the edid data in with something like Natit, or even ATY_init? Is there a way to do it so I can use it to only inject display data and not data for the graphics card? I'm using PC_EFI 10.5 to inject the graphics and it's working fine.

Here's the iMac

#6
banini_jeque

banini_jeque

    InsanelyMac Sage

  • Members
  • PipPipPipPipPip
  • 303 posts

In reality, I've never gotten it to work. I can place it under the videocard (GFX0), and the data is seen (shows up under ioreg), but it's seen under the videocard, not any display, so is never used. And as I said, all display device data is ignored in my DSDT, so adding it there does nothing either. You may have better luck if your videocard and display devices are under the same hardware address. I'm still seeking a DSDT (or at least EFI-based) solution, but am stuck using a modified default display override with the proper EDID injected into it.


I used "@0,EDID" instead of "APPL01,EDID" and it shows up in ioreg under the video card's first output, and also under the display.

#7
CharredPC

CharredPC

    InsanelyMac Sage

  • Members
  • PipPipPipPipPip
  • 302 posts

I used "@0,EDID" instead of "APPL01,EDID" and it shows up in ioreg under the video card's first output, and also under the display.


Are you using Leopard or SL? Do you have a GMA 950 or X3100 videcoard? Laptop or desktop?

@0,EIDE does not work under 10.5.8 with stock drivers on my X3100 laptop.

#8
banini_jeque

banini_jeque

    InsanelyMac Sage

  • Members
  • PipPipPipPipPip
  • 303 posts

Are you using Leopard or SL? Do you have a GMA 950 or X3100 videcoard? Laptop or desktop?

@0,EIDE does not work under 10.5.8 with stock drivers on my X3100 laptop.



I'm using the nvidia ION actually, and SL. I just haven't found any posts of people injecting EDID with nvidia cards so that's why I posted here in the intel forum.

#9
bisk

bisk

    InsanelyMac Protégé

  • Members
  • PipPip
  • 53 posts
Aloha !

I know that this is an insanely ancient thread but I figured that I might as well revive it rather than recreate yet another, so ...

Just wanted to check if anyone had an idea of how to inject an EDID via DSDT or any other method into my display0->AppleBacklightDisplay.

I have a Sony Vaio VGN-NR180E with Intel X3100 video and just about everything is now working under 10.7.5 32 bit.
Sleep/Wake, SpeedStep, Ethernet, Airport(swapped out Intel WiFi card for Broadcom), Audio, K/B&TrackPad, etc., etc. It's completely vanilla with the exception of FakeSMC, VoodooHDA, [Apple: ACPIBatteryManager/ACPIPS2Nub/PS2Controller].

I needed to use the Display Override method with a custom DisplayProductID-717 file to get the LCD viewable with QE/CI and Resman working so I'm convinced that my EDID is good.

However, even when booting the corrected display, no EDID information appears anywhere in my registry. It will show up in the wrong place (under the video adapter) if I attempt to inject it via DSDT exactly as described by CharredPC above but is no help there at all.

The reason that I care is because this HackBook is locked at 100% brightness and if I even touch the slider or the Fn/brightness- key, the backlight goes black and will not come back unless I reboot. I have had to disable the "Slightly dim the display when using this power source" and "Automatically reduce brightness before display goes to sleep" checkboxes as well or the backlight shuts off for good if/when these kick in !

My hope is that injecting the proper EDID for this LCD into the AppleBacklightDisplay device will correct the brightness behavior.

Has anybody out there yet been able to successfully inject a missing EDID into the AppleBacklightDisplay device ?

Thanks in advance :)

On a separate sidenote, there is only one other strange deficiency with this HackBook.

I get logged out whenever I attempt to invoke the "About This Mac" panel.

I have not seen this happen on any system that I've built since the Leopard 10.5.x days with chocolate installs prior to the birth of FakeSMC. I can run System Profiler directly and get the "About This Mac" panel through it's Windows option but just cannot get the panel directly. Also, I notice an error in the Profiler when trying to display detailed Memory information. It knows that there is 2GB of RAM installed but fails to recognize the memory slots.

The Chameleon bootloader displays a proper summary of the RAM slots and the DIMM details at the beginning of the boot so this is strange. BTW, I use v2.1-r2069.





0 user(s) are reading this topic

0 members, 0 guests, 0 anonymous users

© 2014 InsanelyMac  |   News  |   Forum  |   Downloads  |   OSx86 Wiki  |   Mac Netbook  |   PHP hosting by CatN  |   Designed by Ed Gain  |   Logo by irfan  |   Privacy Policy