Leaderboard

Here's the files I use, no issue with sleep / wake Disable the DW1820a in the Config if you have other wifi devices E7270_OC.zip

Better later than never... As explained in past system/model-specific threads, there are further patches that may be used to modify the framebuffer memory size (useful on Latitude E6x30) and the VRAM allocation (nice to increase). Of course, WhateverGreen supports property injection (through DSDT/SSDT patches or bootloader configs) as a more efficient alternative to rather old-fashioned framebuffer kext binary patching. Those parameters are defined in the 2nd line of the sample Capri layouts we've illustrated throughout this thread (bearing in mind the reversed byte order of kexts' binary code). For instance: LoRes mobile layout 0x01660003: 03006601 01020402 00000004 00000001 00000060 10070000 HiRes mobile layout 0x01660004: 04006601 01030101 00000002 00000001 00000060 10070000 Desktop layout 0x0166000a: 0A006601 00020302 00000002 00000001 00000060 10070000 Desktop layout 0x0166000b: 0B006601 00020302 00000002 00000001 00000060 10070000 1) Framebuffer memory size: This is defined in the 4th 32bit parameter of the layouts. Default value is 0x01000000 (reversed code 00000001), i.e. 16777216 in decimal which, when divided by 1024*1024 (=1MBytes), equates to 16MB. Some laptops such as the Dell Latitude E6x30 models suffer from corrupt/garbled display on screen unless this value is reduced to 8MB, i.e. 0x00800000. The patch required to change this is: Find: xxxxxxxx [...] xxxxxxxx 00000001 xxxxxxxx [...] xxxxxxxx Replace xxxxxxxx [...] xxxxxxxx 00008000 xxxxxxxx [...] xxxxxxxx For instance, to reduce the FB mem. size of layout 0x01660003 to 8MB, use this patch: \/\/ Find: 03006601010204020000000400000001 Replace: 03006601010204020000000400008000 /\/\ Alternative property injection: framebuffer-patch-enable 1 NUMBER framebuffer-fbmem 00008000 DATA 2) VRAM allocation: This is defined in the 5th 32bit parameter of the layouts. In most recent versions of OS X/macOS, the default value usually is 0x60000000 (reversed code 00000060), i.e. 1610612736 in decimal which, when divided by 1024*1024 (=1MBytes), equates to 1536MB (i.e. 1.5GB). This is shared memory and systems with, say, 8GB of RAM, may want to increase this. The patch required to do this is: Find: xxxxxxxx [...] xxxxxxxx 00000060 xxxxxxxx [...] xxxxxxxx Replace xxxxxxxx [...] xxxxxxxx 000000YY xxxxxxxx [...] xxxxxxxx -> where YY = desired VRAM Qty Reminder: 256MB = 1000 0000 in hex 384MB = 1800 0000 in hex 512MB = 2000 0000 in hex 768MB = 3000 0000 in hex 1024MB = 4000 0000 in hex 1536MB = 6000 0000 in hex 1792MB = 7000 0000 in hex 2048MB = 8000 0000 in hex For instance, to increase VRAM allocation of layout 0x01660003 to 2048MB (i.e. 2GB), use this patch: \/ Find: 0300660101020402000000040000000100000060 Replace: 0300660101020402000000040000000100000080 /\ Alternative property injection: framebuffer-patch-enable 1 NUMBER framebuffer-unifiedmem 00000080 DATA Naturally, those framebuffer modifications can be combined in a single patch. For instance, to reduce FB mem. size to 8MB and increase VRAM to 2GB, layout 0x01660003 is patched as follows: \/\/ \/ Find: 030066010102040200000004000000010000006010070000 Replace: 030066010102040200000004000080000000008010070000 /\/\ /\ Alternative property injection: framebuffer-patch-enable 1 NUMBER framebuffer-fbmem 00008000 DATA framebuffer-unifiedmem 00000080 DATA