Bug 215773 - Internal display turns on but stays black after resume from S3 sleep until reboot
Summary: Internal display turns on but stays black after resume from S3 sleep until re...
Status: RESOLVED INVALID
Alias: None
Product: Drivers
Classification: Unclassified
Component: Video(Other) (show other bugs)
Hardware: All Linux
: P1 normal
Assignee: drivers_video-other
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2022-03-29 23:33 UTC by Alex
Modified: 2023-05-26 14:38 UTC (History)
2 users (show)

See Also:
Kernel Version: 5.17.1
Subsystem:
Regression: No
Bisected commit-id:


Attachments
Output of lspci (17.06 KB, text/plain)
2022-03-29 23:33 UTC, Alex
Details
EDID of 2020 GPD Win Max (128 bytes, application/octet-stream)
2022-04-15 10:10 UTC, Alex
Details
EDID of 2021 GPD Win Max - AMD Ryzen 7 4800U (amdgpu successfully resumes this) (128 bytes, application/octet-stream)
2022-04-15 10:11 UTC, Alex
Details

Description Alex 2022-03-29 23:33:44 UTC
Created attachment 300642 [details]
Output of lspci

Overview: 
    -  The machine enters S3 sleep successfully.  
    -  When resuming from S3 sleep, the internal display activates and "turns every pixel black"
    -  All other aspects of the machine (audio, networking, external displays) resume properly, but the internal display stays black.  

Steps to Reproduce: 
    1) Cold boot.  
    2) Close the lid (or initiate S3 sleep).
    3) Open the lid (or resume the machine)

Actual Results: 
    -  The internal display stays black.
    -  xrandr shows the display as connected, and can turn it off and on.
    -  Backlight control is fine.  
    -  External displays connected resume correctly, and have no issues.
    -  Internal display still forms part of Screen :0, but every single pixel on the display stays black.  
    -  A reboot fixes the issue.  

Expected Results: 

    The internal display should not show just black, and should reinitialise correctly.  

What does not fix the issue:
    -  xset dpms force off
    -  Turning the display off and on using sysfs

Build Date & Hardware: 

    Build 2022-03-28 - GPD Win Max 2021 - Intel i7-1195G7
    Build 2022-03-28 - GPD Pocket 3 - Intel i7-1195G7

Additional Information: 
    -  Literally EVERY single kernel I have tried has this issue
    -  The machine is currently a testing machine. Not doing any critical work on it.  
    -  This is NOT related to:
          -  Bug #201553 (Screen rotation is fine)
          -  Bug #199207 (No I2C issues)
          -  https://gitlab.freedesktop.org/drm/intel/-/issues/3454 (The display is MIPI-DSI, not eDP)
Comment 1 Alex 2022-04-15 10:10:24 UTC
Created attachment 300761 [details]
EDID of 2020 GPD Win Max
Comment 2 Alex 2022-04-15 10:11:01 UTC
Created attachment 300762 [details]
EDID of 2021 GPD Win Max - AMD Ryzen 7 4800U (amdgpu successfully resumes this)
Comment 3 RWahler 2022-08-21 14:36:39 UTC
I have an GPD Pocket 1 and have the same problem.

Don't know if it helps, but here is a forum thread where this problem is discussed a bit further:
https://ubuntu-mate.community/t/gpd-pocket-3-s3-sleep-waiting-for-kernel-fix/25053

They expect the problem to be in the missing re-initialization of the internal display port to mipi-dsi converter chip LT7911D.
Comment 4 Alex 2022-09-18 03:02:05 UTC
> Don't know if it helps, but here is a forum thread where this problem is
> discussed a bit further:
>
> https://ubuntu-mate.community/t/gpd-pocket-3-s3-sleep-waiting-for-kernel-fix/25053

> They expect the problem to be in the missing re-initialization of the
> internal display port to mipi-dsi converter chip LT7911D.

I know. That was me who wrote that. 

I’ve been at this for years, trying to make this work.  

It’s persisted across multiple kernel versions. 

On multiple occasions, I have asked GPD for some info about reset pins, how they’ve wired their PCBs, and even the “custom drivers” they appear to be in possession of, and they have completely stonewalled me. 

I’ve tried reverse-engineering the “Windows drivers”, and managed to extract the EDID, but that didn’t appear to help. 

I’ve tried so many kernelopts, boot parameters, and playing around in sysfs debug options, but I wish I knew what I was looking for…

I’m even willing to give someone one of these laptops for testing, and they can even KEEP IT afterwards if they can come up with a fix. That should show how far I’m willing to go to get this fixed.

Note You need to log in before you can comment on or make changes to this bug.