Hervé

HDMI audio requires connector to be patched to HDMI type (00080000); in your case (and as is usually the case): connector con1. No need to patch con0 to LVDS/eDP, it's its native setting. ID: 59160000, STOLEN: 34 MB, FBMEM: 0 bytes, VRAM: 1536 MB, Flags: 0x00000B0B TOTAL STOLEN: 35 MB, TOTAL CURSOR: 1 MB (1572864 bytes), MAX STOLEN: 103 MB, MAX OVERALL: 104 MB (109588480 bytes) Model name: Intel HD Graphics KBL CRB Camellia: CamelliaDisabled (0), Freq: 1388 Hz, FreqMax: 1388 Hz Mobile: 1, PipeCount: 3, PortCount: 3, FBMemoryCount: 3 [0] busId: 0x00, pipe: 8, type: 0x00000002, flags: 0x00000098 - ConnectorLVDS [1] busId: 0x05, pipe: 9, type: 0x00000400, flags: 0x00000187 - ConnectorDP [2] busId: 0x04, pipe: 10, type: 0x00000800, flags: 0x00000187 - ConnectorHDMI 00000800 02000000 98000000 01050900 00040000 87010000 02040A00 00080000 87010000 I also see that you inject your screen's EDID. I guess it made no difference. Which tool did you grab it with?

So, built-in screen still garbled with HDMI connected and running in mirror mode? Looking at your IOReg, I can see that the built-in screen is fully detected on connector con0 ("AppleBacklightDisplay") with LVDS/eDP type (02000000). Strangely enough, I see that you patched connector con1 (used for external HDMI screen) to type LVDS/eDP too. What's the reason for that?

I'm surprised by your iGPU settings/properties injection: No need to inject any fbmem or stolenmem patches for Haswell graphics/HD4600. Get rid of those. And cursormem patch is entirely optional, use it only if you experience cursor corruption. Azul framebuffer #12 0x0a260006 defines the following video memory and ports settings: ID: 0A260006, STOLEN: 32 MB, FBMEM: 19 MB, VRAM: 1536 MB, Flags: 0x0000000F TOTAL STOLEN: 52 MB, TOTAL CURSOR: 1 MB (1572864 bytes), MAX STOLEN: 116 MB, MAX OVERALL: 117 MB (123219968 bytes) Camellia: CamelliaDisabled (0), Freq: 2777 Hz, FreqMax: 2777 Hz Mobile: 1, PipeCount: 3, PortCount: 3, FBMemoryCount: 3 [0] busId: 0x00, pipe: 8, type: 0x00000002, flags: 0x00000030 - ConnectorLVDS [1] busId: 0x05, pipe: 9, type: 0x00000400, flags: 0x00000087 - ConnectorDP [2] busId: 0x04, pipe: 9, type: 0x00000400, flags: 0x00000087 - ConnectorDP 00000800 02000000 30000000 01050900 00040000 87000000 02040900 00040000 87000000 HDMI output usually attaches to connector con1, not con2. So that's what you'd usually set to HDMI type. Pipe needs to be changed to 12 too for both connectors. So you'd therefore inject the following adjusted settings: framebuffer-con1-enable 1 NUMBER framebuffer-con1-pipe 12000000 DATA framebuffer-con1-type 00080000 DATA framebuffer-con2-enable 1 NUMBER framebuffer-con2-pipe 12000000 DATA See here.

Take and post a new zipped IOReg extract.

Good to know and glad you sorted it out. NB: your Google drive link is not opened to public access.

