GPD Pocket 3 S3 sleep "waiting for kernel fix"

I've been trying to figure out how to get my GPD Pocket 3 to sleep properly.

I saw that currently, s2_idle is used, with a comment that when a commit makes it to the kernel, s3 should work.

I wanted to ask, was anything done to check that the kernel fix allows the GPD Pocket 3 specifically to sleep? I've tried "everything" on mine, including a newer kernel (5.17), and haven't had any luck.

Hi @bobobo1618, I have a Pocket 3, a Win Max 2020 (i5-1035G7), a Win Max 2021 Intel (i7-1195G7), and a Win Max 2021 AMD (Ryzen 7 4800U). I do testing for various distros.

The Intel GPD models have always done the same thing that the Pocket 3 currently does when suspending from S3 sleep.

The thing is, it already does sleep properly. The device has no issues under GNU/Linux to successfully S3 suspend. It also is able to resume out of S3 sleep. Everything resumes properly, except the internal display stays black.

If you plug in an external display into either the HDMI or USB-C port, it'll turn on properly and show your desktop. If you have sshd enabled, you should be able to remotely log into your machine. Audio works fine. You can still control the internal display's backlight after resuming from S3 sleep. You could even "use your computer blind" and bring up a terminal and type sudo reboot if you wanted to, and your machine would reboot normally.

To make things even worse, the Linux kernel thinks everything has resumed successfully... The logs show NO ERRORS at all....

Yes, setting sleep mode to s2idle in the kernelopts technically is better than nothing, but I wouldn't put it in any case or backpack while it's in S2 sleep. It'll eventually overheat...

And no, that commit didn't seem to work when I tried it in 5.18.0-rc2, and I really wish it had :frowning: .

GPD's ACPI tables have always been a bit of a "black box" for the Linux kernel, unfortunately. To be fair, they built their machines purely to run Windows, and they contain all the things necessary to do that.

The most likely issue, as far as I can tell, is the I2C Lontium LT7911D converter that converts the DisplayPort output from the Intel Iris Xe graphics into the MIPI-DSI that the display panel then shows on your screen.

This chip is present in the 2021 Intel Win Max as well as the Pocket 3, which is why you get the black screen from S3 resume, but the kernel seems to think that everything has been resumed properly.

The original Win Max doesn't use this chip. It uses the TV080WUM-NL0, which the Linux kernel has had drivers for for quite a few years now...

I have looked in quite a few branches of the Linux kernel, and there doesn't seem to be any mention of the LT7911D in it at all (there are drivers for other Lontium chips, though). This means that potentially someone will have to write a driver from scratch, reverse-engineer the Windows driver, or someone at Lontium could "do the right thing" and submit their code to Linus' tree. That way, no Linux-based OS would have this issue ever again.

I'm pretty sure there's some sort of driver (or initialising code) in the BIOS, which is why it initialises properly from cold boot. But it then hands the display over to the Linux kernel (or Windows), which then takes care of the display functions, and Linux just has no idea what it even is, let alone how to reset it after waking from sleep...

The Windows drivers work fine, but they only come in binary format, not source code. If there was an accessible copy of the source code, it would take a week max to get a driver into the Mainline kernel, and problem solved.

What I have tried already:

  • Overriding the EDID for DSI-1 with the following EDIDs I dumped from working models:
    • GPD Win Max 2020 EDID:
edid-decode (hex):

00 ff ff ff ff ff ff 00 09 e5 03 00 03 00 00 00
01 1d 01 03 80 0b 11 78 2f 00 00 a0 57 49 9b 26
10 48 4f 00 00 00 01 01 01 01 01 01 01 01 01 01
01 01 01 01 01 01 c2 1a 20 50 30 00 10 50 10 10
32 00 6c ac 00 00 00 18 00 00 00 fc 00 54 56 30
38 30 57 55 4d 2d 4e 4c 30 0a 00 00 00 fd 00 3c
3c 10 10 07 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 c3

----------------

Block 0, Base EDID:
  EDID Structure Version & Revision: 1.3
  Vendor & Product Identification:
    Manufacturer: BOE
    Model: 3
    Serial Number: 3
    Made in: week 1 of 2019
  Basic Display Parameters & Features:
    Digital display
    Maximum image size: 11 cm x 17 cm
    Gamma: 2.20
    DPMS levels: Off
    RGB color display
    Default (sRGB) color space is primary color space
    First detailed timing is the preferred timing
    Supports GTF timings within operating range
  Color Characteristics:
    Red  : 0.6250, 0.3398
    Green: 0.2851, 0.6054
    Blue : 0.1484, 0.0625
    White: 0.2812, 0.3085
  Established Timings I & II: none
  Standard Timings: none
  Detailed Timing Descriptors:
    DTD 1:   800x1280   60.062 Hz   5:8    77.841 kHz   68.500 MHz (108 mm x 172 mm)
                 Hfront   16 Hsync  16 Hback  48 Hpol N
                 Vfront    3 Vsync   2 Vback  11 Vpol N
    Display Product Name: 'TV080WUM-NL0'
  Display Range Limits:
    Monitor ranges (GTF): 60-60 Hz V, 16-16 kHz H, max dotclock 70 MHz
    Empty Descriptor
