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 
.
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:
DSI-1 with the following EDIDs I dumped from working models:
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
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:
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 
), 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
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=
I honestly don’t think the EDID is the problem.
On cold boot:
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.
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):
Welcome @Rob_Wood to the community!