macOS Ventura dropped support for pre-Kaby Lake platforms and that includes dropped CPU Power Management for pre-Haswell legacy CPUs, i.e. Wolfdale/Penryn (Core2Duo/Core2Quad and associated Xeon) processors Nehalem/Westmere (Lynnfield, Clarkdale/Arrandale) processors Sandy Bridge processors Ivy Bridge processors Adding kexts to S/L/E or /L/E for caching being so difficult in Ventura (and since Big Sur), CPU power management for the above pre-Haswell legacy CPUs can only easily be achieved by injecting the missing AICPUPMClient + AICPUPM kexts through the bootloader (Clover or OpenCore). The kexts from macOS Monterey can be re-used to that effect. The trouble then is that, for Sandy Bridge and Ivy Bridge CPUs, no on-the-fly AICPUPM patch can be applied to the cache since the kexts do no exist in cache. As an exception, Ivy Bridge CPUs may be able to benefit from XCPM but that does not necessarily work on all platforms. Luckily for us, the good old (pre-Clover/pre-OpenCore) solution of manually patching the AppleIntelCPUPowerManagment kext can be revived and re-used to satisfy our needs on Sandy Bridge and Ivy Bridge platforms. The patched AICPUPM kext can then be injected in Ventura to provide full CPU power management without incurring the good old dreaded Kernel Panic. The method has not changed since its inception all those years ago and the patch details remain courtesy of Pimentel and his tools as published at IM. In order to ensure the tool is not lost, I attach a copy of it, I trust the author won't mind. AICPMPatch.zip Usage of the patching script is as follows: cd <script path>/AICPMPatch to check on the patching requirements (i.e. list of wrmsr instances in the kext's binary): sudo perl AICPMPatch.pl <kext path>/AppleIntelCPUPowerManagement.kext/Contents/MacOS/AppleIntelCPUPowerManagement to patch the kext's binary: sudo perl AICPMPatch.pl <kext path>/AppleIntelCPUPowerManagement.kext/Contents/MacOS/AppleIntelCPUPowerManagement --patch The kexts are of Monterey 12.6.x origin and carry version v222.0. Vanilla AppleIntelCPUPowerManagementClient and patched AppleIntelCPUPowerManagement kexts for Sandy/Ivy Bridge CPUs: AppleIntelCPUPowerManagementClient.kext.zip Patched_AppleIntelCPUPowerManagement.kext.zip Place the unzipped kexts in the bootloader's target kexts folder and that's it: full CPU power management in Ventura for pre-Haswell CPUs. Caution though because I'm not certain this fully works after wake.

Injecting EDID info will do no harm. This being said, you should get rid of all those patched SSDT tables you do not use; this will avoid all possible confusion. Also check that the PNLF table is correct in order to ensure it's not the cause of your issue. You could experiment with the PNLF table included in the Ventura pack of my E7270 guide. On the kexts side, I've noticed you inject Lilu v1.6.4, WhateverGreen v1.6.4 and AppleALC v1.7.9. For WhateverGreen and AppleALC, these were only published today afaik and Lilu is only at v1.6.3, all that at Acidanthera's Github repo. I'd recommend you grab your kexts from there: https://github.com/acidanthera.

Make sure to reset NVRAM at OC Picker after you make changes to your config/setup.

Your posted IOReg and Opencore EFI indeed have incorrect graphics settings for Ventura. In addition, I don't believe you'd need all those igfx boot args for any macOS version, especially if they come as duplicates of your iGPU injected properties (eg: force-online vs. igfxonln=1). I'm pretty sure all you may require is the force-online injected property or the igfxonln=1 boot arg. See the Whatevergreen User Manual for references. Also note that, afaik, Latitude E5x70 are limited to HDMI1.4, so no HDMI2.0 capability. Given that Ventura dropped support for Skylake platforms and therefore SKL graphics (no SKL drivers provided), one of the easiest trick is to spoof Kaby Lake (KBL) settings and modify your setup as follows: AAPL,ig-platform-id 0x59160000 or 0x591b0000 (these work for SKL HD520) device-id 0x5916 (this works for SKL HD520) use Whatevergreen kext v1.6.1 minimum (and no need of specific boot args) SMBIOS MBP14,1 during installation after which you may revert to SMBIOS MBP13,1 with -no_compat_check boot arg Those settings are visible in the Ventura OC EFI posted at the place you linked in post #1, even if it were for the beta version. I can't see why these would not work for you if you have the exact same laptop but see our existing guidance/information on the matter of Skylake graphics in Ventura. For instance: https://osxlatitude.com/forums/topic/8238-supportedunsupported-gpus-graphics-cards/#comment-117952 https://osxlatitude.com/forums/topic/17292-macos-ventura-130-beta1-early-feedback-and-findings https://osxlatitude.com/forums/topic/17336-macos-ventura-130-beta3-is-out/ https://osxlatitude.com/forums/topic/15648-dell-latitude-e7270-with-i7-6600u-hd520-and-1920x1080-touchscreen-high-sierramojavecatalinabig-surmontereyventura/?do=findComment&comment=116192 I suggest you go back to basics: 1) injected properties AAPL,ig-platform-id 00001659 DATA // KBL mobile framebuffer device-id 16590000 DATA // KBL iGPU id framebuffer-patch-enable 1 NUMBER // Enables framebuffer patching framebuffer-fbmem 00009000 DATA // Sets fbmem to 9MB framebuffer-stolenmem 00003001 DATA // Sets stolenmem to 19MB framebuffer-con1-enable 1 NUMBER // Enables connector con1 patching framebuffer-con1-type 00080000 DATA // Sets connector con1 to HDMI type hda-gfx onboard-1 STRING // Built-in digital audio capability 2) boot args for graphics (may come in addition to other unrelated boot args like audio settings or boot mode) -igfxonln=1 // forces all displays on-line 3) SMBIOS MBP14,1 for installation, then MBP13,1 with -no_compat_check boot arg if you want to revert to SKL profile.

