How to drive an external monitor that does not send hotplug info over HDMI?

Since a few days I have the Dasung Paperlike HD device and after using it for one day I'm afraid the utility that comes with it, did something it shouldn't have done. **Hot-plug events** First, of all, it doesn't seem to receive hot-plug information over HDMI (anymore). The so-called HPD (hot-plug detect) signal carried through pin 19 (see [wikipedia](https://en.wikipedia.org/wiki/HDMI)) does not seem to arrive. **Manually enable** We can override this (our interface is DP-1):

echo 'on-digital' | sudo tee /sys/class/drm/card0-DP-1/status

Now we can read the EDID information through edid-decode /sys/class/drm/card0-DP-1/edid

edid-decode (hex):

00 ff ff ff ff ff ff 00 12 63 01 00 00 00 00 00 
0a 1d 01 03 80 14 0f 78 2a 08 a5 a2 57 4f a2 28 
0f 50 54 00 00 00 01 01 01 01 01 01 01 01 01 01 
01 01 01 01 01 01 c1 3e 98 a8 80 72 2e 60 38 20 
36 00 c8 96 00 00 00 1e 00 00 00 10 00 00 00 00 
00 00 00 00 00 00 00 00 00 00 00 00 00 fc 00 50 
61 70 65 72 6c 69 6b 65 20 48 20 44 48 3f 40 30 
62 b0 32 40 40 c0 13 00 6d 55 21 00 00 1e 00 d1 

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

EDID version: 1.3
Manufacturer: DSC Model 1 Serial Number 0
Made in week 10 of 2019
Digital display
Maximum image size: 20 cm x 15 cm
Gamma: 2.20
DPMS levels: Off
RGB color display
First detailed timing is preferred timing
Color Characteristics
  Red:   0.6328, 0.3398
  Green: 0.3105, 0.6328
  Blue:  0.1582, 0.0605
  White: 0.3134, 0.3291
Established Timings I & II: none
Standard Timings: none
Detailed mode: Clock 160.650 MHz, 200 mm x 150 mm
               2200 2256 2288 2368 ( 56  32  80)
               1650 1653 1659 1696 (  3   6  37)
               +hsync +vsync
               VertFreq: 40.001 Hz, HorFreq: 67.842 kHz
Dummy Descriptor
Display Product Name: Paperlike H D
Detailed mode: Clock 162.000 MHz, 621 mm x 341 mm
               1600 1664 1856 2160 ( 64 192 304)
               1200 1201 1204 1250 (  1   3  46)
               +hsync +vsync
               VertFreq: 60.000 Hz, HorFreq: 75.000 kHz
Checksum: 0xd1

The checksum is correct. We use the indicated modelines to manually configure the interface

xrandr --newmode "Low-res" 162.000 1600 1664 1856 2160 1200 1201 1204 1250 +hsync +vsync
xrandr --addmode DP-1 "Low-res"
xrandr --output DP-1 --mode "Low-res"

# Bug This leads to the following trace (with dmesg -w):