Checksum: 0xc3
  • GPD Win Max 2021 AMD
edid-decode (hex):

00 ff ff ff ff ff ff 00 02 96 00 08 59 51 00 00
24 1f 01 03 a5 0b 11 78 3a f6 3d a3 55 4e 9e 27
0d 47 4a 21 08 00 01 01 01 01 01 01 01 01 01 01
01 01 01 01 01 01 bb 1a 20 50 30 00 10 50 10 10
84 00 20 00 35 00 00 1e 00 00 00 fe 00 4c 54 37
39 31 31 44 31 38 31 32 30 33 00 00 00 fd 00 18
50 14 64 0a 00 0a 20 20 20 20 20 20 00 00 00 fc
00 4c 54 37 39 31 31 44 0a 20 20 20 20 20 00 11

----------------

Block 0, Base EDID:
  EDID Structure Version & Revision: 1.3
  Vendor & Product Identification:
    Manufacturer: @TV
    Model: 2048
    Serial Number: 20825
    Made in: week 36 of 2021
  Basic Display Parameters & Features:
    Digital display
    DFP 1.x compatible TMDS
    Maximum image size: 11 cm x 17 cm
    Gamma: 2.20
    DPMS levels: Off
    Undefined display color type
    First detailed timing is the preferred timing
  Color Characteristics:
    Red  : 0.6396, 0.3349
    Green: 0.3056, 0.6191
    Blue : 0.1523, 0.0537
    White: 0.2802, 0.2900
  Established Timings I & II:
    DMT 0x04:   640x480    59.940 Hz   4:3    31.469 kHz   25.175 MHz
    DMT 0x09:   800x600    60.317 Hz   4:3    37.879 kHz   40.000 MHz
    DMT 0x10:  1024x768    60.004 Hz   4:3    48.363 kHz   65.000 MHz
  Standard Timings: none
  Detailed Timing Descriptors:
    DTD 1:   800x1280   60.001 Hz   5:8    77.761 kHz   68.430 MHz (800 mm x 1280 mm)
                 Hfront   16 Hsync  16 Hback  48 Hpol P
                 Vfront    8 Vsync   4 Vback   4 Vpol P
    Alphanumeric Data String: 'LT7911D181203'
  Display Range Limits:
    Monitor ranges (GTF): 24-80 Hz V, 20-100 kHz H, max dotclock 100 MHz
    Display Product Name: 'LT7911D'
Checksum: 0x11

Using the EDID from the AMD Win Max did not work, which is surprising, because the AMD version of the Win Max can reinitialise the display from S3 sleep perfectly, and I assumed that the 2021 Win Max Intel had the same components...