Target macOS release: Ventura 13.x. This is a Clover-based installation based on the standard vanilla method detailed below, followed by OCLP root patching to bring back support for HD4000 graphics. Working: full graphics acceleration on Intel HD4000 graphics (with Lilu v1.6.3 + WEG v1.6.3 + OCLP v0.6.1 root patching) multi-display with HDMI after OCLP patching audio, including jack microphone input and headset output (with AppleALC v1.7.8 & layout 12 + CodecCommander v2.7.2) HDMI audio (with Capri Framebuffer properties injection) built-in GigEthernet LAN connection (with AppleIntelE1000e v3.1.0 or latest IntelMausiEthernet kext) wireless and bluetooth with any compatible card integrated webcam (OOB) full CPU power management, including Turbo boost (with CPU-specific generated ssdt + AICPUPMClient v222.0 & patched AICPUPM v222.0 kexts) sleep (Lid, Energy Saver settings, Apple menu, Fn-F1, PWR button) & wake (Lid, PWR button) battery management (with ACPIBatteryManager v1.90.1) SD card reader (with DSDT patch or property injection, for compatibility with Apple's default card reader) keyboard (with Dr Hurt's VoodooPS2Controller R6 + DSDT patch for brightness control) touchpad including tap-to-click (with Dr Hurt's VoodooPS2Controller R6) left combo eSATA/USB2.0 + right USB3.0 ports (with Hackintool's generated USBPorts; optional FakePCIID kexts v1.3.15, published here, for multiplexing) ExpressCard slot OOB Stage Manager Continuity Camera Airplay Audio Not working: VGA output unsupported Not tested: SmartCard reader fingerprint scanner GeekBench v4.4.x (64bit) results: 1) 13.x USB installer creation Using a USB key of 16GB minimum, create a Ventura USB installer through the following Terminal command: sudo <path>/Install\ macOS\ Ventura.app/Contents/Resources/createinstallmedia --volume /Volumes/<USB key> where: <path> = location of Ventura installation package (eg: /Applications if freshly downloaded) <USB key> = name of formatted USB volume (eg: USB_16GB) The process will take several minutes. Once completed: install Clover boot loader on the USB installer with the following customised settings: Clover for UEFI booting only Install Clover in the ESP UEFI drivers Recommended Drivers (optional) EnglishDxe Human Interface Devices (optional) PS2MouseDxe USBMouseDxe FileSystem Drivers ApfsDriverLoader FAT (optional) Memory fix drivers OpenRuntime Additional Drivers (optional) PartitionDxe Themes (optional) BootLoader Chooser (optional) CloverConfigPlistValidator (optional) you may use version r5150 attached below Clover_r5150.pkg.zip once Clover is installed, launch Clover Configurator app and mount the freshly created EFI partition of the USB installer Clover Configurator.zip add the (unzipped) HFSPlus driver attached below to the EFI/CLOVER/drivers/UEFI folder HFSPlus.efi.zip open the EFI partition and transfer the files and folders from the Latitude E6230 Ventura Clover pack below to the EFI/CLOVER folder. The pack contains: the CryptexFixup + AMFIExemption kexts that are necessary to install Ventura on non-AVX 2.0 systems such as this Ivy Bridge platform the accompanying -crypt_force_avx and amfi_get_out_of_my_way=1 boot args AppleIntelCPUPowerManagementClient + patched AppleIntelCPUPowerManagement kexts (of Monterey origin) that are necessary for full for Ivy Bridge CPU PM, Apple having dropped those in Ventura and XCPM not being achievable on this platform Clover_Pack_E6230_Ventura.zip /!\ If your E6230 is fitted with a different CPU than the i7-3540M, please remove the Power Management SSDT of the pack until you replace it by one applicable to your model (whether an existing SSDT or your own generated one) in the post-install phase. 2) 13.x installation boot the Ventura USB installer at the Clover main menu, go to the "Options->configs" menu and select the "config_MBP14,1" config file. This is required to install (and later update as/when required) Ventura on a supported Mac model. Press [ESC] twice to return to Clover main menu. at the Clover main menu, select the "Install macOS Ventura" partition and press [ENTER] at Ventura main installation screen, select Disk Utility to create & format APFS the target Ventura disk/partition/volume. Note that installation won't work if target disk/partition/volume is formatted HFS+ exit DU and return to Ventura main installation screen, then proceed with installation the installation process will need to reboot a temporary macOS Install from <target disk> partition to complete the installation. Make sure to select the "config_MBP14,1" config file before the reboot. repeat this until the temporary partition is replaced by a final <Ventura partition name> on Preboot entry. Each time, reboot via your USB installer and make sure to select the "config_MBP14,1" config file until you boot the partition labelled <Ventura partition name> on Preboot to finalise the installation. 3) Post-installation tuning Once the finalised Ventura installation has booted, complete the 1st boot configuration tuning. This will be very slow due to lack of graphics acceleration, HD4000 having been dropped since macOS Monterey. Once at the desktop, install Clover on your Ventura disk with above settings, then mount the EFI partition of that disk. Copy the contents of the E6230 Ventura Clover pack to the EFI/CLOVER folder of the mounted EFI partition. You may then modify your SMBIOS info using Clover Configurator app and ensure you have unique numbers or unique combination of numbers (MLB, ROM, SystemSerialNumber and SystemUUID). Please note that, with MBP10,2 SMBIOS, Ventura will not offer any updates because it'll be running on an unsupported platform. You'll only get updated offered if you boot with the MBP14,1 config file, MacBookPro14,1 being a supported model. Open up Terminal and type: sudo nvram boot-args="amfi_get_out_of_my_way=1" Download the latest version of OpenCore Legacy Patcher (OCLP) app (needs to be v0.6.1 minimum). Remove your USB installer and reboot (with default config file). No need to call on the "config_MBP14,1" config file from there on to boot Ventura. 4) Post-installation OCLP patching OpenCoreLegacyPatcher (OCLP) app is used to patch the Ventura build on the E6230 and recover support for HD4000 graphics. The latest version of the tool available here. Run the tool and set it up as follows in order to apply post-installation root patching: click Settings button select MacBookPro10,2 SMBIOS, then return to Settings select SIP settings and tick all cases except "CSR_ALLOW_APPLE_INTERNAL" in order to set SIP to 0xFEF, then return to Settings select SMBIOS Settings and make sure everything is left blank, then return to Settings select Misc Settings and tick everything off, leaving Feature Unlock Status as "Enabled, then return to Settings select Non-Metal Settings and make sure everything is ticked off, then return to Settings select Developper Settings and make sure everything is ticked off, then return to Settings return to Main Menu Click Post Install Root Patch, then Start Root Patching OCLP root patches will then be installed. Once completed, reboot into Ventura and you'll have graphics acceleration running on HD4000. Note that OCLP root patching will be required after each Ventura update.

