[BUG] ACPI/i915: Dell Inspiron 5567 fails to resume from S3 (black screen), DSDT patch included

[Bandhan Pramanik <bandhanpramanik06.foss@gmail.com>]

Hello everyone,

I am reporting a long-standing bug on the Dell Inspiron 5567 that causes 
it to fail when resuming from S3 sleep, resulting in a black screen. 
This issue has been present for years, including on Windows.

After a deep investigation, I've traced the root cause to a logical flaw 
in the vendor's ACPI DSDT and have tried to develop a patch addressing 
that. However, a final experiment has left me with a question about the 
interaction between the ACPI code and the i915 driver, and I am seeking 
expert insight.

Firstly, the original DSDT in the _PTS method calls the sleep trigger 
(SLPE = One) before setting a critical flag (AES3 = One), meaning the 
flag is never set for S3 sleep.

The faulty code:

Method (SPTS, 1, NotSerialized)
{
     SLPX = One
     SLPE = One
     If ((Arg0 == 0x03))
     {
         AES3 = One
     }
}

My fix was to reorder the operations to ensure AES3 is set before 
sleeping. With this patch, loaded via a GRUB override, S3 suspend and 
resume are perfectly stable.

Working patch:

diff --git a/dsdt.dsl b/dsdt.dsl
index f30aef6..b6fb883 100644
--- a/dsdt.dsl
+++ b/dsdt.dsl
@@ -4359,11 +4359,11 @@ DefinitionBlock ("", "DSDT", 2, "DELL  ", 
"CBX3   ", 0x01072009)
                  Method (SPTS, 1, NotSerialized)
                  {
                      SLPX = One
-                    SLPE = One
                      If ((Arg0 == 0x03))
                      {
                          AES3 = One
                      }
+                    SLPE = One
                  }

                  Method (SWAK, 1, NotSerialized)

(Note: I also confirmed that the _WAK sequence explicitly clears this 
flag (AES3 = Zero), more specifically in the SWAK method of DSDT, which 
supports the theory that it is part of an intended state machine.)

Now, here comes the main part.

The _WAK sequence on this machine calls a graphics-specific method, 
_SB.PCI0.GFX0.IUEH, which is defined in a secondary ACPI table (SSDT). 
This method appears to be responsible for display re-initialization 
after waking.

To confirm its role, I created an experimental patch where I commented 
out the calls to IUEH inside the RWAK method. I expected this to 
reliably cause a black screen on resume.

Surprisingly, it did not. The system still resumed and the display 
turned on, even though my patched ACPI table with the disabled IUEH 
calls was successfully loaded (confirmed via dmesg: "ACPI: DSDT ACPI 
table found in initrd...").

Here are the questions:

1) Is the i915 driver "saving the day?" Does the kernel's native i915 
driver handle the entire display resume sequence on its own, making the 
ACPI IUEH call redundant on a modern Linux system?

2) What is the failure mechanism? If the i915 driver is doing the work, 
why does the black screen bug happen in the first place? Does the 
driver's resume sequence depend on a specific hardware state that is 
only correctly configured when my AES3 = One patch is applied before sleep?

3) How can I debug this further? Are there specific tracepoints or debug 
flags in the i915 driver I can enable to see where the resume sequence 
fails when AES3 is not set?

Here is the full acpidump for review: 
https://gist.githubusercontent.com/BandhanPramanik/3e5350019b513c0d32afed1f22dbaf42/raw/1f44ddcfb17277ce282cf03f9aab2f91bec1bd30/acpidump

Thank you for your time and for maintaining these critical subsystems.

Bandhan Pramanik
বন্ধন প্রামাণিক