What I am still trying, but with little success:

  • Patching the i915 drivers to reset the i2c pins one by one until the display turns back on. Essentially playing "russian roulette" with GPIO pins (obviously, don't do this unless you know what you're doing, and you don't care if you break your machine...)
  • Trying to find any kind of firmware/driver (even in source code) for the LT7911D.

Mainline Kernel Bug Report:
https://bugzilla.kernel.org/show_bug.cgi?id=215773

So, unless you're interested in writing a driver and submitting a merge request (please please PLEASE go for it if you are :slight_smile: ), you're just going to have to wait until someone commits a driver, unfortunately....


I hope I've explained this well enough, so that you know what's going on :slight_smile:

There seems to be some code in various Linux kernel forks, have you seen any of the following?
Sign in to GitHub · GitHub
History for drivers/media/i2c/lt7911d.c - Caesar-github/kernel_linux_rk · GitHub

I do remember that my Dell 9350 had issues not waking up the display after resume back in 2015/2016 when it was first released. It was soon fixed and it was the same story: suspend/resume works, just the display does not wake up because of some GPIO pin fiddling was required.

I was worried that Pocket3 is not as "simple" as this, because it looks like that Intel removed S3 support entirely and replaced with S0ix. However, Linux still indicates that Pocket3 has S3 support while S0ix is not there. So I am confused and really wish that the problem is only the screen resume.

In that case, if we had similar issue with laptops in 2015, why can't we do the same fix once again for this machine?

I am currently compiling a mainline kernel with that driver patched into it. Let's see what happens. I will report as soon as it's finished.

It would make sens that android would make full support for it. It was designed for phones....

Hi,

Did you have any success with the driver ? It looks like this driver is written for DT matching, ACPI matching may need to be added.

Maybe I've overlooked something, but I haven't found anything related to LT7911D in ACPI table.

EDID dumped on Windows:

edid-decode (hex):

00 ff ff ff ff ff ff 00 36 7f 00 00 00 00 00 00
00 1f 01 03 a5 0b 11 78 2f 00 00 a0 57 49 9b 26
10 48 4f 00 00 00 01 01 01 01 01 01 01 01 01 01
01 01 01 01 01 01 43 3e b0 8d 40 80 3d 70 3c 01
91 04 00 00 00 00 00 18 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 f9

----------------

Block 0, Base EDID:
  EDID Structure Version & Revision: 1.3
  Vendor & Product Identification:
    Manufacturer: MS_
    Model: 0
    Made in: 2021
  Basic Display Parameters & Features:
    Digital display
    DFP 1.x compatible TMDS
    Maximum image size: 11 cm x 17 cm
    Gamma: 2.20
    DPMS levels: Off
    RGB color display
    Default (sRGB) color space is primary color space
    First detailed timing is the preferred timing
    Supports GTF timings within operating range
  Color Characteristics:
    Red  : 0.6250, 0.3398
    Green: 0.2851, 0.6054
    Blue : 0.1484, 0.0625
    White: 0.2812, 0.3085
  Established Timings I & II: none
  Standard Timings: none
  Detailed Timing Descriptors:
    DTD 1:  1200x1920   59.999526 Hz   5:8    118.859 kHz    159.390000 MHz
                 Hfront   60 Hsync   1 Hback   80 Hpol N
                 Vfront   25 Vsync   1 Vback   35 Vpol N
    Empty Descriptor
    Empty Descriptor
    Empty Descriptor
Checksum: 0xf9

The repo containing that lt7911d.c file has a lot of missing links in it, so I’m still going through all of them. Haven’t had a successful build yet, but it’s only a matter of time.

An interesting thing about that driver is that it’s written as a camera module. But in any case, the reset pins are in the code, so it’s basically just trial and error from here on out.

There wouldn’t be. GPD appears to have connected it as an intermediary module between the GPU and the DSI panel. In a perfect world, the GPU would reset it properly (and the Windows drivers seem to do that, but I still have no idea why….), but not if the Linux kernel doesn’t know it’s actually there….

Hopefully this will help….

Oh brilliant!

Any chance of the verbose output of that?

(I have a nasty habit of purging Windows from my machines as soon as I get my hands on them….)

Maybe because it is connected directly to DSI interface without eDP to MIPI converter.
Also, apparently, intel DSI driver doesn't understand EDID. I was unable to pass binary dumped from windows to it.

Here is a full binary as base64 string since I can't attach binary files:

AP///////wA2fwAAAAAAAAAfAQOlCxF4LwAAoFdJmyYQSE8AAAABAQEBAQEBAQEBAQEBAQEBQz6wjUCAPXA8AZEEAAAAAAAYAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAPk=

1 Like

I honestly don’t think the EDID is the problem.

On cold boot:

  • All resolutions show up completely fine
  • Changing the resolution, even to a non-standard one, does not produce the same black screen as when resuming from S3 sleep
  • You can turn the display off and on (even repeatedly over and over again), and it behaves normally, and doesn’t show the black screen

I could be wrong, though…

———

The ACPI tables do have some entries for things that the Linux kernel does not recognise, so there is a chance that one of those is the elusive reset that we’ve been looking for….

Here it is

edid-decode /media/data/dspinfo.bin -V
edid-decode (hex):

00 ff ff ff ff ff ff 00 36 7f 00 00 00 00 00 00
00 1f 01 03 a5 0b 11 78 2f 00 00 a0 57 49 9b 26
10 48 4f 00 00 00 01 01 01 01 01 01 01 01 01 01
01 01 01 01 01 01 43 3e b0 8d 40 80 3d 70 3c 01
91 04 00 00 00 00 00 18 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 f9

----------------

Block 0, Base EDID:
  EDID Structure Version & Revision: 1.3
  Vendor & Product Identification:
    Manufacturer: MS_
    Model: 0
    Made in: 2021
  Basic Display Parameters & Features:
    Digital display
    DFP 1.x compatible TMDS
    Maximum image size: 11 cm x 17 cm
    Gamma: 2.20
    DPMS levels: Off
    RGB color display
    Default (sRGB) color space is primary color space
    First detailed timing is the preferred timing
    Supports GTF timings within operating range
  Color Characteristics:
    Red  : 0.6250, 0.3398
    Green: 0.2851, 0.6054
    Blue : 0.1484, 0.0625
    White: 0.2812, 0.3085
  Established Timings I & II: none
  Standard Timings: none
  Detailed Timing Descriptors:
    DTD 1:  1200x1920   59.999526 Hz   5:8    118.859 kHz    159.390000 MHz
        #define V4L2_DV_BT_1200X1920P59_100 { \
                .type = V4L2_DV_BT_656_1120, \
                V4L2_INIT_BT_TIMINGS(1200, 1920, 0, 0, \
                        159390000ULL, 60, 1, 80, 25, 1, 35, 0, 0, 0, \
                        0, \
                        V4L2_DV_FL_HAS_PICTURE_ASPECT, \
                        { 5, 8 }, 0, 0) \
        }
    Empty Descriptor
    Empty Descriptor
    Empty Descriptor
Checksum: 0xf9

I honestly don’t think the EDID is the problem.

I feel the same.

1 Like

The code needs a bit of tweaking.

I've had 10 builds where lt7911d.c wasn't even touched, and I'm trying to get it included in the kernel. I also have another build where I'm trying to include it as a module.

did anyone find a solution to this?

There is some LT7911D kernel driver code at this link, but looks like they were struggling with it too (I have not yet looked at it myself):

1 Like

Welcome @Rob_Wood to the community!