@Dave45 I guess you must be using a version of CC or a version of Clover not entirely compatible with the posted config or the config file somehow got corrupted for you. Or maybe made a confusion and actually used a different config file like the default one ("config.plist") in which Platform Support parameter is indeed not specified due to MBP10,2 SMBIOS. In each of my guide, I always include a copy of the version of CC and Clover I used. In the case of my E6230 Big Sur guide, I do not reproduce the issue you mentioned when I open said MBP11,1 config file with CC v5.19.0.0 (provided in the guide) nor with v5.23.0.0/v5.24.0.0: the Platform Feature parameter is clearly visible in the SMBIOS tab of the app and I have no issue booting that config with Clover either. This config boots Catalina & Monterey (with additional -no_compat_check for latter) with Clover r5150 -the version now running on my E6230- without a glitch.

Restoring support for dropped GPUs in macOS Ventura For older platforms up to Broadwell, best thing to do is patch Ventura with Opencore Legacy Patcher (OCLP) tool. Minimum version is OCLP v0.5.1. macOS 13 officially dropped support for all Haswell, Broadwell and Skylake iGPUs. Ventura therefore needs to be installed with SMBIOS of a supported Kaby Lake Mac model minimum. for 1st gen Intel HD graphics, apply root patches with OpenCore Patcher, making sure to disable SIP and select an Arrandale SMBIOS (eg: MBP6,2); no need for any other OCLP settings. for HD3000 graphics, apply root patches with OpenCore Patcher, making sure to disable SIP and select a Sandy Bridge SMBIOS (eg: MBP8,1); no need for any other OCLP settings. for HD4000 graphics, apply root patches with OpenCore Patcher, making sure to disable SIP and select an Ivy Bridge SMBIOS (eg: MPB10,2); no need for any other OCLP settings. for Haswell HD4x00 graphics and affiliated, apply root patches with OpenCore Patcher, making sure to disable SIP and select a Haswell SMBIOS (eg: MBP11,1); no need for any other OCLP settings. for Broadwell HD5x00 graphics and affiliated, apply root patches with OpenCore Patcher, making sure to disable SIP and select a Broadwell SMBIOS (eg: MBP12,1); no need for any other OCLP settings. for nVidia Tesla and Kepler graphics, apply root patches with OpenCore Patcher, making sure to disable SIP and select the SMBIOS or a Mac Model with nVidia graphics (eg: MBP7,1/iMac14,2); no need for any other OCLP settings. For Skylake HD5x0 graphics, things are a little different and using Kaby Lake graphics settings works perfectly. The trick to apply consists of: installing Ventura with Kaby Lake SMBIOS (eg: MBP14,1). injecting KBL framebuffer layout (eg: 0x59160000 or 0x591b0000). faking KBL iGPU device id (eg: 0x5916). injecting WhateverGreen kext v1.6.1 minimum. booting Ventura with KBL SMBIOS (eg: MBP14,1) or, alternatively, SKL SMBIOS (eg: MBP13,1) + -no_compat_check boot arg.

