linux-kernel - Re: [PATCH 2/2] drm/i915/display: Disable display for iMac's

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <20260126204915.1324-1-atharvatiwarilinuxdev@gmail.com>
Date: Mon, 26 Jan 2026 20:49:15 +0000
From: Atharva Tiwari <atharvatiwarilinuxdev@...il.com>
To: jani.nikula@...ux.intel.com
Cc: airlied@...il.com,
	atharvatiwarilinuxdev@...il.com,
	dri-devel@...ts.freedesktop.org,
	intel-gfx@...ts.freedesktop.org,
	intel-xe@...ts.freedesktop.org,
	joonas.lahtinen@...ux.intel.com,
	linux-kernel@...r.kernel.org,
	rodrigo.vivi@...el.com,
	simona@...ll.ch,
	tursulin@...ulin.net,
	ville.syrjala@...ux.intel.com
Subject: Re: [PATCH 2/2] drm/i915/display: Disable display for iMac's

> 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]