[  760.510138] ------------[ cut here ]------------
[  760.510140] WARN_ON(len  0b b8 d0 78 02 00 5d c3 0f 1f 40 00 0f 1f 44 00 00 55 48 89 e5
[  760.510316] RSP: 0018:ffffacbf40ebbb40 EFLAGS: 00010286
[  760.510318] RAX: 0000000000000000 RBX: ffff98275e83a000 RCX: 0000000000000000
[  760.510319] RDX: 0000000000000011 RSI: ffffffff88f945b1 RDI: 0000000000000246
[  760.510320] RBP: ffffacbf40ebbb40 R08: ffffffff88f945a0 R09: 0000000000000011
[  760.510321] R10: ffffffff88f94980 R11: 0000000088f9459f R12: ffff9826fda56800
[  760.510322] R13: 00000000000a4cb8 R14: ffff982766680000 R15: 00000000000278d0
[  760.510324] FS:  00007f8f40701a80(0000) GS:ffff98276b300000(0000) knlGS:0000000000000000
[  760.510325] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[  760.510326] CR2: 00007f0bb409b703 CR3: 0000000228540002 CR4: 00000000003606e0
[  760.510329] Call Trace:
[  760.510369]  intel_dp_mode_valid+0xb6/0x240 [i915]
[  760.510383]  drm_helper_probe_single_connector_modes+0x412/0x740 [drm_kms_helper]
[  760.510406]  drm_mode_getconnector+0x47d/0x4b0 [drm]
[  760.510409]  ? radix_tree_lookup+0xd/0x10
[  760.510428]  ? drm_connector_property_set_ioctl+0x60/0x60 [drm]
[  760.510440]  drm_ioctl_kernel+0xae/0xf0 [drm]
[  760.510451]  drm_ioctl+0x234/0x3d0 [drm]
[  760.510471]  ? drm_connector_property_set_ioctl+0x60/0x60 [drm]
[  760.510476]  ? __fsnotify_parent+0x9f/0x140
[  760.510478]  do_vfs_ioctl+0x407/0x670
[  760.510482]  ksys_ioctl+0x67/0x90
[  760.510484]  __x64_sys_ioctl+0x1a/0x20
[  760.510487]  do_syscall_64+0x57/0x190
[  760.510490]  entry_SYSCALL_64_after_hwframe+0x44/0xa9
[  760.510491] RIP: 0033:0x7f8f40a6137b
[  760.510493] Code: 0f 1e fa 48 8b 05 15 3b 0d 00 64 c7 00 26 00 00 00 48 c7 c0 ff ff ff ff c3 66 0f 1f 44 00 00 f3 0f 1e fa b8 10 00 00 00 0f 05  3d 01 f0 ff ff 73 01 c3 48 8b 0d e5 3a 0d 00 f7 d8 64 89 01 48
[  760.510494] RSP: 002b:00007ffd3eb26108 EFLAGS: 00003246 ORIG_RAX: 0000000000000010
[  760.510497] RAX: ffffffffffffffda RBX: 00007ffd3eb26150 RCX: 00007f8f40a6137b
[  760.510498] RDX: 00007ffd3eb26150 RSI: 00000000c05064a7 RDI: 000000000000000e
[  760.510499] RBP: 00000000c05064a7 R08: 0000000000000007 R09: 0000000000000190
[  760.510500] R10: 0000000000000140 R11: 0000000000003246 R12: 0000000000000001
[  760.510501] R13: 000000000000000e R14: 00007ffd3eb26150 R15: 0000000000000000
[  760.510503] ---[ end trace 706fd3d45f136b1f ]---

Apparently in the following function the i915 module does receive a value equal or smaller than 0 as return value of intel_dp_common_len_rate_limit.

int
intel_dp_max_link_rate(struct intel_dp *intel_dp)
{
	int len;

	len = intel_dp_common_len_rate_limit(intel_dp, intel_dp->max_link_rate);
	if (WARN_ON(len common_rates[len - 1];
}

I've also copied the edid data to /lib/firmware/edid/paperlike.bin and added the kernel commandline parameter drm_kms_helper.edid_firmware=edid/paperlike.bin. However, this doesn't make much of a difference. I think that's logical. It's not that the EDID information is not available. It's that the hot-plug pin is not set and so the entire screen is not considered to be connected. By manually setting it to be connected, the EDID information can be retrieved. However, actually sending data to it, doesn't work. My guess is that I've to do something else to override the hot-plug behaviour, but what? **Current situation** The current situation is that the Paperlike HD screen stays blank. Nothing happens. The USB part of it works though (it is a touchscreen). When setting the output with xrandr (as indicated above) it gives:

xrandr: Configure crtc 1 failed

It feels like I'm close to solving this riddle, however, I definitely need help here.