Means you need to fake Kaby Lake (KBL) graphics since Skylake (SKL) graphics are no longer supported, Apple having dropped support for all pre-Kaby Lake MacBook platforms (+ others) in Ventura. Also look at the WhateverGreen User Manual and our GPU support thread.

https://dortania.github.io/Anti-Hackintosh-Buyers-Guide/Storage.html

Have a look at existing XPS 7390 threads. Eg: https://osxlatitude.com/forums/topic/16557-solved-dell-xps-13-7390-cannot-boot-past-opencore

Ventura dropped support for Skylake platforms on which it can only run with tricks. If you read the various guides and/or threads we have about Ventura on Skylake E7x70 laptops, you'll see that there are pre-requisites you need to respect. You'll need to: fake a Kaby Lake platform -> switch from MBP13,1 to MBP14,1 fake KBL graphics since SKL are no longer supported and no SKL drivers are provided -> inject KBL framebuffer layout 0x59160000 (or 0x591b0000) and iGPU device id 0x5916 update Lulu and Whatevergreen to latest version (WEG v1.6.1 minimum) -> Whatevergreen will then apply the necessary patches to fake SKL as KBL graphics Rest should be unchanged. Note that it's a lot easier to use Clover in that context because it'll allow you to boot Monterey with a separate additional target Ventura config (manually add boot arg -igfxsklaskbl for Monterey only), download the Ventura installation app and install Ventura. Thereafter, you just need to call on that config as default to boot Ventura. If something goes wrong, you just boot Monterey as usual. With OpenCore, you don't have that option to call on a separate config file so you must ensure your file is 100% correct from the onset. Better to have a bootable USB key for backup... See these, among other things: https://osxlatitude.com/forums/topic/17636-macos-ventura-is-out https://osxlatitude.com/forums/topic/17292-macos-ventura-130-beta1-early-feedback-and-findings https://osxlatitude.com/forums/topic/17336-macos-ventura-130-beta3-is-out https://osxlatitude.com/forums/topic/17629-macos-ventura-130-rc-is-out https://osxlatitude.com/forums/topic/15648-dell-latitude-e7270-with-i7-6600u-hd520-and-1920x1080-touchscreen-high-sierramojavecatalinabig-surmontereyventura/?do=findComment&comment=116192 Good luck.

Updated for BIOS 1.36.3.

No, the stolenmem patch (alongside the fbmem patch) solves the OS X/macOS graphics framebuffer memory problem encountered since Yosemite with Broadwell (& later) iGPUs. It does not address in any way the 64MB+ DVMT requirement for 4K, nor the black screen issue. See this thread, in our FAQ section, for information on the matter of DVMT and framebuffer memory patches. As for your tablet's screen, do try and identify the fitted connector type. There are Windows and Linux tools for that. Look it up.

