Disable display on iMacs, as they can't do link training
on the internal display.
(tested on iMac20,1)
Signed-off-by: Atharva Tiwari <atharvatiwarilinuxdev@gmail.com>
---
drivers/gpu/drm/i915/display/intel_display_device.c | 7 +++++++
1 file changed, 7 insertions(+)
diff --git a/drivers/gpu/drm/i915/display/intel_display_device.c b/drivers/gpu/drm/i915/display/intel_display_device.c
index 1170afaa8680..3fb47232e7a4 100644
--- a/drivers/gpu/drm/i915/display/intel_display_device.c
+++ b/drivers/gpu/drm/i915/display/intel_display_device.c
@@ -3,6 +3,7 @@
* Copyright © 2023 Intel Corporation
*/
+#include <linux/dmi.h>
#include <linux/pci.h>
#include <drm/drm_color_mgmt.h>
@@ -1657,6 +1658,7 @@ struct intel_display *intel_display_device_probe(struct pci_dev *pdev,
const struct platform_desc *desc;
const struct subplatform_desc *subdesc;
enum intel_step step;
+ const char *product_name = dmi_get_system_info(DMI_PRODUCT_NAME);
display = kzalloc(sizeof(*display), GFP_KERNEL);
if (!display)
@@ -1674,6 +1676,11 @@ struct intel_display *intel_display_device_probe(struct pci_dev *pdev,
goto no_display;
}
+ if (dmi_match(DMI_BOARD_VENDOR, "Apple Inc.") && !strncmp(product_name, "iMac", 4)) {
+ drm_dbg_kms(display->drm, "iMac Detected, Disabling display\n");
+ goto no_display;
+ }
+
desc = find_platform_desc(pdev);
if (!desc) {
drm_dbg_kms(display->drm,
--
2.43.0
On Sun, 25 Jan 2026, Atharva Tiwari <atharvatiwarilinuxdev@gmail.com> wrote:
[Quoting this part from the cover letter]
> A side effect of this patch is that the iGPU becomes enabled on iMacs.
> However, iMacs can’t use the iGPU for rendering (They can't link-train
> the internal display), so displays must be disabled on iMacs.
Rendering and display are quite separate in the hardware and in the
driver. Perhaps you do not mean "rendering" here? Perhaps it can be used
for rendering but not display?
> Disable display on iMacs, as they can't do link training
> on the internal display.
Okay, so perhaps there's no eDP connected. But what about the other
connectors on the iGPU? What about everything else in the display
hardware?
If you can figure out that it's specifically link training that fails (a
dmesg would be useful to show this) there clearly is display hardware,
right?
There's at least three levels where this could be handled, depending on
details:
- Display probe (the patch at hand). Assumes there's no display
hardware, at all. The driver doesn't touch the hardware, which
continues to consume power, it's not put in low power states. Not
optimal if there actually is display hardware.
- Display disable. See intel_display_device_enabled(). The driver takes
over the hardware, puts it to sleep, but prevents all connectors from
being connected.
- eDP disable. Add a quirk somewhere to enforce eDP is disconnected, but
other connectors can be used.
> (tested on iMac20,1)
It would be quite useful to indicate the PCI ID of the device in
question.
>
> Signed-off-by: Atharva Tiwari <atharvatiwarilinuxdev@gmail.com>
> ---
> drivers/gpu/drm/i915/display/intel_display_device.c | 7 +++++++
> 1 file changed, 7 insertions(+)
>
> diff --git a/drivers/gpu/drm/i915/display/intel_display_device.c b/drivers/gpu/drm/i915/display/intel_display_device.c
> index 1170afaa8680..3fb47232e7a4 100644
> --- a/drivers/gpu/drm/i915/display/intel_display_device.c
> +++ b/drivers/gpu/drm/i915/display/intel_display_device.c
> @@ -3,6 +3,7 @@
> * Copyright © 2023 Intel Corporation
> */
>
> +#include <linux/dmi.h>
> #include <linux/pci.h>
>
> #include <drm/drm_color_mgmt.h>
> @@ -1657,6 +1658,7 @@ struct intel_display *intel_display_device_probe(struct pci_dev *pdev,
> const struct platform_desc *desc;
> const struct subplatform_desc *subdesc;
> enum intel_step step;
> + const char *product_name = dmi_get_system_info(DMI_PRODUCT_NAME);
>
> display = kzalloc(sizeof(*display), GFP_KERNEL);
> if (!display)
> @@ -1674,6 +1676,11 @@ struct intel_display *intel_display_device_probe(struct pci_dev *pdev,
> goto no_display;
> }
>
> + if (dmi_match(DMI_BOARD_VENDOR, "Apple Inc.") && !strncmp(product_name, "iMac", 4)) {
> + drm_dbg_kms(display->drm, "iMac Detected, Disabling display\n");
> + goto no_display;
> + }
> +
This function is high level code, its clarity is important, and low
level device specific quirks do not belong here. They are a
distraction. At a minimum this needs to be hidden away in a function
that gets called from has_no_display() or something.
BR,
Jani.
> desc = find_platform_desc(pdev);
> if (!desc) {
> drm_dbg_kms(display->drm,
--
Jani Nikula, Intel
> Rendering and display are quite separate in the hardware and in the > driver. Perhaps you do not mean "rendering" here? Perhaps it can be used > for rendering but not display? Yeah, it can be used for rendering but not display, sorry for the wording. > Okay, so perhaps there's no eDP connected. But what about the other > connectors on the iGPU? What about everything else in the display > hardware? You cant use the iGPU to drive the display on any hardware (including external displays). > If you can figure out that it's specifically link training that fails (a > dmesg would be useful to show this) there clearly is display hardware, > right? As said the iGPU cant drive the display on all monitors (even on macOS), but still heres the dmesg before this patch: [ 5.095489] i915 0000:00:02.0: [drm] Found cometlake (device ID 9bc8) integrated display version 9.00 stepping N/A [ 5.096061] i915 0000:00:02.0: [drm] VT-d active for gfx access [ 5.096102] i915 0000:00:02.0: [drm] Using Transparent Hugepages [ 5.099214] i915 0000:00:02.0: Invalid PCI ROM header signature: expecting 0xaa55, got 0xffff [ 5.099217] i915 0000:00:02.0: [drm] Failed to find VBIOS tables (VBT) [ 5.099324] i915 0000:00:02.0: vgaarb: VGA decodes changed: olddecodes=io+mem,decodes=none:owns=io+mem [ 5.100960] i915 0000:00:02.0: [drm] Finished loading DMC firmware i915/kbl_dmc_ver1_04.bin (v1.4) [ 5.832214] i915 0000:00:02.0: [drm] [ENCODER:105:DDI A/PHY A] failed to retrieve link info, disabling eDP [ 5.835756] i915 0000:00:02.0: [drm] Registered 3 planes with drm panic [ 6.428455] i915 0000:00:02.0: [drm] Cannot find any crtc or sizes [ 6.722404] i915 0000:00:02.0: [drm] Cannot find any crtc or sizes > There's at least three levels where this could be handled, depending on > details: > > - Display probe (the patch at hand). Assumes there's no display > hardware, at all. The driver doesn't touch the hardware, which > continues to consume power, it's not put in low power states. Not > optimal if there actually is display hardware. > > - Display disable. See intel_display_device_enabled(). The driver takes > over the hardware, puts it to sleep, but prevents all connectors from > being connected. > > - eDP disable. Add a quirk somewhere to enforce eDP is disconnected, but > other connectors can be used. The main reason I sent this patch is that after i915 trys to probe the display, the dGPU (amdgpu) is no longer able to detect the internal display, resulting in a black screen. > It would be quite useful to indicate the PCI ID of the device in > question. 00:02.0 VGA compatible controller [0300]: Intel Corporation CometLake-S GT2 [UHD Graphics 630] [8086:9bc8] (rev 03) (prog-if 00 [VGA controller]) Subsystem: Apple Inc. CometLake-S GT2 [UHD Graphics 630] [106b:ffff]
On Mon, 26 Jan 2026, Atharva Tiwari <atharvatiwarilinuxdev@gmail.com> wrote: >> Rendering and display are quite separate in the hardware and in the >> driver. Perhaps you do not mean "rendering" here? Perhaps it can be used >> for rendering but not display? > > Yeah, it can be used for rendering but not display, sorry for the wording. > >> Okay, so perhaps there's no eDP connected. But what about the other >> connectors on the iGPU? What about everything else in the display >> hardware? > > You cant use the iGPU to drive the display on any hardware (including external displays). > >> If you can figure out that it's specifically link training that fails (a >> dmesg would be useful to show this) there clearly is display hardware, >> right? > > As said the iGPU cant drive the display on all monitors (even on macOS), but still heres the dmesg before this patch: > > [ 5.095489] i915 0000:00:02.0: [drm] Found cometlake (device ID 9bc8) integrated display version 9.00 stepping N/A > [ 5.096061] i915 0000:00:02.0: [drm] VT-d active for gfx access > [ 5.096102] i915 0000:00:02.0: [drm] Using Transparent Hugepages > [ 5.099214] i915 0000:00:02.0: Invalid PCI ROM header signature: expecting 0xaa55, got 0xffff > [ 5.099217] i915 0000:00:02.0: [drm] Failed to find VBIOS tables (VBT) > [ 5.099324] i915 0000:00:02.0: vgaarb: VGA decodes changed: olddecodes=io+mem,decodes=none:owns=io+mem > [ 5.100960] i915 0000:00:02.0: [drm] Finished loading DMC firmware i915/kbl_dmc_ver1_04.bin (v1.4) > [ 5.832214] i915 0000:00:02.0: [drm] [ENCODER:105:DDI A/PHY A] failed to retrieve link info, disabling eDP > [ 5.835756] i915 0000:00:02.0: [drm] Registered 3 planes with drm panic > [ 6.428455] i915 0000:00:02.0: [drm] Cannot find any crtc or sizes > [ 6.722404] i915 0000:00:02.0: [drm] Cannot find any crtc or sizes > >> There's at least three levels where this could be handled, depending on >> details: >> >> - Display probe (the patch at hand). Assumes there's no display >> hardware, at all. The driver doesn't touch the hardware, which >> continues to consume power, it's not put in low power states. Not >> optimal if there actually is display hardware. >> >> - Display disable. See intel_display_device_enabled(). The driver takes >> over the hardware, puts it to sleep, but prevents all connectors from >> being connected. At a glance, this seems like the appropriate level. What if you drop patch 2 and supply i915.disable_display=1 module parameter? Or return false from intel_display_device_enabled(). BR, Jani. >> >> - eDP disable. Add a quirk somewhere to enforce eDP is disconnected, but >> other connectors can be used. > > The main reason I sent this patch is that after i915 trys to probe the display, > the dGPU (amdgpu) is no longer able to detect the internal display, > resulting in a black screen. > >> It would be quite useful to indicate the PCI ID of the device in >> question. > > 00:02.0 VGA compatible controller [0300]: Intel Corporation CometLake-S GT2 [UHD Graphics 630] [8086:9bc8] (rev 03) (prog-if 00 [VGA controller]) > Subsystem: Apple Inc. CometLake-S GT2 [UHD Graphics 630] [106b:ffff] -- Jani Nikula, Intel
>At a glance, this seems like the appropriate level. > > What if you drop patch 2 and supply i915.disable_display=1 module > parameter? Or return false from intel_display_device_enabled(). I added the i915.disable_display=1 module parameter and removed the patch , but then the display just goes blank, here are some logs: $ cat /proc/cmdline BOOT_IMAGE=/boot/vmlinuz-6.19.0-rc4+ root=UUID=c058ecbb-6bf6-480c-943a-e8c48a831554 ro pcie_ports=native intel_iommu=on iommu=pt i915.disable_display=1 $ $ sudo cat /sys/module/i915/parameters/disable_display Y $ dmesg | grep i915 [ 5.255798] i915 0000:00:02.0: [drm] Found cometlake (device ID 9bc8) integrated display version 9.00 stepping N/A [ 5.256392] i915 0000:00:02.0: [drm] VT-d active for gfx access [ 5.256437] i915 0000:00:02.0: [drm] Using Transparent Hugepages [ 5.263588] i915 0000:00:02.0: Invalid PCI ROM header signature: expecting 0xaa55, got 0xffff [ 5.263592] i915 0000:00:02.0: [drm] Failed to find VBIOS tables (VBT) [ 5.263698] i915 0000:00:02.0: vgaarb: VGA decodes changed: olddecodes=io+mem,decodes=none:owns=io+mem [ 5.993265] i915 0000:00:02.0: [drm] [ENCODER:105:DDI A/PHY A] failed to retrieve link info, disabling eDP [ 5.994957] mei_hdcp 0000:00:16.0-b638ab7e-94e2-4ea2-a552-d1c54b627f04: bound 0000:00:02.0 (ops i915_hdcp_ops [i915]) [ 6.308891] i915 0000:00:02.0: [drm] Finished loading DMC firmware i915/kbl_dmc_ver1_04.bin (v1.4) [ 6.310598] i915 0000:00:02.0: [drm] Registered 3 planes with drm panic [ 6.310602] [drm] Initialized i915 1.6.0 for 0000:00:02.0 on minor 1 [ 6.314962] i915 0000:00:02.0: [drm] Cannot find any crtc or sizes [ 6.318910] snd_hda_intel 0000:00:1f.3: bound 0000:00:02.0 (ops intel_audio_component_bind_ops [i915]) $ dmesg | grep amdgpu [ 8.655793] [drm] amdgpu kernel modesetting enabled. [ 8.656000] amdgpu: Virtual CRAT table created for CPU [ 8.656025] amdgpu: Topology: Add CPU node [ 8.656191] amdgpu 0000:03:00.0: amdgpu: initializing kernel modesetting (NAVI14 0x1002:0x7340 0x106B:0x0219 0x47). [ 8.656203] amdgpu 0000:03:00.0: amdgpu: register mmio base: 0x81600000 [ 8.656204] amdgpu 0000:03:00.0: amdgpu: register mmio size: 524288 [ 8.660144] amdgpu 0000:03:00.0: amdgpu: detected ip block number 0 <common_v1_0_0> (nv_common) [ 8.660146] amdgpu 0000:03:00.0: amdgpu: detected ip block number 1 <gmc_v10_0_0> (gmc_v10_0) [ 8.660147] amdgpu 0000:03:00.0: amdgpu: detected ip block number 2 <ih_v5_0_0> (navi10_ih) [ 8.660149] amdgpu 0000:03:00.0: amdgpu: detected ip block number 3 <psp_v11_0_0> (psp) [ 8.660150] amdgpu 0000:03:00.0: amdgpu: detected ip block number 4 <smu_v11_0_0> (smu) [ 8.660151] amdgpu 0000:03:00.0: amdgpu: detected ip block number 5 <dce_v1_0_0> (dm) [ 8.660152] amdgpu 0000:03:00.0: amdgpu: detected ip block number 6 <gfx_v10_0_0> (gfx_v10_0) [ 8.660154] amdgpu 0000:03:00.0: amdgpu: detected ip block number 7 <sdma_v5_0_0> (sdma_v5_0) [ 8.660155] amdgpu 0000:03:00.0: amdgpu: detected ip block number 8 <vcn_v2_0_0> (vcn_v2_0) [ 8.660156] amdgpu 0000:03:00.0: amdgpu: detected ip block number 9 <jpeg_v2_0_0> (jpeg_v2_0) [ 8.660172] amdgpu 0000:03:00.0: amdgpu: Fetched VBIOS from VFCT [ 8.660174] amdgpu: ATOM BIOS: 113-D322A1XL-011 [ 8.687707] amdgpu 0000:03:00.0: vgaarb: deactivate vga console [ 8.687710] amdgpu 0000:03:00.0: amdgpu: Trusted Memory Zone (TMZ) feature disabled as experimental (default) [ 8.687766] amdgpu 0000:03:00.0: amdgpu: vm size is 262144 GB, 4 levels, block size is 9-bit, fragment size is 9-bit [ 8.687782] amdgpu 0000:03:00.0: BAR 0 [mem 0xa0000000-0xafffffff 64bit pref]: releasing [ 8.687784] amdgpu 0000:03:00.0: BAR 2 [mem 0xb0000000-0xb01fffff 64bit pref]: releasing [ 8.687798] amdgpu 0000:03:00.0: BAR 0 [mem 0x4100000000-0x41ffffffff 64bit pref]: assigned [ 8.687805] amdgpu 0000:03:00.0: BAR 2 [mem 0x4080000000-0x40801fffff 64bit pref]: assigned [ 8.687842] amdgpu 0000:03:00.0: amdgpu: VRAM: 4080M 0x0000008000000000 - 0x00000080FEFFFFFF (4080M used) [ 8.687843] amdgpu 0000:03:00.0: amdgpu: GART: 512M 0x0000000000000000 - 0x000000001FFFFFFF [ 8.687947] amdgpu 0000:03:00.0: amdgpu: amdgpu: 4080M of VRAM memory ready [ 8.687949] amdgpu 0000:03:00.0: amdgpu: amdgpu: 7918M of GTT memory ready. [ 8.688772] amdgpu 0000:03:00.0: amdgpu: [VCN instance 0] Found VCN firmware Version ENC: 1.21 DEC: 7 VEP: 0 Revision: 2 [ 8.754221] amdgpu 0000:03:00.0: amdgpu: reserve 0x900000 from 0x80fd000000 for PSP TMR [ 8.823385] amdgpu 0000:03:00.0: amdgpu: RAS: optional ras ta ucode is not available [ 8.834600] amdgpu 0000:03:00.0: amdgpu: RAP: optional rap ta ucode is not available [ 8.834603] amdgpu 0000:03:00.0: amdgpu: SECUREDISPLAY: optional securedisplay ta ucode is not available [ 8.834654] amdgpu 0000:03:00.0: amdgpu: use vbios provided pptable [ 8.834656] amdgpu 0000:03:00.0: amdgpu: smc_dpm_info table revision(format.content): 4.5 [ 8.849207] amdgpu 0000:03:00.0: amdgpu: SMU is initialized successfully! [ 8.849532] amdgpu 0000:03:00.0: amdgpu: [drm] Display Core v3.2.359 initialized on DCN 2.0 [ 8.849534] amdgpu 0000:03:00.0: amdgpu: [drm] DP-HDMI FRL PCON supported [ 8.881799] snd_hda_intel 0000:03:00.1: bound 0000:03:00.0 (ops amdgpu_dm_audio_component_bind_ops [amdgpu]) [ 9.011896] amdgpu 0000:03:00.0: amdgpu: kiq ring mec 2 pipe 1 q 0 [ 9.036429] amdgpu: HMM registered 4080MB device memory [ 9.545268] amdgpu 0000:03:00.0: amdgpu: Fence fallback timer expired on ring sdma0 [ 9.545394] kfd kfd: amdgpu: Allocated 3969056 bytes on gart [ 9.545417] kfd kfd: amdgpu: Total number of KFD nodes to be created: 1 [ 10.049267] amdgpu 0000:03:00.0: amdgpu: Fence fallback timer expired on ring sdma0 [ 10.049402] amdgpu: Virtual CRAT table created for GPU [ 10.049521] amdgpu: Topology: Add dGPU node [0x7340:0x1002] [ 10.049523] kfd kfd: amdgpu: added device 1002:7340 [ 10.049539] amdgpu 0000:03:00.0: amdgpu: SE 1, SH per SE 2, CU per SH 12, active_cu_number 20 [ 10.049544] amdgpu 0000:03:00.0: amdgpu: ring gfx_0.0.0 uses VM inv eng 0 on hub 0 [ 10.049546] amdgpu 0000:03:00.0: amdgpu: ring comp_1.0.0 uses VM inv eng 1 on hub 0 [ 10.049547] amdgpu 0000:03:00.0: amdgpu: ring comp_1.1.0 uses VM inv eng 4 on hub 0 [ 10.049548] amdgpu 0000:03:00.0: amdgpu: ring comp_1.2.0 uses VM inv eng 5 on hub 0 [ 10.049549] amdgpu 0000:03:00.0: amdgpu: ring comp_1.3.0 uses VM inv eng 6 on hub 0 [ 10.049550] amdgpu 0000:03:00.0: amdgpu: ring comp_1.0.1 uses VM inv eng 7 on hub 0 [ 10.049550] amdgpu 0000:03:00.0: amdgpu: ring comp_1.1.1 uses VM inv eng 8 on hub 0 [ 10.049551] amdgpu 0000:03:00.0: amdgpu: ring comp_1.2.1 uses VM inv eng 9 on hub 0 [ 10.049552] amdgpu 0000:03:00.0: amdgpu: ring comp_1.3.1 uses VM inv eng 10 on hub 0 [ 10.049553] amdgpu 0000:03:00.0: amdgpu: ring kiq_0.2.1.0 uses VM inv eng 11 on hub 0 [ 10.049554] amdgpu 0000:03:00.0: amdgpu: ring sdma0 uses VM inv eng 12 on hub 0 [ 10.049555] amdgpu 0000:03:00.0: amdgpu: ring sdma1 uses VM inv eng 13 on hub 0 [ 10.049556] amdgpu 0000:03:00.0: amdgpu: ring vcn_dec uses VM inv eng 0 on hub 8 [ 10.049557] amdgpu 0000:03:00.0: amdgpu: ring vcn_enc0 uses VM inv eng 1 on hub 8 [ 10.049558] amdgpu 0000:03:00.0: amdgpu: ring vcn_enc1 uses VM inv eng 4 on hub 8 [ 10.049559] amdgpu 0000:03:00.0: amdgpu: ring jpeg_dec uses VM inv eng 5 on hub 8 [ 10.061446] amdgpu 0000:03:00.0: amdgpu: Runtime PM not available [ 10.061681] amdgpu 0000:03:00.0: amdgpu: [drm] Skipping amdgpu DM backlight registration [ 10.062153] amdgpu 0000:03:00.0: [drm] Registered 5 planes with drm panic [ 10.062155] [drm] Initialized amdgpu 3.64.0 for 0000:03:00.0 on minor 2 [ 10.067637] fbcon: amdgpudrmfb (fb0) is primary device [ 10.067724] amdgpu 0000:03:00.0: [drm] fb0: amdgpudrmfb frame buffer device $ xrandr Can't open display
On Tue, 27 Jan 2026, Atharva Tiwari <atharvatiwarilinuxdev@gmail.com> wrote:
>>At a glance, this seems like the appropriate level.
>>
>> What if you drop patch 2 and supply i915.disable_display=1 module
>> parameter? Or return false from intel_display_device_enabled().
>
> I added the i915.disable_display=1 module parameter and removed the patch
> , but then the display just goes blank, here are some logs:
Mmh, okay. Honestly, I still feel like this would be the better thing to
do, but I don't think I have the time to debug this further. Feels like
a rabbit hole. ;)
So I guess let's go with ignoring display completely. The way to go is
to extend has_no_display() with a struct dmi_system_id array, and use
dmi_check_system() on it. Even if it's just one, it'll be so much easier
to extend later on.
Something like this, completely untested of course:
static bool has_no_display(struct pci_dev *pdev)
{
static const struct pci_device_id ids[] = {
INTEL_IVB_Q_IDS(INTEL_VGA_DEVICE, 0),
{}
};
static const struct dmi_system_id dmi_ids[] = {
{
.ident = "Apple iMac",
.matches = {
DMI_EXACT_MATCH(DMI_BOARD_VENDOR, "Apple Inc."),
DMI_EXACT_MATCH(DMI_PRODUCT_NAME, "iMac"),
}
},
{}
};
return pci_match_id(ids, pdev) || dmi_check_system(dmi_ids);
}
Finally, it would really be super helpful if you could file a bug at the
fdo gitlab as described at [1], along with the full dmesg with debugs
enabled, running just patch 1, and then you could reference that issue
in the commit. So we'd have some info for posterity of what's actually
going on.
Thanks,
Jani.
--
Jani Nikula, Intel
© 2016 - 2026 Red Hat, Inc.