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

[Jani Nikula <jani.nikula@linux.intel.com>]

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