Realtek ALC3234 is based on ALC255 codec (PCI id 10ec:0255). Look up the recommended layout ids listed in the AppleALC wiki. You may not obtain full running audio on this codec with AppleALC in which case fallback on VoodooHDA. But this is off-topic in this HD530 troubleshooting thread.

It's best to opt for Clover on these old and obsolete laptops given that OpenCore is really made for systems fully operating in UEFI mode and it's a little painful to configure in legacy mode. Clover is far easier to configure and change in that respect. Look up my E6220 guide for pointers.

Graphics settings to use for KBL R UHD620 iGPU are: KBL framebuffer layout 0x591B0000 or 0x59160000 iGPU device id 0x5916 (or 0x5912 apparently) Layouts 0x87C000-- normally are for Amber Lake systems. SMBIOS should be MBP15,2 with MBP15,4 probably fine as well. Of course, DVMT will need to be set at 64MB minimum in BIOS for 4K output, it won't be achievable with DVMT set to 32MB. There are no workaround to this.

Intel i5-6500 integrates HD 530 iGPU with id 0x1912; this is natively supported, hence no need to fake iGPU is 0x191b. See the WEG user manual: https://github.com/acidanthera/WhateverGreen/blob/master/Manual/FAQ.IntelHD.en.md#intel-hd-graphics-510-580-skylake-processors

So... Dell XPS 13 7390: BIOS 1.18.0 Comet Lake i7-10710U @1.10GHz (6 core) Intel UHD graphics for 10th gen CPU (~ Intel UHD 620) -> PCI id 8086:9BCA FHD 1920x1080 built-in screen 16GB LPDDR3-2133 RAM 512GB SK Hynix PC611 NVME SSD Realtek ALC299 High Definition Audio -> PCI id 10EC:0299 Microdia integrated webcam (USB internal) -> PCI id 0C45:6D13 Realtek RTS525a PCIe microSD card reader -> PCI id 10EC:525A Intel Killer AX1650 Wi-Fi 6 802.11ax wireless + Bluetooth 5.2 -> PCI id 8086:2723 I2C Synaptics Touchpad -> PCI id 06CB:76B1 2 x TB3 (USB-c) ports 1 x USB3.1 gen2 (USB-c) port 1 x combo audio jack

When you boot with an invalid framebuffer, macOS operates in what is called VESA mode; consider it like Windows safe mode if you want a comparison. In this mode, you have no graphics driver loaded and the system operates in a very basic graphics mode. This is fully reflected in IOReg where you see no framebuffer whatsoever: When you boot with a valid (CFL) framebuffer, the driver loads/applies the framebuffer's defined output ports. Those will be reflected in IOReg and include the displays against/under their associated connectors (i.e. video output ports), provided these are fully and properly detected. In the case of your internal screen, regretfully it is not (no display registers again FB@0, FB@1 or FB@2): On the other hand, your external display does register as an HDMI monitor attached to 3rd output port FB@2: Now, looking at each output port when you boot with valid CFL layout 0x3e9b007, I see that all 3 x video output ports (i.e. connectors) are set to HDMI type (00080000). In all likelihood, your internal screen is LVDS or DP/mDP and you should try and experiment with that. It should be attached to 1st output port, i.e. FB@0 aka con0. As explained in my previous post, CFL framebuffer layout 0x3e9b007 defines 3 x DP ports. I would suggest you revisit your bootloader's config file and, in the iGPU device properties section, you experiment with con0's type as follows: framebuffer-con0-enable 1 NUMBER framebuffer-con0-type XXXXXXXX DATA where XXXXXXXX corresponds to the desired port type: 00080000 -> HDMI 00040000 -> DP/mDP 02000000 -> LVDS/eDP 04000000 -> digital DVI (or is it dual link DVI ?) 00020000 -> analog DVI (or is it single link DVI?) LVDS/eDP type being the most likely target value. If you stop injecting a port type for con0, you'll revert to default DP type but I assume you may have already tried that. You may also require to inject different values for the connector's flags but I'm not so familiar with that. Say, inject the same flags as for the built-in display of a CFL mobile layout: framebuffer-con0-flags 98000000 DATA Or disable/play with AGPM, that's another possibility.