Jump to content



Member Since 13 Apr 2011
Offline Last Active Nov 30 2017 08:45 PM

Posts I've Made

In Topic: AppleIntelHDGraphicsFB fixed (SL 10.6.8)

05 April 2013 - 01:46 PM

Hey so I found this linux utilityto read and write EDID information. I havent tried it yet as I am afraid of messing up my display, But I believe that it can be used to write a good EDID to our displays, either the one provided by windows or another one that We are able to decode. Does anybody have any experience with this utility/ think this is arealistic solutuion


I tried it, unfortunately it does not work, my laptop had 8 devices on the i2c bus, number 2 being listed as the 'Panel', if you try a read or write to this or indeed most of the devices it gives an IO error. Devices 6 & 7 were listed as DDC and they did accept the read/write without the IO Error but timed out, assume these are for external displays. Looks like Toshiba don't put the hardware in the display for the EDID.

In Topic: AppleIntelHDGraphicsFB fixed (SL 10.6.8)

19 March 2013 - 11:55 PM

I have a Toshiba M11 with exactly the same problem as Pentothal. The screen is LVDS but is not sending an EDID out, if you look under the frame buffer in ioreg with IntelHDGraphicsFB loaded no displays are present. I have tried injecting the EDID through DSDT, Natit and monitor overrides, nothing works. Some of the other Intel framebuffers have EDID override code in them, unfortunately although IntelHDGraphicsFB does have the code it is not used, did try to call it by manually altering the code but that just caused a kernel panic.

I think Pentothal is correct, for us because EDID is not being sent the Framebuffer can't determine the correct timing and ignores the screen

In Topic: Intel HD Graphics (0x00468086) QE/CI on Lenovo X201

16 January 2013 - 09:20 PM

alexanita, did you retrieve the aapl,os-info data yourself? If so, how did you do it, and will it vary from system to system?


aapl,os-info is defined in appleintelhdgraphicsfb there are two defined, but I think only one used in the kext as follows

30 49 01 11 01 10 08 00 00 01 00 00 00 00 00 00 FF FF FF FF
30 49 00 14 14 14 08 04 00 00 00 00 00 00 00 00 FF FF FF FF

In addition there is another one OsInformation Default

30 49 01 01 01 00 08 00 00 00 00 00 00 00 00 00 FF FF FF FF

I am not really sure what they do but suspect they only tell what hardware is in use

In Topic: [FIXED] Intel GMA HD 5700MHD

09 August 2012 - 09:11 PM

Thanks for the help, ebmesnow, and now I'm getting these errors in compiling the DSDT.aml.

Can you attach your DSDT and I will have a look, have you done this before? Some of the DSDT compilations are known to be full of errors before, does not look like anything we have introduced.

In Topic: [FIXED] Intel GMA HD 5700MHD

09 August 2012 - 01:02 AM

You need to find the Graphics section of your DSDT, probably called GFX0 or IGPU then add this code under it
Method (_DSM, 4, NotSerialized)
						    Store (Package (0x0A)
								    Buffer (0x0A)
								    Buffer (0x08)
								    Buffer (0x12)
									    "Intel HD Graphics"
								    Buffer (One)
								    Buffer (0x14)
									    /* 0000 */   0x30, 0x49, 0x01, 0x11, 0x01, 0x10, 0x08, 0x00,
									    /* 0008 */   0x00, 0x01, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
									    /* 0010 */   0xFF, 0xFF, 0xFF, 0xFF
							    }, Local0)
						    DTGP (Arg0, Arg1, Arg2, Arg3, RefOf (Local0))
						    Return (Local0)

You will also need to add the DTGP method in not already included in your DSDT, this is a fairly common method of injecting stuff, used to trick kexts into think the hardware is something other than it is and used a lot in fixes, if you look at some of the standard hacks in DSDTSE you will see it frequently used.
© 2017 InsanelyMac  |   News  |   Forum  |   Downloads  |   OSx86 Wiki  |   Designed by Ed Gain  |   Logo by irfan  |   Privacy Policy