ebmesnow

stacyk819, on 28 March 2013 - 06:54 PM, said:

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.

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

iWin32, on 13 January 2013 - 04:28 PM, said:

iwin32

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

Quote

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.

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)
								{
									"hda-gfx",
									Buffer (0x0A)
									{
										"onboard-1"
									},
									"device_type",
									Buffer (0x08)
									{
										"display"
									},
									"model",
									Buffer (0x12)
									{
										"Intel HD Graphics"
									},
									"built-in",
									Buffer (One)
									{
										 0x01
									},
									"AAPL,os-info",
									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.