# Configurar monitor ultrawide 21:9 via HDMI 2.1
**Session ID:** ses_03687fa7dffeg1Gun9oO7z2Ay6
**Created:** 8/3/2026, 6:11:53 PM
**Updated:** 8/3/2026, 6:45:35 PM
---
## User
estou com monitor ultrawid conectado, o caboi é hdmi 2.1 e nao consigo configurar 21:9
---
## Assistant (Plan · DeepSeek V4 Pro · 9.0s)
_Thinking:_
The user is having an issue with an ultrawide monitor connected via HDMI 2.1 and can't configure the 21:9 aspect ratio. This is a Linux system. I need to help them debug this display issue. Let me gather some information about their system.
Since I'm in plan mode (read-only), I can only read/inspect. Let me check their display configuration, GPU drivers, and monitor detection.
**Tool: bash**
**Input:**
```json
{
"command": "xrandr 2>/dev/null || echo \"xrandr not available\""
}
```
**Output:**
```
Screen 0: minimum 16 x 16, current 1829 x 1029, maximum 32767 x 32767
HDMI-A-1 connected primary 1829x1029+0+0 (normal left inverted right x axis y axis) 601mm x 254mm
1829x1029 59.87*+
1280x1024 59.89
1280x960 59.94
1152x864 59.96
1024x768 59.92
800x600 59.86
640x480 59.38
320x240 59.29
1440x900 59.89
1280x800 59.81
1152x720 59.97
960x600 59.63
928x580 59.88
800x500 59.50
768x480 59.90
720x480 59.71
640x400 59.95
320x200 58.14
1600x900 59.95
1368x768 59.88
1280x720 59.86
1024x576 59.90
864x486 59.92
720x400 59.27
640x350 59.28
```
**Tool: bash**
**Input:**
```json
{
"command": "lspci -k | grep -A 3 -i \"vga\\|3d\\|display\" 2>/dev/null"
}
```
**Output:**
```
00:02.0 VGA compatible controller: Intel Corporation Iris Plus Graphics G1 (Ice Lake) (rev 07)
Subsystem: Dell Device 0ab3
Kernel driver in use: i915
Kernel modules: i915
--
02:00.0 Non-Volatile memory controller: Sandisk Corp SanDisk Ultra 3D / WD Blue SN570 NVMe SSD (DRAM-less)
Subsystem: Sandisk Corp SanDisk Ultra 3D / WD Blue SN570 NVMe SSD (DRAM-less)
Kernel driver in use: nvme
Kernel modules: nvme
```
**Tool: bash**
**Input:**
```json
{
"command": "cat /sys/class/drm/*/edid 2>/dev/null | parse-edid 2>/dev/null || echo \"parse-edid not available\"; ls /sys/class/drm/ 2>/dev/null"
}
```
**Output:**
```
Section "Monitor"
Identifier ""
ModelName ""
VendorName "LGD"
# Monitor Manufactured week 0 of 2021
# EDID version 1.4
# Digital Display
DisplaySize 340 190
Gamma 2.20
Option "DPMS" "false"
Modeline "Mode 0" +hsync -vsync
Modeline "Mode 1" +hsync -vsync
EndSection
card0
card0-eDP-1
card0-HDMI-A-1
renderD128
version
```
---
## Assistant (Plan · DeepSeek V4 Pro · 12.2s)
_Thinking:_
The user has:
- Intel Iris Plus Graphics G1 (Ice Lake) with i915 driver
- Monitor detected as HDMI-A-1 at 1829x1029 (which is roughly 16:9, not ultrawide)
- The EDID parsing only shows the internal eDP-1 panel (LGD), not the external monitor's EDID
- The resolution list doesn't include any 21:9 ultrawide resolutions (like 3440x1440 or 2560x1080)
The problem is clear: The system can't read the proper EDID from the HDMI-connected monitor, so it only sees standard 16:9 resolutions. The highest available is 1829x1029 which seems like a scrambled/detected resolution.
Let me get more info about the monitor's EDID and check if we can force a custom resolution.
Since I'm in plan mode (read-only), let me gather more data to formulate a plan.
**Tool: bash**
**Input:**
```json
{
"command": "ls /sys/class/drm/card0-HDMI-A-1/edid 2>/dev/null && xxd /sys/class/drm/card0-HDMI-A-1/edid 2>/dev/null || echo \"No EDID file for HDMI-A-1\""
}
```
**Output:**
```
/sys/class/drm/card0-HDMI-A-1/edid
00000000: 00ff ffff ffff ff00 1e6d 0c5c 7b9a 0100 .........m.\{...
00000010: 0720 0103 803c 1978 ea24 e5ae 5048 a424 . ...<.x.$..PH.$
00000020: 0e50 5425 6b00 7140 8180 81c0 a9c0 b300 .PT%k.q@........
00000030: d1c0 8100 d1cf cd46 00a0 a038 1f40 3020 .......F...8.@0
00000040: 3a00 59fe 2000 001a 023a 8018 7138 2d40 :.Y. ....:..q8-@
00000050: 582c 4500 59fe 2000 001e 0000 00fd 0030 X,E.Y. ........0
00000060: 4b5a 5a18 010a 2020 2020 2020 0000 00fc KZZ... ....
00000070: 004c 4720 554c 5452 4157 4944 450a 01ba .LG ULTRAWIDE...
00000080: 0203 3af2 2309 0707 4b10 0403 011f 1359 ..:.#...K......Y
00000090: 125d 5e5f 8301 0000 6d03 0c00 1000 b83c .]^_....m......<
000000a0: 2000 6001 0203 681a 0000 0101 304b 00e3 .`...h.....0K..
000000b0: 05c0 00e6 0605 014a 4a56 2959 00a0 a038 .......JJV)Y...8
000000c0: 2740 3020 3a00 59fe 2000 001a 565e 00a0 '@0 :.Y. ...V^..
000000d0: a0a0 2950 3020 3500 59fe 2000 001a 0000 ..)P0 5.Y. .....
000000e0: 0000 0000 0000 0000 0000 0000 0000 0000 ................
000000f0: 0000 0000 0000 0000 0000 0000 0000 00cf ................
```
**Tool: bash**
**Input:**
```json
{
"command": "cat /proc/cmdline 2>/dev/null"
}
```
**Output:**
```
BOOT_IMAGE=/boot/vmlinuz-6.12.100+deb13-amd64 root=UUID=9757ad5c-2c4e-49af-9220-b8363a3c209c ro quiet splash
```
**Tool: bash**
**Input:**
```json
{
"command": "lsmod | grep -E \"i915|drm|hdmi\" 2>/dev/null"
}
```
**Output:**
```
snd_hda_codec_hdmi 98304 1
snd_hda_codec 217088 8 snd_hda_codec_generic,snd_soc_avs,snd_hda_codec_hdmi,snd_soc_hda_codec,snd_hda_intel,snd_hda_codec_realtek,snd_soc_hdac_hda,snd_sof_intel_hda
snd_hda_core 143360 11 snd_hda_codec_generic,snd_soc_avs,snd_hda_codec_hdmi,snd_soc_hda_codec,snd_hda_intel,snd_hda_ext_core,snd_hda_codec,snd_hda_codec_realtek,snd_sof_intel_hda_common,snd_soc_hdac_hda,snd_sof_intel_hda
snd_pcm 188416 14 snd_soc_avs,snd_hda_codec_hdmi,snd_hda_intel,snd_usb_audio,snd_hda_codec,soundwire_intel,snd_sof,snd_sof_intel_hda_common,snd_compress,snd_soc_core,snd_sof_utils,snd_hda_core,snd_pcm_dmaengine
snd 151552 26 snd_ctl_led,snd_hda_codec_generic,snd_seq,snd_seq_device,snd_hda_codec_hdmi,snd_hwdep,snd_hda_intel,snd_usb_audio,snd_usbmidi_lib,snd_hda_codec,snd_hda_codec_realtek,snd_sof,snd_timer,snd_compress,snd_soc_core,snd_pcm,snd_rawmidi
i915 4386816 159
drm_buddy 28672 1 i915
i2c_algo_bit 16384 1 i915
drm_display_helper 274432 1 i915
cec 69632 2 drm_display_helper,i915
ttm 106496 1 i915
drm_kms_helper 253952 2 drm_display_helper,i915
drm 774144 63 i2c_hid,drm_kms_helper,drm_display_helper,drm_buddy,i915,ttm
video 81920 3 dell_wmi,dell_laptop,i915
```
**Tool: bash**
**Input:**
```json
{
"command": "uname -r && cat /etc/os-release 2>/dev/null | head -5"
}
```
**Output:**
```
6.12.100+deb13-amd64
PRETTY_NAME="Debian GNU/Linux 13 (trixie)"
NAME="Debian GNU/Linux"
VERSION_ID="13"
VERSION="13 (trixie)"
VERSION_CODENAME=trixie
```
---
## Assistant (Plan · DeepSeek V4 Pro · 18.1s)
_Thinking:_
Now I have a clear picture:
1. **GPU**: Intel Iris Plus Graphics G1 (Ice Lake) with i915 driver
2. **OS**: Debian 13 Trixie with kernel 6.12
3. **Monitor EDID**: The EDID clearly says "LG ULTRAWIDE" (line 0x70) - so the EDID IS being read
4. **Current resolution**: 1829x1029 which is odd - this looks like a 2560x1080 native resolution being detected wrong
Looking at the EDID more carefully:
- The monitor identifies as "LG ULTRAWIDE"
- The native resolution seems to be encoded but the driver is not parsing it correctly
- The available mode list doesn't include any ultrawide resolution
The Intel Ice Lake GPU has an HDMI port, but Ice Lake's HDMI is often limited to HDMI 1.4 bandwidth via the LSPCON, which can be a limitation. However, the EDID data contains display descriptors that should define the native resolution.
Let me decode the EDID properly:
- Byte 0x36-0x47 (detailed timing descriptor 1):
- `cd46 00a0 a038 1f40 3020 3a00 59fe 2000 001a`
Let me parse this:
- Pixel clock: `cd46` = 0x46cd = 18125 (in 10kHz units) = 181.25 MHz
Looking at the remaining detailed timings - they seem to be monitor descriptors (display range limits, monitor name, etc.) rather than additional detailed timings.
The pixel clock of 181.25 MHz suggests this could be a 2560x1080 @ 60Hz monitor.
The problem is the i915 driver isn't presenting the correct modes. This could be because:
1. HDMI bandwidth limitation on Ice Lake
2. Need to force a custom mode via xrandr
Let me compute: for 2560x1080 @ 60Hz:
- With CVT-RB: pixel clock ≈ 181.25 MHz (matches!)
So the native resolution is likely 2560x1080 @ 60Hz, but the driver isn't offering it.
The plan should be:
1. Calculate the correct modeline for 2560x1080 @ 60Hz using CVT-RB
2. Try adding the mode via xrandr
3. If that doesn't work, the issue might be HDMI bandwidth - Ice Lake's HDMI port may only support HDMI 1.4, which maxes out at ~340 MHz pixel clock, which should be enough for 2560x1080 but just barely.
Let me provide a plan to the user.
Diagnóstico claro. O EDID do monitor está sendo lido (identifica-se como **"LG ULTRAWIDE"**), mas o driver i915 não está oferecendo a resolução nativa. A resolução atual de 1829x1029 é um modo fallback incorreto.
**Problema provável**: O HDMI da Intel Ice Lake (Iris Plus G1) é limitado a **HDMI 1.4** (máx ~340 MHz pixel clock via TMDS). Para 2560x1080@60Hz são necessários ~181 MHz, então cabe. O driver simplesmente não está parseando as timings do EDID corretamente.
**Eis o plano**:
1. **Extrair os modos nativos do EDID** com `edid-decode` para confirmar as resoluções suportadas
2. **Gerar o modeline** com `cvt` para 2560x1080@60Hz
3. **Adicionar o modo manualmente** com `xrandr --newmode` + `xrandr --addmode`
4. **Testar** a resolução com `xrandr --output HDMI-A-1 --mode 2560x1080`
5. **Se HDMI 1.4 for gargalo**: tentar 2560x1080@50Hz (ou reduzir blanking com CVT-RBv2)
6. **Tornar persistente**: criar arquivo de configuração em `/etc/X11/xorg.conf.d/`
Quer que eu prossiga com esse plano? E antes disso, qual é a resolução nativa do seu monitor (ex: 2560x1080 ou 3440x1440)?
---
## User
nao sei a resolucao nativa, quero que teste primeiro
---
## Assistant (Build · DeepSeek V4 Pro · 4.6s)
_Thinking:_
The user wants me to proceed. I need to:
1. Install edid-decode and decode the EDID to find native resolutions
2. Try generating modelines and testing them
Let me start.
**Tool: bash**
**Input:**
```json
{
"command": "which edid-decode 2>/dev/null || sudo apt-get install -y edid-decode 2>/dev/null"
}
```
**Output:**
```
/usr/bin/edid-decode
```
**Tool: bash**
**Input:**
```json
{
"command": "which cvt 2>/dev/null || echo \"cvt not found\""
}
```
**Output:**
```
/usr/bin/cvt
```
---
## Assistant (Build · DeepSeek V4 Pro · 4.0s)
_Thinking:_
Great, both tools are available. Let me decode the EDID to find the native resolution, and also generate modelines for common ultrawide resolutions.
**Tool: bash**
**Input:**
```json
{
"command": "edid-decode /sys/class/drm/card0-HDMI-A-1/edid"
}
```
**Output:**
```
edid-decode (hex):
00 ff ff ff ff ff ff 00 1e 6d 0c 5c 7b 9a 01 00
07 20 01 03 80 3c 19 78 ea 24 e5 ae 50 48 a4 24
0e 50 54 25 6b 00 71 40 81 80 81 c0 a9 c0 b3 00
d1 c0 81 00 d1 cf cd 46 00 a0 a0 38 1f 40 30 20
3a 00 59 fe 20 00 00 1a 02 3a 80 18 71 38 2d 40
58 2c 45 00 59 fe 20 00 00 1e 00 00 00 fd 00 30
4b 5a 5a 18 01 0a 20 20 20 20 20 20 00 00 00 fc
00 4c 47 20 55 4c 54 52 41 57 49 44 45 0a 01 ba
02 03 3a f2 23 09 07 07 4b 10 04 03 01 1f 13 59
12 5d 5e 5f 83 01 00 00 6d 03 0c 00 10 00 b8 3c
20 00 60 01 02 03 68 1a 00 00 01 01 30 4b 00 e3
05 c0 00 e6 06 05 01 4a 4a 56 29 59 00 a0 a0 38
27 40 30 20 3a 00 59 fe 20 00 00 1a 56 5e 00 a0
a0 a0 29 50 30 20 35 00 59 fe 20 00 00 1a 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 cf
----------------
Block 0, Base EDID:
EDID Structure Version & Revision: 1.3
Vendor & Product Identification:
Manufacturer: GSM
Model: 23564
Serial Number: 105083
Made in: week 7 of 2022
Basic Display Parameters & Features:
Digital display
Maximum image size: 60 cm x 25 cm
Gamma: 2.20
DPMS levels: Standby Suspend Off
RGB color display
First detailed timing is the preferred timing
Color Characteristics:
Red : 0.6796, 0.3144
Green: 0.2822, 0.6406
Blue : 0.1435, 0.0566
White: 0.3134, 0.3291
Established Timings I & II:
DMT 0x04: 640x480 59.940476 Hz 4:3 31.469 kHz 25.175000 MHz
DMT 0x06: 640x480 75.000000 Hz 4:3 37.500 kHz 31.500000 MHz
DMT 0x09: 800x600 60.316541 Hz 4:3 37.879 kHz 40.000000 MHz
DMT 0x0b: 800x600 75.000000 Hz 4:3 46.875 kHz 49.500000 MHz
Apple : 832x624 74.551266 Hz 4:3 49.726 kHz 57.284000 MHz
DMT 0x10: 1024x768 60.003840 Hz 4:3 48.363 kHz 65.000000 MHz
DMT 0x12: 1024x768 75.028582 Hz 4:3 60.023 kHz 78.750000 MHz
DMT 0x24: 1280x1024 75.024675 Hz 5:4 79.976 kHz 135.000000 MHz
Standard Timings:
GTF : 1152x864 60.000000 Hz 4:3 53.700 kHz 81.624000 MHz
DMT 0x23: 1280x1024 60.019740 Hz 5:4 63.981 kHz 108.000000 MHz
DMT 0x55: 1280x720 60.000000 Hz 16:9 45.000 kHz 74.250000 MHz
DMT 0x53: 1600x900 60.000000 Hz 16:9 60.000 kHz 108.000000 MHz (RB)
DMT 0x3a: 1680x1050 59.954250 Hz 16:10 65.290 kHz 146.250000 MHz
DMT 0x52: 1920x1080 60.000000 Hz 16:9 67.500 kHz 148.500000 MHz
DMT 0x1c: 1280x800 59.810326 Hz 16:10 49.702 kHz 83.500000 MHz
GTF : 1920x1080 75.000068 Hz 16:9 84.600 kHz 220.637000 MHz
Detailed Timing Descriptors:
DTD 1: 2560x1080 59.978424 Hz 64:27 66.636 kHz 181.250000 MHz (601 mm x 254 mm)
Hfront 48 Hsync 32 Hback 80 Hpol P
Vfront 3 Vsync 10 Vback 18 Vpol N
DTD 2: 1920x1080 60.000000 Hz 16:9 67.500 kHz 148.500000 MHz (601 mm x 254 mm)
Hfront 88 Hsync 44 Hback 148 Hpol P
Vfront 4 Vsync 5 Vback 36 Vpol P
Display Range Limits:
Monitor ranges (Bare Limits): 48-75 Hz V, 90-90 kHz H, max dotclock 240 MHz
Display Product Name: 'LG ULTRAWIDE'
Extension blocks: 1
Checksum: 0xba
----------------
Block 1, CTA-861 Extension Block:
Revision: 3
Underscans IT Video Formats by default
Basic audio support
Supports YCbCr 4:4:4
Supports YCbCr 4:2:2
Native detailed modes: 2
Audio Data Block:
Linear PCM:
Max channels: 2
Supported sample rates (kHz): 48 44.1 32
Supported sample sizes (bits): 24 20 16
Video Data Block:
VIC 16: 1920x1080 60.000000 Hz 16:9 67.500 kHz 148.500000 MHz
VIC 4: 1280x720 60.000000 Hz 16:9 45.000 kHz 74.250000 MHz
VIC 3: 720x480 59.940060 Hz 16:9 31.469 kHz 27.000000 MHz
VIC 1: 640x480 59.940476 Hz 4:3 31.469 kHz 25.175000 MHz
VIC 31: 1920x1080 50.000000 Hz 16:9 56.250 kHz 148.500000 MHz
VIC 19: 1280x720 50.000000 Hz 16:9 37.500 kHz 74.250000 MHz
VIC 89: 2560x1080 50.000000 Hz 64:27 56.250 kHz 185.625000 MHz
VIC 18: 720x576 50.000000 Hz 16:9 31.250 kHz 27.000000 MHz
VIC 93: 3840x2160 24.000000 Hz 16:9 54.000 kHz 297.000000 MHz
VIC 94: 3840x2160 25.000000 Hz 16:9 56.250 kHz 297.000000 MHz
VIC 95: 3840x2160 30.000000 Hz 16:9 67.500 kHz 297.000000 MHz
Speaker Allocation Data Block:
FL/FR - Front Left/Right
Vendor-Specific Data Block (HDMI), OUI 00-0C-03:
Source physical address: 1.0.0.0
Supports_AI
DC_36bit
DC_30bit
DC_Y444
Maximum TMDS clock: 300 MHz
Extended HDMI video details:
HDMI VICs:
HDMI VIC 1: 3840x2160 30.000000 Hz 16:9 67.500 kHz 297.000000 MHz
HDMI VIC 2: 3840x2160 25.000000 Hz 16:9 56.250 kHz 297.000000 MHz
HDMI VIC 3: 3840x2160 24.000000 Hz 16:9 54.000 kHz 297.000000 MHz
Vendor-Specific Data Block (AMD), OUI 00-00-1A:
Version: 1.1
Minimum Refresh Rate: 48 Hz
Maximum Refresh Rate: 75 Hz
Flags 1.x: 0x00
Colorimetry Data Block:
BT2020YCC
BT2020RGB
HDR Static Metadata Data Block:
Electro optical transfer functions:
Traditional gamma - SDR luminance range
SMPTE ST2084
Supported static metadata descriptors:
Static metadata type 1
Desired content max luminance: 74 (248.372 cd/m^2)
Desired content max frame-average luminance: 74 (248.372 cd/m^2)
Desired content min luminance: 86 (0.282 cd/m^2)
Detailed Timing Descriptors:
DTD 3: 2560x1080 74.991458 Hz 64:27 83.915 kHz 228.250000 MHz (601 mm x 254 mm)
Hfront 48 Hsync 32 Hback 80 Hpol P
Vfront 3 Vsync 10 Vback 26 Vpol N
DTD 4: 2560x1440 59.950550 Hz 16:9 88.787 kHz 241.500000 MHz (601 mm x 254 mm)
Hfront 48 Hsync 32 Hback 80 Hpol P
Vfront 3 Vsync 5 Vback 33 Vpol N
Checksum: 0xcf
```
**Tool: bash**
**Input:**
```json
{
"command": "cvt 2560 1080 60"
}
```
**Output:**
```
# 2560x1080 59.98 Hz (CVT) hsync: 67.17 kHz; pclk: 230.00 MHz
Modeline "2560x1080_60.00" 230.00 2560 2720 2992 3424 1080 1083 1093 1120 -hsync +vsync
```
**Tool: bash**
**Input:**
```json
{
"command": "cvt -r 2560 1080 60 2>/dev/null || cvt 2560 1080 60 -r 2>/dev/null || echo \"cvt -r not supported\""
}
```
**Output:**
```
# 2560x1080 59.98 Hz (CVT) hsync: 66.64 kHz; pclk: 181.25 MHz
Modeline "2560x1080R" 181.25 2560 2608 2640 2720 1080 1083 1093 1111 +hsync -vsync
```
---
## Assistant (Build · DeepSeek V4 Pro · 8.4s)
_Thinking:_
Now I have all the information. Let me summarize what the EDID reveals:
- **Native/preferred resolution**: **2560x1080 @ 60Hz** (DTD 1, pixels: 181.25 MHz, with reduced blanking)
- Also supports:
- 1920x1080 @ 60Hz
- 2560x1080 @ 75Hz (228.25 MHz)
- **2560x1440 @ 60Hz** (241.5 MHz) - this is interesting, it's in the CTA block!
- 3840x2160 @ 24/25/30Hz
- Various standard modes
- **Max TMDS clock**: 300 MHz
- Monitor name: "LG ULTRAWIDE"
- Display size: 601mm x 254mm (= roughly 23.66" x 10") which gives about 25.6" diagonal
The monitor is 2560x1080 native. The CVT-RB modeline (181.25 MHz) matches the EDID perfectly.
The problem is the i915 driver isn't exposing these modes. Let me try adding the mode manually.
Since the native is 2560x1080, and it also supports 2560x1440, let me try adding the modes. The pixel clock is within the 300 MHz TMDS limit for HDMI 1.4.
Let me first try to add and apply the 2560x1080 mode.
Achei a resolução nativa! O monitor é **2560x1080 @ 60Hz** (LG ULTRAWIDE). O EDID contém as timings corretas, mas o driver i915 não está expondo os modos. Vou adicionar manualmente:
**Tool: bash**
**Input:**
```json
{
"command": "xrandr --newmode \"2560x1080_60\" 181.25 2560 2608 2640 2720 1080 1083 1093 1111 +hsync -vsync"
}
```
**Output:**
```
(no output)
```
---
## Assistant (Build · DeepSeek V4 Pro · 2.7s)
_Thinking:_
Good, mode added. Now add it to the output and apply.
**Tool: bash**
**Input:**
```json
{
"command": "xrandr --addmode HDMI-A-1 2560x1080_60 && xrandr --output HDMI-A-1 --mode 2560x1080_60"
}
```
**Output:**
```
X Error of failed request: BadValue (integer parameter out of range for operation)
Major opcode of failed request: 139 (RANDR)
Minor opcode of failed request: 21 (RRSetCrtcConfig)
Value in failed request: 0x0
Serial number of failed request: 22
Current serial number in output stream: 22
```
---
## Assistant (Build · DeepSeek V4 Pro · 9.4s)
_Thinking:_
The mode was added successfully (no error for `--addmode`), but applying it fails with `BadValue`. This usually means the pixel clock is too high for the HDMI port, or the CRTC can't handle this configuration.
Let me check:
- The monitor also supports 2560x1440 @ 60Hz at 241.5 MHz - but that's in the CTA block, not the base block
- Max TMDS clock reported by the monitor is 300 MHz
The issue might be:
1. The HDMI port on Ice Lake is limited to 165 MHz (single-link TMDS) or similar
2. Or there's a CRTC limitation on this GPU
Let me check what the max pixel clock is for this GPU/connection. Ice Lake with HDMI via LSPCON might be limited.
Actually, wait - let me check if the mode was added correctly first.
O modo foi adicionado mas falhou ao aplicar. Vou verificar limites de pixel clock da GPU:
**Tool: bash**
**Input:**
```json
{
"command": "xrandr --verbose 2>&1 | grep -E \"HDMI-A-1|max bpc|TMDS|clock|2560\""
}
```
**Output:**
```
HDMI-A-1 connected primary 1829x1029+0+0 (0x23) normal (normal left inverted right x axis y axis) 601mm x 254mm
h: width 1829 start 1936 end 2128 total 2432 skew 0 clock 63.94KHz
v: height 1029 start 1032 end 1042 total 1068 clock 59.87Hz
h: width 1280 start 1360 end 1496 total 1712 skew 0 clock 63.67KHz
v: height 1024 start 1027 end 1034 total 1063 clock 59.89Hz
h: width 1280 start 1360 end 1488 total 1696 skew 0 clock 59.70KHz
v: height 960 start 963 end 967 total 996 clock 59.94Hz
h: width 1152 start 1216 end 1336 total 1520 skew 0 clock 53.78KHz
v: height 864 start 867 end 871 total 897 clock 59.96Hz
h: width 1024 start 1072 end 1176 total 1328 skew 0 clock 47.82KHz
v: height 768 start 771 end 775 total 798 clock 59.92Hz
h: width 800 start 832 end 912 total 1024 skew 0 clock 37.35KHz
v: height 600 start 603 end 607 total 624 clock 59.86Hz
h: width 640 start 656 end 720 total 800 skew 0 clock 29.69KHz
v: height 480 start 483 end 487 total 500 clock 59.38Hz
h: width 320 start 328 end 360 total 400 skew 0 clock 15.00KHz
v: height 240 start 243 end 247 total 253 clock 59.29Hz
h: width 1440 start 1520 end 1672 total 1904 skew 0 clock 55.93KHz
v: height 900 start 903 end 909 total 934 clock 59.89Hz
h: width 1280 start 1352 end 1480 total 1680 skew 0 clock 49.70KHz
v: height 800 start 803 end 809 total 831 clock 59.81Hz
h: width 1152 start 1208 end 1320 total 1488 skew 0 clock 44.86KHz
v: height 720 start 723 end 729 total 748 clock 59.97Hz
h: width 960 start 992 end 1088 total 1216 skew 0 clock 37.21KHz
v: height 600 start 603 end 609 total 624 clock 59.63Hz
h: width 928 start 968 end 1056 total 1184 skew 0 clock 36.11KHz
v: height 580 start 583 end 589 total 603 clock 59.88Hz
h: width 800 start 824 end 896 total 992 skew 0 clock 31.00KHz
v: height 500 start 503 end 509 total 521 clock 59.50Hz
h: width 768 start 792 end 864 total 960 skew 0 clock 29.95KHz
v: height 480 start 483 end 489 total 500 clock 59.90Hz
h: width 720 start 744 end 808 total 896 skew 0 clock 29.85KHz
v: height 480 start 483 end 493 total 500 clock 59.71Hz
h: width 640 start 656 end 720 total 800 skew 0 clock 25.00KHz
v: height 400 start 403 end 409 total 417 clock 59.95Hz
h: width 320 start 328 end 360 total 400 skew 0 clock 12.50KHz
v: height 200 start 203 end 209 total 215 clock 58.14Hz
h: width 1600 start 1688 end 1856 total 2112 skew 0 clock 55.99KHz
v: height 900 start 903 end 908 total 934 clock 59.95Hz
h: width 1368 start 1440 end 1576 total 1784 skew 0 clock 47.79KHz
v: height 768 start 771 end 781 total 798 clock 59.88Hz
h: width 1280 start 1344 end 1472 total 1664 skew 0 clock 44.77KHz
v: height 720 start 723 end 728 total 748 clock 59.86Hz
h: width 1024 start 1064 end 1160 total 1296 skew 0 clock 35.88KHz
v: height 576 start 579 end 584 total 599 clock 59.90Hz
h: width 864 start 888 end 968 total 1072 skew 0 clock 30.32KHz
v: height 486 start 489 end 494 total 506 clock 59.92Hz
h: width 720 start 744 end 808 total 896 skew 0 clock 24.83KHz
v: height 400 start 403 end 413 total 419 clock 59.27Hz
h: width 640 start 656 end 720 total 800 skew 0 clock 21.88KHz
v: height 350 start 353 end 363 total 369 clock 59.28Hz
2560x1080_60 (0x40b) 181.250MHz +HSync -VSync
h: width 2560 start 2608 end 2640 total 2720 skew 0 clock 66.64KHz
v: height 1080 start 1083 end 1093 total 1111 clock 59.98Hz
```
**Tool: bash**
**Input:**
```json
{
"command": "cat /sys/kernel/debug/dri/0/i915_display_info 2>/dev/null | head -80 || echo \"debugfs not mounted\""
}
```
**Output:**
```
(no output)
```
**Tool: bash**
**Input:**
```json
{
"command": "dmesg | grep -i -E \"hdmi|i915|drm.*mode|clock|bandwidth|link\" | tail -30"
}
```
**Output:**
```
dmesg: read kernel buffer failed: Operation not permitted
```
---
## Assistant (Build · DeepSeek V4 Pro · 9.3s)
_Thinking:_
The mode is added (2560x1080_60 at 181.25MHz), but applying it fails.
The issue is likely that Ice Lake's HDMI is limited. Ice Lake uses an LSPCON (Level Shifter/Protocol Converter) chip on the motherboard to convert DisplayPort to HDMI. Depending on the LSPCON revision, the max TMDS clock could be limited to 300 MHz (HDMI 1.4) or even lower.
Actually, the error "BadValue (integer parameter out of range for operation)" with RRSetCrtcConfig typically means the CRTC can't handle this mode - possibly due to bandwidth limitations on the display pipe, not HDMI.
Let me try a few things:
1. Try the mode without the eDP internal display active (disable eDP first, or set it up as a mirrored/off configuration)
2. Try a lower pixel clock - maybe 2560x1080 @ 50Hz which the EDID says is supported
3. Check if there's a connector limitation
Actually, the most common issue with Ice Lake + HDMI is that the HDMI port is driven by DP-to-HDMI conversion, and the DP link rate might be limited. Let me check what modes are available from the debug output.
Let me try:
1. First try with the internal display disabled
2. Try the 50Hz mode
3. Check the connector max bandwidth
Actually wait, I should check if the i915 driver has a debug flag. Let me first try the simplest solution: first try 2560x1080 @ 50Hz, and also try turning off the internal display.
**Tool: bash**
**Input:**
```json
{
"command": "xrandr --listmonitors"
}
```
**Output:**
```
Monitors: 1
0: +*HDMI-A-1 1829/601x1029/254+0+0 HDMI-A-1
```
**Tool: bash**
**Input:**
```json
{
"command": "cvt -r 2560 1080 50"
}
```
**Output:**
```
ERROR: Multiple of 60Hz refresh rate required for reduced blanking.
usage: cvt [-v|--verbose] [-r|--reduced] X Y [refresh]
-v|--verbose : Warn about CVT standard adherence.
-r|--reduced : Create a mode with reduced blanking (default: normal blanking).
X : Desired horizontal resolution (multiple of 8, required).
Y : Desired vertical resolution (required).
refresh : Desired refresh rate (default: 60.0Hz).
Calculates VESA CVT (Coordinated Video Timing) modelines for use with X.
```
---
## Assistant (Build · DeepSeek V4 Pro · 4.7s)
_Thinking:_
CVT reduced blanking only works with 60Hz multiples. Let me try regular CVT for 50Hz, and also try generating from the EDID data directly.
From the EDID:
- VIC 89: 2560x1080 @ 50Hz (185.625 MHz)
- DTD 3: 2560x1080 @ 74.99Hz (228.250 MHz)
Let me try the 50Hz mode. Also, the issue might be that HDMI on Ice Lake is limited. Let me check what the HDMI port actually supports.
Let me try with regular cvt for 50Hz.
**Tool: bash**
**Input:**
```json
{
"command": "cvt 2560 1080 50"
}
```
**Output:**
```
# 2560x1080 49.95 Hz (CVT) hsync: 55.65 kHz; pclk: 188.75 MHz
Modeline "2560x1080_50.00" 188.75 2560 2712 2976 3392 1080 1083 1093 1114 -hsync +vsync
```
**Tool: bash**
**Input:**
```json
{
"command": "xrandr --props | grep -A 30 \"HDMI-A-1\""
}
```
**Output:**
```
HDMI-A-1 connected primary 1829x1029+0+0 (normal left inverted right x axis y axis) 601mm x 254mm
RANDR Emulation: 1
non-desktop: 0
supported: 0, 1
1829x1029 59.87*+
1280x1024 59.89
1280x960 59.94
1152x864 59.96
1024x768 59.92
800x600 59.86
640x480 59.38
320x240 59.29
1440x900 59.89
1280x800 59.81
1152x720 59.97
960x600 59.63
928x580 59.88
800x500 59.50
768x480 59.90
720x480 59.71
640x400 59.95
320x200 58.14
1600x900 59.95
1368x768 59.88
1280x720 59.86
1024x576 59.90
864x486 59.92
720x400 59.27
640x350 59.28
2560x1080_60 59.98
```
---
## Assistant (Build · DeepSeek V4 Pro · 13.8s)
_Thinking:_
Interesting - the mode is listed (2560x1080_60 at 59.98) but it failed to apply. The error was on `RRSetCrtcConfig` which means the CRTC/pipe can't drive this mode.
The problem might be that Ice Lake's display pipe has a bandwidth limitation. The pipe might be limited in terms of max pixel clock. Looking at the specs:
- Ice Lake (Gen 11) - maximum pixel clock per pipe is often around ~170-200 MHz depending on the configuration
- This GPU is in a Dell laptop, so the HDMI port is likely via LSPCON
The 181.25 MHz mode is right at the edge of what Ice Lake can handle. Let me try:
1. 2560x1080 @ 50Hz (188.75 MHz CVT) - actually higher clock, might be worse
2. Try 2560x1080 @ 50Hz from the EDID (VIC 89, 185.625 MHz)
3. Try reducing pixel clock further
Actually wait, I should check if Wayland is being used or X11. If it's Wayland, xrandr won't work properly.
But we do see xrandr output, so it's using X11 (or at least XWayland).
Let me try adding and applying the 50Hz mode. Also, the EDID mode says VIC 89 is 2560x1080 @ 50Hz with 185.625 MHz clock. Let me calculate the modeline for that.
Actually, the mode is already added to the output (I can see it in the xrandr list). The failure is in applying it. Let me try a few things:
1. Try with a lower clock rate - maybe the GPU pipe can't handle 181 MHz
2. The i915 driver might need a kernel parameter like `i915.enable_fbc=0` or similar
Actually, let me look at this from another angle. Ice Lake's maximum pixel clock per pipe varies:
- Single pipe: up to ~300-400 MHz
- With eDP active: possibly shared bandwidth
But these specs are for the display engine, not the HDMI output.
The `BadValue` error on `RRSetCrtcConfig` could also mean that the CRTC configuration is invalid in some other way - like the mode doesn't fit the available CRTC memory or FIFO constraints.
Let me try the 50Hz mode first, and also try disabling the eDP panel.
Actually, there's only one monitor connected - the HDMI-A-1. eDP-1 is listed but not connected. So bandwidth sharing shouldn't be an issue.
Let me try switching to 50Hz first.
**Tool: bash**
**Input:**
```json
{
"command": "xrandr --newmode \"2560x1080_50\" 185.625 2560 2608 2640 2720 1080 1083 1093 1111 +hsync -vsync && xrandr --addmode HDMI-A-1 2560x1080_50 && xrandr --output HDMI-A-1 --mode 2560x1080_50"
}
```
**Output:**
```
X Error of failed request: BadValue (integer parameter out of range for operation)
Major opcode of failed request: 139 (RANDR)
Minor opcode of failed request: 21 (RRSetCrtcConfig)
Value in failed request: 0x0
Serial number of failed request: 22
Current serial number in output stream: 22
```
---
## Assistant (Build · DeepSeek V4 Pro · 10.0s)
_Thinking:_
Same error. The issue is not the pixel clock - it's something else. Let me think about what could cause this.
`RRSetCrtcConfig` failing with `BadValue` suggests the CRTC (pipe) can't accept this configuration. Possible reasons:
1. **Pipe width limit**: Some Intel GPUs have a maximum horizontal resolution per pipe. For Ice Lake, the max should be 5120 pixels, so 2560 should be fine.
2. **FIFO underrun prevention**: The pixel clock vs horizontal active ratio might be too high
3. **LSPCON limitation**: The LSPCON might be in a mode that limits resolution
Let me check a few things:
- What's the actual pipe/PLL configuration looking like
- Try using a lower frequency with the existing mode by using a different modeline
Actually, wait - I should look at the connector type. The port is detected as HDMI-A-1, but it might be going through LSPCON which could be in a limited mode. Ice Lake doesn't have native HDMI - it uses DP-to-HDMI conversion.
Let me try a completely different approach - force the modes via kernel module parameters. But first, let me try checking if Xorg has any logging about the failure.
**Tool: bash**
**Input:**
```json
{
"command": "cat /var/log/Xorg.0.log 2>/dev/null | grep -i -E \"mode.*2560|not.*valid|reject|fail|max.*clock|bad\" | tail -20"
}
```
**Output:**
```
[ 13.199] xf86EnableIO: failed to enable I/O ports 0000-03ff (Operation not permitted)
[ 13.392] (II) modeset(0): h_active: 2560 h_sync: 2608 h_sync_end 2640 h_blank_end 2720 h_border: 0
[ 13.392] (II) modeset(0): Ranges: V min: 48 V max: 75 Hz, H min: 90 H max: 90 kHz, PixClock max 245 MHz
[ 13.392] (II) modeset(0): h_active: 2560 h_sync: 2608 h_sync_end 2640 h_blank_end 2720 h_border: 0
[ 13.392] (II) modeset(0): h_active: 2560 h_sync: 2608 h_sync_end 2640 h_blank_end 2720 h_border: 0
```
**Tool: bash**
**Input:**
```json
{
"command": "ls /sys/kernel/debug/dri/0/ 2>/dev/null | head -20"
}
```
**Output:**
```
(no output)
```
---
## Assistant (Build · DeepSeek V4 Pro · 11.2s)
_Thinking:_
Interesting - the Xorg log shows:
1. The driver IS parsing the 2560x1080 modes from EDID (it's printing the horizontal timings)
2. But the max pixel clock is being reported as 245 MHz (not the 300 MHz from the EDID)
3. The modes are detected but not made available
The key clue is "PixClock max 245 MHz" - this is lower than what the EDID says (300 MHz), and also lower than what the H-freq range would suggest (90 kHz * some factor). This might be an i915 driver limitation for the specific connector type or LSPCON configuration.
But our modes (181.25 MHz and 185.625 MHz) are well within 245 MHz, so the pixel clock limit shouldn't be the issue.
Let me check more of the Xorg log to understand what's happening. Maybe the modes are being rejected by the modesetting driver.
Actually, wait - the log shows `modeset(0)` driver, which is the generic modesetting driver, not the i915-specific one. But i915 is loaded. On some configurations, the modesetting driver can conflict.
Let me look for more detail about why the modes are being rejected.
**Tool: bash**
**Input:**
```json
{
"command": "cat /var/log/Xorg.0.log 2>/dev/null | grep -i -E \"HDMI|mode.*reject|not using|bad|fail|2560|max.*pixel|clock.*limit|bandwidth\" -A 1 | tail -40"
}
```
**Output:**
```
--
[ 13.361] (II) modeset(0): Output HDMI-1 has no monitor section
[ 13.363] (II) modeset(0): EDID for output eDP-1
--
[ 13.392] (II) modeset(0): EDID for output HDMI-1
[ 13.392] (II) modeset(0): Manufacturer: GSM Model: 5c0c Serial#: 105083
--
[ 13.392] (II) modeset(0): h_active: 2560 h_sync: 2608 h_sync_end 2640 h_blank_end 2720 h_border: 0
[ 13.392] (II) modeset(0): v_active: 1080 v_sync: 1083 v_sync_end 1093 v_blanking: 1111 v_border: 0
--
[ 13.392] (II) modeset(0): h_active: 2560 h_sync: 2608 h_sync_end 2640 h_blank_end 2720 h_border: 0
[ 13.392] (II) modeset(0): v_active: 1080 v_sync: 1083 v_sync_end 1093 v_blanking: 1119 v_border: 0
--
[ 13.392] (II) modeset(0): h_active: 2560 h_sync: 2608 h_sync_end 2640 h_blank_end 2720 h_border: 0
[ 13.392] (II) modeset(0): v_active: 1440 v_sync: 1443 v_sync_end 1448 v_blanking: 1481 v_border: 0
--
[ 13.392] (--) modeset(0): HDMI max TMDS frequency 300000KHz
[ 13.392] (II) modeset(0): Printing probed modes for output HDMI-1
[ 13.392] (II) modeset(0): Modeline "1920x1080"x60.0 148.50 1920 2008 2052 2200 1080 1084 1089 1125 +hsync +vsync (67.5 kHz e)
--
[ 13.392] (II) modeset(0): Output HDMI-1 connected
[ 13.392] (II) modeset(0): Using exact sizes for initial modes
--
[ 13.392] (II) modeset(0): Output HDMI-1 using initial mode 1920x1080 +0+0
[ 13.392] (==) modeset(0): Using gamma correction (1.0, 1.0, 1.0)
--
[ 14.230] (II) config/udev: Adding input device HDA Intel PCH HDMI/DP,pcm=3 (/dev/input/event19)
[ 14.230] (II) No input driver specified, ignoring this device.
--
[ 14.230] (II) config/udev: Adding input device HDA Intel PCH HDMI/DP,pcm=7 (/dev/input/event20)
[ 14.230] (II) No input driver specified, ignoring this device.
--
[ 14.231] (II) config/udev: Adding input device HDA Intel PCH HDMI/DP,pcm=8 (/dev/input/event21)
[ 14.231] (II) No input driver specified, ignoring this device.
--
[ 14.231] (II) config/udev: Adding input device HDA Intel PCH HDMI/DP,pcm=9 (/dev/input/event22)
[ 14.231] (II) No input driver specified, ignoring this device.
--
[ 255.807] (--) modeset(0): HDMI max TMDS frequency 300000KHz
[ 262.473] (II) event7 - Video Bus: device removed
```
**Tool: bash**
**Input:**
```json
{
"command": "cat /var/log/Xorg.0.log 2>/dev/null | grep -i \"removing\\|prune\\|discard\\|drop\" | tail -10"
}
```
**Output:**
```
(no output)
```
---
## Assistant (Build · DeepSeek V4 Pro · 12.2s)
_Thinking:_
Now I see the key information:
1. The Xorg log shows that the EDID is being fully parsed (including the 2560x1080 and 2560x1440 modes)
2. "HDMI max TMDS frequency 300000KHz" - this is correct
3. But under "Printing probed modes for output HDMI-1", only "1920x1080" is listed
4. The modes are being parsed but NOT being included in the probed modes
This means the modesetting driver is discarding the higher-resolution modes. This is likely because:
- The connector's max dotclock is being set lower than needed, or
- Something in the mode validation is rejecting them
Let me look more carefully at the full xrandr verbose output and check if there are any connector properties that show the max clock limit.
Actually, the 1829x1029 mode is very suspicious. That's not a standard mode. It seems like the driver is calculating a fallback mode based on some arithmetic error.
Let me check if the issue is with the `modesetting` driver vs the `intel` driver. The modesetting driver is the generic one. Maybe switching to the `xf86-video-intel` driver would help?
Or better yet - maybe the issue is that Xorg is using the modesetting driver and not the intel-specific DDX. Let me check.
**Tool: bash**
**Input:**
```json
{
"command": "cat /var/log/Xorg.0.log 2>/dev/null | grep -i \"driver\\|modeset\\|intel\\|i915\" | head -20"
}
```
**Output:**
```
[ 13.160] X.Org Video Driver: 25.2
[ 13.160] X.Org XInput driver : 24.4
[ 13.182] (==) Matched modesetting as autoconfigured driver 0
[ 13.182] (==) Matched fbdev as autoconfigured driver 1
[ 13.182] (==) Matched vesa as autoconfigured driver 2
[ 13.182] (==) Assigned the driver to the xf86ConfigLayout
[ 13.182] (II) LoadModule: "modesetting"
[ 13.182] (II) Loading /usr/lib/xorg/modules/drivers/modesetting_drv.so
[ 13.183] (II) Module modesetting: vendor="X.Org Foundation"
[ 13.183] Module class: X.Org Video Driver
[ 13.183] ABI class: X.Org Video Driver, version 25.2
[ 13.183] (II) Loading /usr/lib/xorg/modules/drivers/fbdev_drv.so
[ 13.184] Module class: X.Org Video Driver
[ 13.184] ABI class: X.Org Video Driver, version 25.2
[ 13.184] (II) Loading /usr/lib/xorg/modules/drivers/vesa_drv.so
[ 13.184] Module class: X.Org Video Driver
[ 13.184] ABI class: X.Org Video Driver, version 25.2
[ 13.184] (II) modesetting: Driver for Modesetting Kernel Drivers: kms
[ 13.184] (II) FBDEV: driver for framebuffer: fbdev
[ 13.184] (II) VESA: driver for VESA chipsets: vesa
```
**Tool: bash**
**Input:**
```json
{
"command": "dpkg -l | grep -i xserver-xorg-video-intel 2>/dev/null"
}
```
**Output:**
```
ii xserver-xorg-video-intel 2:2.99.917+git20210115-1 amd64 X.Org X server -- Intel i8xx, i9xx display driver
```
**Tool: bash**
**Input:**
```json
{
"command": "cat /sys/class/drm/card0-HDMI-A-1/modes 2>/dev/null"
}
```
**Output:**
```
1920x1080
1920x1080
1920x1080
1920x1080
1680x1050
1600x900
1280x1024
1280x1024
1280x800
1152x864
1280x720
1280x720
1280x720
1280x720
1024x768
1024x768
832x624
800x600
800x600
720x576
720x480
720x480
640x480
640x480
640x480
640x480
```
---
## Assistant (Build · DeepSeek V4 Pro · 17.9s)
_Thinking:_
Now I see the root cause:
The kernel DRM driver itself (`/sys/class/drm/card0-HDMI-A-1/modes`) is NOT exposing 2560x1080. Only up to 1920x1080 is available. This is a kernel-level limitation, not Xorg.
The xf86-video-intel DDX is installed but NOT being used (it's using modesetting instead). But the real problem is at the kernel/i915 driver level.
The kernel's i915 driver is rejecting the 2560x1080 modes. This could be because:
1. HDMI bandwidth limitation on Ice Lake - the DisplayPort to HDMI converter (LSPCON) might not support the required TMDS clock
2. The i915 driver limits HDMI to a certain resolution/clock for Ice Lake
Since `xrandr --addmode` also fails to apply (not just list) the mode, this confirms it's a kernel-level issue.
Options:
1. Use a custom EDID to force the kernel to use lower timings for 2560x1080
2. Try the `video=HDMI-A-1:2560x1080@60` kernel parameter
3. Try `modeset` driver with specific options
4. Use a custom modeline with lower pixel clock
Actually, looking at the kernel modes list again: 1920x1080 is the max. This is suspicious because 1920x1080 @ 60Hz has a pixel clock of 148.5 MHz, which is well below the 181.25 MHz needed for 2560x1080.
But wait - the monitor claims "HDMI max TMDS frequency 300000KHz" (300 MHz) which should be enough.
The problem might be that Ice Lake has an LSPCON that only exposes HDMI 1.4, and the i915 driver might be limiting based on the LSPCON's capabilities.
BUT - the 1829x1029 mode that's currently active is really weird. It's almost like the driver is computing a custom mode from the display size rather than using the EDID modes. This suggests the EDID parsing might be failing at the kernel level, and then Xorg falls back to computing modes from the display dimensions.
Let me try a different approach:
1. Try the `video=` kernel parameter
2. Try creating a custom EDID with only 2560x1080 modes
3. Try using `xrandr --fb` to set a framebuffer size first
Actually, let me try one more thing: check if the GPU actually supports this resolution at the hardware level by looking at Intel's documentation for the specific GPU. But first, let me try practical solutions.
Let me try:
1. Setting a larger framebuffer with xrandr
2. Using the intel driver instead of modesetting (create an xorg.conf snippet)
3. Kernel command line parameter
Let me start with the simplest approach - try setting the framebuffer first and then the mode.
A raiz do problema está no **kernel DRM** — `/sys/class/drm/card0-HDMI-A-1/modes` não expõe 2560x1080. O máximo listado é 1920x1080. É uma limitação do driver i915 no kernel para essa GPU Ice Lake via HDMI (LSPCON).
Vou tentar algumas abordagens:
**Tool: bash**
**Input:**
```json
{
"command": "xrandr --fb 2560x1080 2>&1; xrandr --output HDMI-A-1 --mode 2560x1080_60 2>&1"
}
```
**Output:**
```
X Error of failed request: BadValue (integer parameter out of range for operation)
Major opcode of failed request: 139 (RANDR)
Minor opcode of failed request: 21 (RRSetCrtcConfig)
Value in failed request: 0x0
Serial number of failed request: 22
Current serial number in output stream: 22
```
**Tool: bash**
**Input:**
```json
{
"command": "ls /etc/X11/xorg.conf.d/ 2>/dev/null || echo \"dir doesn't exist\""
}
```
**Output:**
```
00-keyboard.conf
```
---
## Assistant (Build · DeepSeek V4 Pro · 13.2s)
_Thinking:_
The framebuffer attempt also failed. The kernel DRM is rejecting this mode entirely.
The issue is at the kernel level - the i915 driver's connector is rejecting modes above 1920x1080 for this HDMI output. This is typical for Ice Lake LSPCON limitations.
Let me try one more creative approach: creating a custom EDID file that breaks 2560x1080 into two 1280x1080 tiles (tile mode), or using a lower pixel clock altogether.
Actually, wait - maybe I should try the `xf86-video-intel` driver instead of modesetting. The intel DDX sometimes handles mode validation differently. Let me create an xorg.conf snippet to use the intel driver.
But actually, the kernel modes list doesn't have 2560x1080 either, so switching Xorg drivers might not help. The root cause is the kernel driver.
Let me try these approaches:
1. Forzar el modo via kernel command line (`video=`) - requires reboot
2. Crear un EDID personalizado con solo 2560x1080 sin los modos que confunden al driver
3. Usar el driver xf86-video-intel en lugar de modesetting
Actually, let me try a creative workaround: use two "tiled" 1280x1080 panels. No, that's too complex.
Let me try the kernel parameter approach by testing it with a temporary mode set. Actually we can't easily test without reboot.
Wait, let me try something else first. Maybe the i915 driver has a module parameter to override the max TMDS clock or force modes. Let me check.
**Tool: bash**
**Input:**
```json
{
"command": "modinfo -p i915 2>/dev/null | grep -i -E \"hdmi|edid|mode|override|force\""
}
```
**Output:**
```
(no output)
```
**Tool: bash**
**Input:**
```json
{
"command": "cat /sys/module/i915/parameters/modeset 2>/dev/null; cat /sys/module/i915/parameters/enable_dp_mst 2>/dev/null; cat /sys/module/i915/parameters/fastboot 2>/dev/null"
}
```
**Output:**
```
(no output)
```
---
## Assistant (Build · DeepSeek V4 Pro · 17.2s)
_Thinking:_
The i915 module parameters don't seem to be available directly. Let me check modinfo differently.
Actually, let me try a completely different approach. Since this is Ice Lake and HDMI goes through LSPCON, the issue might be:
1. The LSPCON needs to be in PCON mode (protocol converter) vs LS mode (level shifter)
2. This affects what modes are available
Or it could be a simple pipe bandwidth limitation. Ice Lake Gen11 has some specific pixel clock limits.
Let me check if we can use a custom EDID via kernel parameter, or better yet, let me try forcing the modes via the `drm.edid_firmware` parameter.
Actually, let's just try the xf86-video-intel driver with a configuration that forces the mode. Even though the kernel doesn't list 2560x1080, the intel DDX might handle mode forcing differently than modesetting.
Wait, actually, both drivers use kernel mode setting (KMS). If the kernel rejects the mode, Xorg can't override it. The BadValue is coming from the kernel via RANDR.
Let me try yet another approach: create a custom EDID that reports a lower pixel clock for 2560x1080. For example, if we can make the EDID claim the connector can support the mode.
Actually, the issue might be simpler than I think. Let me look at whether this is a Pipe/CRTC limitation. On Ice Lake:
- Display pipes (CRTCs) might have width limits
- The pipe configuration might need specific settings
Let me try to see if there's some way to force it.
One thing I haven't tried: the `video=` kernel parameter format like `video=HDMI-A-1:2560x1080@60D` or `video=HDMI-A-1:2560x1080MR@60`.
But that requires a reboot. Let me try the xorg.conf approach first with the intel driver, and also try using `xrandr` with `--scale` to achieve 21:9 aspect ratio.
Actually, scaling is a good workaround! We can set the mode to 1920x1080 (which works) and use xrandr scaling to stretch it to 2560x1080. It won't be pixel-perfect, but it'll fill the screen.
Let me try:
```
xrandr --output HDMI-A-1 --mode 1920x1080 --scale 1.333x1.0
```
But wait, 1920 * 1.333 = 2560. That might cause blurry text though since we're scaling.
Actually, a better option might be to use `xrandr --transform` with a proper scaling matrix. But let me first check if 1920x1080 mode works properly.
Also, I should try creating a custom EDID and loading it via the kernel. On Debian, I can:
1. Extract and modify the EDID
2. Place it in /lib/firmware/edid/
3. Use `drm.edid_firmware=HDMI-A-1:edid/your-edid.bin` kernel parameter
But actually, there's an even simpler approach the user might prefer: let me try the `xf86-video-intel` driver with an explicit modeline in xorg.conf.d.
Let me take a practical approach:
1. First try `xrandr --scale` as quick workaround
2. Then try xorg.conf with intel driver
3. If that fails, use custom EDID firmware
**Tool: bash**
**Input:**
```json
{
"command": "xrandr --output HDMI-A-1 --mode 1920x1080 --scale-from 2560x1080 2>&1"
}
```
**Output:**
```
xrandr: cannot find mode 1920x1080
```
---
## Assistant (Build · DeepSeek V4 Pro · 3.1s)
_Thinking:_
Interesting - xrandr can't find 1920x1080 even though it's in the kernel modes list and in the Xorg log. Let me check the exact mode names.
**Tool: bash**
**Input:**
```json
{
"command": "xrandr --verbose 2>&1 | grep -E \"^ [0-9]\" | head -30"
}
```
**Output:**
```
1829x1029 (0x23) 155.500MHz -HSync +VSync *current +preferred
1280x1024 (0x24) 109.000MHz -HSync +VSync
1280x960 (0x25) 101.250MHz -HSync +VSync
1152x864 (0x26) 81.750MHz -HSync +VSync
1024x768 (0x27) 63.500MHz -HSync +VSync
800x600 (0x28) 38.250MHz -HSync +VSync
640x480 (0x29) 23.750MHz -HSync +VSync
320x240 (0x2a) 6.000MHz -HSync +VSync
1440x900 (0x2b) 106.500MHz -HSync +VSync
1280x800 (0x2c) 83.500MHz -HSync +VSync
1152x720 (0x2d) 66.750MHz -HSync +VSync
960x600 (0x2e) 45.250MHz -HSync +VSync
928x580 (0x2f) 42.750MHz -HSync +VSync
800x500 (0x30) 30.750MHz -HSync +VSync
768x480 (0x31) 28.750MHz -HSync +VSync
720x480 (0x32) 26.750MHz -HSync +VSync
640x400 (0x33) 20.000MHz -HSync +VSync
320x200 (0x34) 5.000MHz -HSync +VSync
1600x900 (0x35) 118.250MHz -HSync +VSync
1368x768 (0x36) 85.250MHz -HSync +VSync
1280x720 (0x37) 74.500MHz -HSync +VSync
1024x576 (0x38) 46.500MHz -HSync +VSync
864x486 (0x39) 32.500MHz -HSync +VSync
720x400 (0x3a) 22.250MHz -HSync +VSync
640x350 (0x3b) 17.500MHz -HSync +VSync
2560x1080_60 (0x40b) 181.250MHz +HSync -VSync
2560x1080_50 (0x40c) 185.625MHz +HSync -VSync
```
---
## Assistant (Build · DeepSeek V4 Pro · 10.3s)
_Thinking:_
1920x1080 is not in the xrandr list! That's really strange. The kernel modes list shows it, but xrandr doesn't. Let me check where the weird modes are coming from.
The current mode 1829x1029 has 155.5 MHz pixel clock. This is very close to what a 1920x1080 mode with standard timings would use (148.5 MHz), but the resolution doesn't match.
Wait - 1829x1029 is suspicious. Looking at the display size reported (601mm x 254mm), and doing math: 1829/601 = ~3.04 pixels/mm for horizontal, and 1029/254 = ~4.05 pixels/mm for vertical. These aren't matching.
I think what's happening is: the i915 driver is rejecting all the detailed timing modes from the EDID (including 1920x1080!) and instead computing a mode based on the display physical size (601mm x 254mm) with some default DPI assumption.
This means the kernel driver is completely failing to use any of the EDID modes. The modes it's listing in /sys/class/drm/card0-HDMI-A-1/modes might be the standard DMT/CEA modes it computes, not the detailed timings.
This changes everything. The fundamental problem is that the i915 driver is not properly parsing/accepting the EDID detailed timings for this HDMI connection. This is likely a bug in the i915 driver's handling of this specific LSPCON/HDMI configuration.
Solutions could include:
1. Custom EDID with properly formatted detailed timings that the driver will accept
2. Kernel parameter to force modes
3. Using the `xf86-video-intel` DDX driver which might handle this differently
4. Custom xorg.conf with Modeline
Let me try the xorg.conf approach with the intel driver and explicit modelines.
**Tool: bash**
**Input:**
```json
{
"command": "ls /etc/X11/xorg.conf.d/"
}
```
**Output:**
```
00-keyboard.conf
```
---
## Assistant (Build · DeepSeek V4 Pro · 10.5s)
_Thinking:_
Let me create an xorg.conf.d snippet to use the intel driver with a forced modeline. The intel DDX might handle mode validation differently.
Actually, wait. Let me think about this differently. The kernel is rejecting all EDID detailed timings. The xrandr modes it's showing are computed modes based on physical dimensions, not from the EDID. That's why we get 1829x1029 (computed from 601mm x 254mm display size at some DPI).
One approach that often works is creating a custom EDID with only the 2560x1080 detailed timing and loading it via kernel's EDID firmware mechanism. Let me try that.
But first, let me try the simplest kernel workaround: use the `video=` parameter in the kernel command line. However, we can't easily test this without reboot. Instead, let me try creating a custom xorg.conf that uses the intel driver.
Let me try:
1. Create xorg config with intel driver + modelines
2. If that doesn't work, try custom EDID firmware
Actually, maybe I should try a completely different approach. Since all the EDID modes are being rejected, maybe there's a fundamental issue with how the HDMI connection is established. Let me check if there's something in the i915 driver debug info.
**Tool: bash**
**Input:**
```json
{
"command": "mount -t debugfs none /sys/kernel/debug 2>/dev/null; cat /sys/kernel/debug/dri/0/i915_display_info 2>/dev/null | head -100 || echo \"cannot read\""
}
```
**Output:**
```
(no output)
```
---
## Assistant (Build · DeepSeek V4 Pro · 10.3s)
_Thinking:_
We couldn't read the debugfs info (probably permission issue). Let me try with sudo.
Actually, we can't use sudo. Let me try a different approach.
Let me try another approach: create a custom EDID binary file and load it using the kernel module. This is a well-known workaround for HDMI EDID parsing issues with Intel GPUs.
The plan:
1. Create a proper EDID binary that contains only the 2560x1080 @ 60Hz mode
2. Copy the file to /lib/firmware/edid/
3. Add kernel parameter `drm.edid_firmware=HDMI-A-1:edid/lg-ultrawide.bin`
4. Reboot
But first, since we can't just modify and apply a custom EDID without rebooting, let me try the xorg approach first.
Let me create an xorg.conf.d file with the intel driver. Even though the modesetting driver uses KMS and gets modes from the kernel, the intel DDX might handle the modeline differently.
Actually wait, let me think about this more carefully. The xrandr CRTC config failure (`BadValue on RRSetCrtcConfig`) means the kernel KMS driver is rejecting the mode set. This happens regardless of which Xorg driver is in use, because xrandr talks to the kernel DRM directly through the RANDR protocol.
So the solutions are:
1. **Kernel parameter**: `video=HDMI-A-1:2560x1080@60` or `drm.edid_firmware=...`
2. **Kernel module parameter**: some i915 parameter that might help
3. **Custom EDID firmware**: load via kernel
Let me try one more thing - check if there are any HDMI-related parameters for i915.
**Tool: bash**
**Input:**
```json
{
"command": "modinfo i915 2>/dev/null | grep -E \"^parm:\" | head -30"
}
```
**Output:**
```
(no output)
```
**Tool: bash**
**Input:**
```json
{
"command": "ls /lib/firmware/edid/ 2>/dev/null || echo \"no edid firmware dir\""
}
```
**Output:**
```
no edid firmware dir
```
---
## Assistant (Build · DeepSeek V4 Pro · 13.5s)
_Thinking:_
modinfo doesn't output anything for i915 - this is unusual on Debian. It seems like the module isn't in the typical path or modinfo can't find it. Let me check differently.
Let me try:
1. Finding the module parameters file
2. Creating a custom EDID
Actually, let me try a different approach. Since this is Debian Trixie, the i915 module is likely built-in to the kernel, not a module. Let me verify.
Also, let me try something practical: create a custom EDID binary that we know will work, and load it via kernel parameter at boot time.
For the custom EDID, I'll take the original EDID and strip out everything except the 2560x1080 detailed timing. Actually, the kernel already can see the EDID with the correct timings - the issue is that it's rejecting them.
Let me try a completely different approach. Instead of feeding a custom EDID, let me create an xorg.conf that uses the `intel` driver with explicit modelines. The intel DDX might use a different code path for mode validation.
Actually, I just realized something. The fact that xrandr can't even see 1920x1080 (which IS in the kernel modes list) is very suspicious. Let me investigate this further.
Wait, looking at the xrandr verbose output more carefully, the modes listed don't include ANY of the standard modes from the kernel. The highest is 1829x1029. This strongly suggests that Xorg is NOT using the kernel-provided mode list, but is instead computing modes from the display size.
The issue might be that the modesetting driver is confused by the EDID and falls back to generating modes from the display size. Or, there could be a bug in the way the kernel exposes modes to userspace.
Let me try switching to the intel driver by creating an xorg.conf.d file. This might bypass whatever bug is causing the modesetting driver to not see the kernel modes.
Let me also check if we can find module parameters for i915 elsewhere.
**Tool: bash**
**Input:**
```json
{
"command": "ls /sys/module/i915/parameters/ 2>/dev/null && cat /sys/module/i915/parameters/* 2>/dev/null | head -20 || echo \"no params\""
}
```
**Output:**
```
disable_display
disable_power_well
dmc_firmware_path
edp_vswing
enable_dc
enable_dmc_wl
enable_dpcd_backlight
enable_dp_mst
enable_dpt
enable_dsb
enable_fbc
enable_guc
enable_gvt
enable_hangcheck
enable_ips
enable_psr
enable_psr2_sel_fetch
enable_sagv
error_capture
force_probe
force_reset_modeset_test
gsc_firmware_path
guc_firmware_path
guc_log_level
huc_firmware_path
invert_brightness
lmem_bar_size
lmem_size
load_detect_test
lvds_channel_mode
memtest
mitigations
mmio_debug
modeset
nuclear_pageflip
panel_use_ssc
psr_safest_params
request_timeout_ms
reset
vbt_firmware
vbt_sdvo_panel_type
verbose_state_checks
```
**Tool: bash**
**Input:**
```json
{
"command": "find /sys/module/i915 -type f 2>/dev/null | head -20"
}
```
**Output:**
```
/sys/module/i915/initsize
/sys/module/i915/uevent
/sys/module/i915/notes/.note.Linux
/sys/module/i915/notes/.note.gnu.build-id
/sys/module/i915/notes/.note.gnu.property
/sys/module/i915/taint
/sys/module/i915/parameters/enable_ips
/sys/module/i915/parameters/enable_psr2_sel_fetch
/sys/module/i915/parameters/psr_safest_params
/sys/module/i915/parameters/enable_psr
/sys/module/i915/parameters/huc_firmware_path
/sys/module/i915/parameters/edp_vswing
/sys/module/i915/parameters/enable_fbc
/sys/module/i915/parameters/disable_power_well
/sys/module/i915/parameters/vbt_firmware
/sys/module/i915/parameters/enable_hangcheck
/sys/module/i915/parameters/guc_firmware_path
/sys/module/i915/parameters/reset
/sys/module/i915/parameters/modeset
/sys/module/i915/parameters/lvds_channel_mode
```
---
## Assistant (Build · DeepSeek V4 Pro · 2.6s)
_Thinking:_
I see that i915 is a built-in module with parameters. I don't see any HDMI-specific parameters that would help. Let me check the `
---
## User
estou usando waylland
---
## Assistant (Build · DeepSeek V4 Pro · 11.7s)
_Thinking:_
The user mentions they're using Wayland, not X11. This changes everything! xrandr won't work properly on Wayland - it's an X11 tool. The `RANDR Emulation: 1` property in the xrandr output confirms this - it's running in XWayland emulation mode.
On Wayland, we need to use Wayland-native tools or the compositor's config to set modes. Let me figure out which compositor they're using (likely GNOME/Mutter or KDE/KWin on Debian Trixie).
Let me check the Wayland compositor and use the appropriate tool (like `wlr-randr` for wlroots, `gnome-randr` for GNOME, or `kscreen-doctor` for KDE).
Also, since they're on Wayland, I should look at the actual kernel modes (/sys/class/drm/card0-HDMI-A-1/modes) which DOES have 1920x1080, unlike what xrandr showed. The xrandr weirdness was just XWayland emulation limitation.
The kernel modes list DOESN'T have 2560x1080 though, which means the i915 driver is rejecting it at the kernel level.
Let me:
1. Check which Wayland compositor is running
2. Check if we can force the mode via compositor-specific tools
3. Try the custom EDID approach since that's a kernel-level fix
**Wayland!** Isso explica tudo — o `xrandr` estava rodando em emulação XWayland (por isso os modos incorretos). Preciso usar ferramentas nativas do Wayland. Vamos ver o compositor:
**Tool: bash**
**Input:**
```json
{
"command": "echo $XDG_SESSION_TYPE && echo $XDG_CURRENT_DESKTOP && ps aux | grep -E \"gnome-shell|kwin|sway|Hyprland|weston|mutter|wlroots\" | grep -v grep"
}
```
**Output:**
```
wayland
KDE
v_raton 2538 0.0 0.0 148820 4864 ? Ssl ago02 0:00 /usr/bin/kwin_wayland_wrapper --xwayland
v_raton 2549 1.1 0.4 2524100 77672 ? Sl ago02 15:51 /usr/bin/kwin_wayland --wayland-fd 7 --socket wayland-0 --xwayland-fd 8 --xwayland-fd 9 --xwayland-display :1 --xwayland-xauthority /run/user/1000/xauth_hCqoxl --xwayland
```
**Tool: bash**
**Input:**
```json
{
"command": "which wlr-randr gnome-randr kscreen-doctor 2>/dev/null; dpkg -l | grep -E \"wlr-randr|gnome-randr|kscreen|wlroots\" 2>/dev/null | head -5"
}
```
**Output:**
```
wlr-randr not found
gnome-randr not found
/usr/bin/kscreen-doctor
ii kde-config-screenlocker 6.3.5-1 amd64 KCM Module for kscreenlocker
ii kscreen 4:6.3.6-1 amd64 KDE monitor hotplug and screen handling
ii libkscreen-bin 4:6.3.4-1 amd64 library for screen management - helpers
ii libkscreen-data 4:6.3.4-1 all library for screen management - data files
ii libkscreenlocker6:amd64 6.3.5-1 amd64 Secure lock screen architecture
```
---
## Assistant (Build · DeepSeek V4 Pro · 5.1s)
_Thinking:_
KDE Wayland with KWin. We have `kscreen-doctor` available. Let me use it to:
1. Check what KWin sees for the monitor
2. Try to set the 2560x1080 mode
But first, the kernel still doesn't list 2560x1080 in the available modes. Let me check what modes KWin sees.
Also, let me check if the kernel actually does support this mode but it's just not being exposed. I should check what modes the kernel has available via drm_info or directly.
**Tool: bash**
**Input:**
```json
{
"command": "kscreen-doctor --outputs 2>&1"
}
```
**Output:**
```
[01;32mOutput: [0;0m1 eDP-1
[01;31mdisabled[0;0m
[01;32mconnected[0;0m
[01;31mpriority 0[0;0m
[01;33mPanel[0;0m
[01;34mModes: [0;0m 1:[01;32m1920x1080@60*[0;0m! 2:1920x1080@48 3:1280x1024@60 4:1280x1024@60 5:1024x768@60 6:1024x768@60 7:1280x800@60 8:1280x800@60 9:1600x900@60 10:1600x900@60 11:1368x768@60 12:1368x768@60 13:1280x720@60 14:1280x720@60
[01;33m Geometry: [0;0m-1600,0 1600x900
[01;33m Scale: [0;0m1.2
[01;33m Rotation: [0;0m1
[01;33m Overscan: [0;0m0
[01;33m Vrr: [0;0mincapable
[01;33m RgbRange: [0;0mAutomatic
[01;33m HDR: [0;0mincapable
[01;33m Wide Color Gamut: [0;0mincapable
[01;33m ICC profile: [0;0mnone
[01;33m Color profile source: [0;0msRGB
[01;33m Color power preference: [0;0mprefer efficiency and performance
[01;33m Brightness control: [0;0msupported, set to 30% and dimming to 100%
[01;32mOutput: [0;0m2 HDMI-A-1
[01;32menabled[0;0m
[01;32mconnected[0;0m
[01;32mpriority 1[0;0m
[01;33mHDMI[0;0m
[01;34mModes: [0;0m 15:[01;32m1920x1080@60*[0;0m 16:1920x1080@60! 17:1920x1080@60 18:1920x1080@50 19:1680x1050@60 20:1600x900@60 21:1280x1024@75 22:1280x1024@60 23:1280x800@60 24:1152x864@60 25:1280x720@60 26:1280x720@60 27:1280x720@60 28:1280x720@50 29:1024x768@75 30:1024x768@60 31:832x624@75 32:800x600@75 33:800x600@60 34:720x576@50 35:720x480@60 36:720x480@60 37:640x480@75 38:640x480@60 39:640x480@60 40:640x480@60
[01;33m Geometry: [0;0m0,0 1829x1029
[01;33m Scale: [0;0m1.05
[01;33m Rotation: [0;0m1
[01;33m Overscan: [0;0m0
[01;33m Vrr: [0;0mincapable
[01;33m RgbRange: [0;0mAutomatic
[01;33m HDR: [0;0mdisabled
[01;33m Wide Color Gamut: [0;0mdisabled
[01;33m ICC profile: [0;0mnone
[01;33m Color profile source: [0;0msRGB
[01;33m Color power preference: [0;0mprefer accuracy
[01;33m Brightness control: [0;0msupported, set to 64% and dimming to 100%
```
**Tool: bash**
**Input:**
```json
{
"command": "kscreen-doctor --json 2>&1 | python3 -m json.tool 2>/dev/null || kscreen-doctor --json 2>&1"
}
```
**Output:**
```
{
"features": 255,
"outputs": [
{
"clones": [],
"connected": true,
"currentModeId": "1",
"enabled": false,
"followPreferredMode": false,
"icon": "",
"id": 1,
"modes": [
{
"id": "1",
"name": "1920x1080@60",
"refreshRate": 60.02000045776367,
"size": {
"height": 1080,
"width": 1920
}
},
{
"id": "10",
"name": "1600x900@60",
"refreshRate": 59.94599914550781,
"size": {
"height": 900,
"width": 1600
}
},
{
"id": "11",
"name": "1368x768@60",
"refreshRate": 59.88199996948242,
"size": {
"height": 768,
"width": 1368
}
},
{
"id": "12",
"name": "1368x768@60",
"refreshRate": 59.88199996948242,
"size": {
"height": 768,
"width": 1368
}
},
{
"id": "13",
"name": "1280x720@60",
"refreshRate": 59.85499954223633,
"size": {
"height": 720,
"width": 1280
}
},
{
"id": "14",
"name": "1280x720@60",
"refreshRate": 59.85499954223633,
"size": {
"height": 720,
"width": 1280
}
},
{
"id": "2",
"name": "1920x1080@48",
"refreshRate": 47.981998443603516,
"size": {
"height": 1080,
"width": 1920
}
},
{
"id": "3",
"name": "1280x1024@60",
"refreshRate": 59.89500045776367,
"size": {
"height": 1024,
"width": 1280
}
},
{
"id": "4",
"name": "1280x1024@60",
"refreshRate": 59.89500045776367,
"size": {
"height": 1024,
"width": 1280
}
},
{
"id": "5",
"name": "1024x768@60",
"refreshRate": 59.91999816894531,
"size": {
"height": 768,
"width": 1024
}
},
{
"id": "6",
"name": "1024x768@60",
"refreshRate": 59.91999816894531,
"size": {
"height": 768,
"width": 1024
}
},
{
"id": "7",
"name": "1280x800@60",
"refreshRate": 59.810001373291016,
"size": {
"height": 800,
"width": 1280
}
},
{
"id": "8",
"name": "1280x800@60",
"refreshRate": 59.810001373291016,
"size": {
"height": 800,
"width": 1280
}
},
{
"id": "9",
"name": "1600x900@60",
"refreshRate": 59.94599914550781,
"size": {
"height": 900,
"width": 1600
}
}
],
"name": "eDP-1",
"pos": {
"x": -1600,
"y": 0
},
"preferredModes": [
"1"
],
"priority": 0,
"replicationSource": 0,
"rgbRange": 0,
"rotation": 1,
"scale": 1.2,
"size": {
"height": 1080,
"width": 1920
},
"sizeMM": {
"height": 194,
"width": 344
},
"type": 7
},
{
"clones": [],
"connected": true,
"currentModeId": "15",
"enabled": true,
"followPreferredMode": false,
"hdr": false,
"icon": "",
"id": 2,
"modes": [
{
"id": "15",
"name": "1920x1080@60",
"refreshRate": 60,
"size": {
"height": 1080,
"width": 1920
}
},
{
"id": "16",
"name": "1920x1080@60",
"refreshRate": 60,
"size": {
"height": 1080,
"width": 1920
}
},
{
"id": "17",
"name": "1920x1080@60",
"refreshRate": 59.939998626708984,
"size": {
"height": 1080,
"width": 1920
}
},
{
"id": "18",
"name": "1920x1080@50",
"refreshRate": 50,
"size": {
"height": 1080,
"width": 1920
}
},
{
"id": "19",
"name": "1680x1050@60",
"refreshRate": 59.882999420166016,
"size": {
"height": 1050,
"width": 1680
}
},
{
"id": "20",
"name": "1600x900@60",
"refreshRate": 60,
"size": {
"height": 900,
"width": 1600
}
},
{
"id": "21",
"name": "1280x1024@75",
"refreshRate": 75.0250015258789,
"size": {
"height": 1024,
"width": 1280
}
},
{
"id": "22",
"name": "1280x1024@60",
"refreshRate": 60.02000045776367,
"size": {
"height": 1024,
"width": 1280
}
},
{
"id": "23",
"name": "1280x800@60",
"refreshRate": 59.90999984741211,
"size": {
"height": 800,
"width": 1280
}
},
{
"id": "24",
"name": "1152x864@60",
"refreshRate": 59.96699905395508,
"size": {
"height": 864,
"width": 1152
}
},
{
"id": "25",
"name": "1280x720@60",
"refreshRate": 60,
"size": {
"height": 720,
"width": 1280
}
},
{
"id": "26",
"name": "1280x720@60",
"refreshRate": 60,
"size": {
"height": 720,
"width": 1280
}
},
{
"id": "27",
"name": "1280x720@60",
"refreshRate": 59.939998626708984,
"size": {
"height": 720,
"width": 1280
}
},
{
"id": "28",
"name": "1280x720@50",
"refreshRate": 50,
"size": {
"height": 720,
"width": 1280
}
},
{
"id": "29",
"name": "1024x768@75",
"refreshRate": 75.02899932861328,
"size": {
"height": 768,
"width": 1024
}
},
{
"id": "30",
"name": "1024x768@60",
"refreshRate": 60.00400161743164,
"size": {
"height": 768,
"width": 1024
}
},
{
"id": "31",
"name": "832x624@75",
"refreshRate": 74.5510025024414,
"size": {
"height": 624,
"width": 832
}
},
{
"id": "32",
"name": "800x600@75",
"refreshRate": 75,
"size": {
"height": 600,
"width": 800
}
},
{
"id": "33",
"name": "800x600@60",
"refreshRate": 60.31700134277344,
"size": {
"height": 600,
"width": 800
}
},
{
"id": "34",
"name": "720x576@50",
"refreshRate": 50,
"size": {
"height": 576,
"width": 720
}
},
{
"id": "35",
"name": "720x480@60",
"refreshRate": 60,
"size": {
"height": 480,
"width": 720
}
},
{
"id": "36",
"name": "720x480@60",
"refreshRate": 59.939998626708984,
"size": {
"height": 480,
"width": 720
}
},
{
"id": "37",
"name": "640x480@75",
"refreshRate": 75,
"size": {
"height": 480,
"width": 640
}
},
{
"id": "38",
"name": "640x480@60",
"refreshRate": 60,
"size": {
"height": 480,
"width": 640
}
},
{
"id": "39",
"name": "640x480@60",
"refreshRate": 59.939998626708984,
"size": {
"height": 480,
"width": 640
}
},
{
"id": "40",
"name": "640x480@60",
"refreshRate": 59.939998626708984,
"size": {
"height": 480,
"width": 640
}
}
],
"name": "HDMI-A-1",
"pos": {
"x": 0,
"y": 0
},
"preferredModes": [],
"priority": 1,
"replicationSource": 0,
"rgbRange": 0,
"rotation": 1,
"scale": 1.05,
"sdr-brightness": 248,
"size": {
"height": 1080,
"width": 1920
},
"sizeMM": {
"height": 254,
"width": 601
},
"type": 6,
"wcg": false
}
],
"screen": {
"currentSize": {
"height": 1029,
"width": 1829
},
"id": 0,
"maxActiveOutputsCount": 2,
"maxSize": {
"height": 64000,
"width": 64000
},
"minSize": {
"height": 0,
"width": 0
}
},
"tabletModeAvailable": false,
"tabletModeEngaged": false
}
```
---
## Assistant (Build · DeepSeek V4 Pro · 27.4s)
_Thinking:_
Now I can see the full picture on Wayland/KDE:
1. **eDP-1** (internal laptop display): disabled, 1920x1080 panel
2. **HDMI-A-1** (LG Ultrawide): enabled, max mode is 1920x1080, no preferred modes listed, current geometry is 1829x1029 (which is 1920x1080 with a 1.05 scale factor applied: 1920/1.05 ≈ 1829, 1080/1.05 ≈ 1029)
The key finding: `"preferredModes": []` for HDMI-A-1 - the kernel isn't detecting ANY preferred mode from the EDID for this output. The max available is 1920x1080.
The problem is at kernel level - the i915 driver is not accepting the 2560x1080 detailed timing from the EDID. This is a known limitation with Ice Lake HDMI via LSPCON.
Solutions:
1. **Custom EDID firmware** - create a custom EDID and load it via kernel parameter at boot
2. **Force mode via kernel cmdline**: `video=HDMI-A-1:2560x1080@60D`
3. **Custom modeline in kwin** - not directly possible with kwin
Let me try the custom EDID approach. I need to:
1. Save the current EDID
2. Modify it to only include what the driver will accept
3. Or create a minimal EDID with just 2560x1080
Actually, let me try a different approach first. On Wayland/KDE, we can try using `kscreen-doctor` to set a custom mode. Actually, kscreen-doctor doesn't support custom modes.
Let me try the kernel command line approach: `video=HDMI-A-1:2560x1080@60D`
This requires a reboot. But first let me try seeing if the i915 kernel module has any parameters that might help. Let me check the values of the existing parameters.
Actually, let me try the EDID override approach. The kernel has built-in support for overriding EDID via firmware files. Here's the plan:
1. Save the current EDID to a file
2. Create a modified version or use it as-is but force it via `drm.edid_firmware`
3. Add kernel boot parameter
But actually, since the kernel already reads the EDID and sees the 2560x1080 mode (the Xorg log confirms it parses it), the issue is that it's REJECTING the mode during mode validation. Overriding the EDID with the same EDID won't help.
Let me think about what validation step might be failing:
- Pixel clock: 181.25 MHz - within HDMI 1.4 limit (340 MHz)
- Horizontal resolution: 2560 - within Gen11 pipe limits
- The H-freq is 66.64 kHz, within the reported monitor range of 90-90 kHz
Wait! The monitor reports "H min: 90 H max: 90 kHz"! That means the monitor says its horizontal sync range is exactly 90 kHz. But 2560x1080 @ 60Hz requires only 66.64 kHz horizontal sync, which is BELOW 90 kHz.
Wait, let me re-read the EDID:
```
Display Range Limits:
Monitor ranges (Bare Limits): 48-75 Hz V, 90-90 kHz H, max dotclock 240 MHz
```
H min = 90 kHz, H max = 90 kHz. This means the monitor claims to only support exactly 90 kHz horizontal sync. This is clearly wrong/invalid for a monitor that supports many different modes. But Xorg seems to override this to 245 MHz somehow.
But the EDID parsing in Xorg says "PixClock max 245 MHz" even though EDID says 240 MHz. Not sure why.
Anyway, the H sync range being fixed at 90 kHz might cause issues with mode validation since 2560x1080 @ 60Hz requires 66.64 kHz which is below 90 kHz. But then 1920x1080 requires 67.5 kHz, also below 90 kHz, and that IS being offered.
So the H-freq limit isn't the problem. The modes being rejected must be for a different reason.
Let me focus on what DOES work and find a practical solution:
1. The kernel mode list doesn't have 2560x1080
2. This is likely a bandwidth/pipe limitation on Ice Lake
Let me try the kernel command line parameter approach. Or, even better, try a completely different physical connection approach - maybe there's a setting on the monitor that affects what EDID it sends.
Actually, let me try something practical and check if there are any monitor settings related to HDMI version or EDID. Also, I should try the `video=` kernel parameter.
But first, let me try the immediate workaround: set HDMI-A-1 to 1920x1080@60 which should at least give a proper 16:9 image. Then we can work on getting 21:9.
Actually wait - the monitor ALREADY has 1920x1080 configured as the current mode! But the geometry is 1829x1029 because of the 1.05 scale factor.
Let me try setting it to 1920x1080 WITHOUT scaling first, see if that works properly. If 1920x1080 works, the monitor will show black bars on the sides but at least the image will be crisp. Then we can work on the custom EDID approach.
Actually, the real fix is at the kernel level. Let me try:
1. First, set a proper 1920x1080 without any weird scaling
2. Then try the kernel command line approach
3. Then custom EDID if needed
For the kernel approach, I need to modify /etc/default/grub and add the `video=` parameter.
Agora está claro — no **Wayland/KDE**, o kernel i915 não está expondo 2560x1080. Os modos aparecem corretamente no JSON do kscreen-doctor mas só chegam até 1920x1080. Vou primeiro corrigir o scaling atual (que está distorcendo para 1829x1029) e depois tentar forçar o modo nativo:
**Tool: bash**
**Input:**
```json
{
"command": "kscreen-doctor output.HDMI-A-1.mode.15 output.HDMI-A-1.scale.1 2>&1"
}
```
**Output:**
```
kscreen.doctor: Taddaaa! Found mode "15" "1920x1080@60"
kscreen.doctor: Output 2 set mode "15"
```
---
## Assistant (Build · DeepSeek V4 Pro · 12.4s)
_Thinking:_
Good, 1920x1080 is now set with scale 1. Now the critical thing is to try forcing 2560x1080 at the kernel level. The approach:
1. Add `video=HDMI-A-1:2560x1080@60D` to kernel command line
2. Also try `drm.edid_firmware=HDMI-A-1:edid/lg-ultrawide.bin` with a custom EDID
Let me try the kernel parameter approach first. I need to modify the GRUB configuration.
Actually, let me first check the current grub config and kernel cmdline.
1920x1080 sem scaling já está aplicado. Agora vou forçar 2560x1080 via parâmetro do kernel. Primeiro verifico o GRUB:
**Tool: bash**
**Input:**
```json
{
"command": "cat /etc/default/grub | grep -E \"GRUB_CMDLINE_LINUX|GRUB_CMDLINE_LINUX_DEFAULT\""
}
```
**Output:**
```
GRUB_CMDLINE_LINUX_DEFAULT="quiet splash"
GRUB_CMDLINE_LINUX=""
```
**Tool: bash**
**Input:**
```json
{
"command": "cat /proc/cmdline"
}
```
**Output:**
```
BOOT_IMAGE=/boot/vmlinuz-6.12.100+deb13-amd64 root=UUID=9757ad5c-2c4e-49af-9220-b8363a3c209c ro quiet splash
```
---
## Assistant (Build · DeepSeek V4 Pro · 15.9s)
_Thinking:_
I need to add a kernel parameter to force 2560x1080. There are two approaches:
1. `video=HDMI-A-1:2560x1080@60D` - tries to add the mode to the connector
2. Custom EDID firmware override
Let me try approach #1 first since it's simpler. I'll add it to GRUB_CMDLINE_LINUX_DEFAULT.
Actually, let me first create a custom EDID override since that's more reliable. The issue is likely that the i915 driver is validating the mode against some constraint and rejecting it. A custom EDID might not help if the same constraint applies.
But actually, `video=HDMI-A-1:2560x1080@60D` is designed specifically for this case - it tells the kernel to force-add this mode to the connector. The `D` suffix means "digital" and tells the kernel to try harder to add it.
Let me also try `video=HDMI-A-1:2560x1080MR@60` where `MR` means "monitor reduced blanking" mode.
Let me add both approaches: the video= parameter and also a drm.edid_firmware approach.
Actually, the most reliable approach might be to combine both. Let me first try the simple video= parameter, and if that doesn't work, try the EDID firmware approach.
But for the EDID firmware, I need to create a proper EDID binary. Let me do both in parallel - edit the grub config and create the EDID firmware file.
For the custom EDID, I'll take the original EDID and modify it to have only the 2560x1080@60 mode as the preferred detailed timing, with correct checksum.
Actually, let me just try the video= parameter first. It's simpler and faster. If the user reboots and it doesn't work, we can try the EDID firmware approach.
Let me edit /etc/default/grub.
**Tool: read**
**Input:**
```json
{
"filePath": "/etc/default/grub"
}
```
**Output:**
```
/etc/default/grub
file
1: # If you change this file or any /etc/default/grub.d/*.cfg file,
2: # run 'update-grub' afterwards to update /boot/grub/grub.cfg.
3: # For full documentation of the options in these files, see:
4: # info -f grub -n 'Simple configuration'
5:
6: GRUB_DEFAULT=0
7: GRUB_TIMEOUT=5
8: GRUB_DISTRIBUTOR=`( . /etc/os-release && echo ${NAME} )`
9: GRUB_CMDLINE_LINUX_DEFAULT="quiet splash"
10: GRUB_CMDLINE_LINUX=""
11:
12: # If your computer has multiple operating systems installed, then you
13: # probably want to run os-prober. However, if your computer is a host
14: # for guest OSes installed via LVM or raw disk devices, running
15: # os-prober can cause damage to those guest OSes as it mounts
16: # filesystems to look for things.
17: GRUB_DISABLE_OS_PROBER=false
18:
19: # Uncomment to enable BadRAM filtering, modify to suit your needs
20: # This works with Linux (no patch required) and with any kernel that obtains
21: # the memory map information from GRUB (GNU Mach, kernel of FreeBSD ...)
22: #GRUB_BADRAM="0x01234567,0xfefefefe,0x89abcdef,0xefefefef"
23:
24: # Uncomment to disable graphical terminal
25: #GRUB_TERMINAL=console
26:
27: # The resolution used on graphical terminal
28: # note that you can use only modes which your graphic card supports via VBE/GOP/UGA
29: # you can see them in real GRUB with the command `videoinfo'
30: #GRUB_GFXMODE=640x480
31:
32: # Uncomment if you don't want GRUB to pass "root=UUID=xxx" parameter to Linux
33: #GRUB_DISABLE_LINUX_UUID=true
34:
35: # Uncomment to disable generation of recovery mode menu entries
36: #GRUB_DISABLE_RECOVERY="true"
37:
38: # Uncomment to get a beep at grub start
39: #GRUB_INIT_TUNE="480 440 1"
(End of file - total 39 lines)
```
---
## Assistant (Build · DeepSeek V4 Pro · 19.2s)
_Thinking:_
Let me edit the GRUB_CMDLINE_LINUX_DEFAULT to add the video= parameter. I'll add `video=HDMI-A-1:2560x1080@60D` to force the kernel to add the 2560x1080 mode.
The `D` suffix indicates a digital display and tells the DRM subsystem to add this mode as a detailed timing.
Let me also try with the correct modeline using CVT-RB timings: `video=HDMI-A-1:2560x1080MR@60` where `M` specifies the mode is calculated using CVT and `R` means reduced blanking.
Actually, the `D` option tries to add it as a driver-generated mode. The format is:
- `video=:x[M][R][-][@][i][m][eDd]`
Let me try with both `D` and the explicit mode. The safest is to provide explicit modeline parameters:
`video=HDMI-A-1:2560x1080MR@60`
Wait, actually the kernel `video=` parameter has limited support for forced modes. The modern approach is `drm.edid_firmware`. Let me try both.
Let me start with `video=HDMI-A-1:2560x1080@60e` which should try to force the mode. The `e` flag forces the output to be enabled even if not detected.
Actually, I think the best approach here is:
1. Create a custom EDID with only the 2560x1080 mode
2. Load it via `drm.edid_firmware=HDMI-A-1:edid/lg2560x1080.bin`
This is more reliable than the video= parameter because it replaces the EDID entirely.
Let me do both: add the video= parameter and create the EDID firmware.
**Tool: edit**
**Input:**
```json
{
"filePath": "/etc/default/grub",
"oldString": "GRUB_CMDLINE_LINUX_DEFAULT=\"quiet splash\"",
"newString": "GRUB_CMDLINE_LINUX_DEFAULT=\"quiet splash video=HDMI-A-1:2560x1080@60D\""
}
```
**Error:**
```
The user rejected permission to use this specific tool call.
```
---
## User
quero apenas que verifique sem mmudar a viabilidade
---
## Assistant (Plan · DeepSeek V4 Pro · 16.4s)
_Thinking:_
The user wants me to only verify feasibility without making changes. They're in plan/read-only mode. Let me summarize the findings and present a plan.
Let me verify a few more things about the kernel's capability and whether there's a known limitation with Ice Lake HDMI.
Claro. Vou apenas analisar a viabilidade sem alterar nada. Aqui está o diagnóstico completo:
---
## Diagnóstico
| Item | Status |
|------|--------|
| **Monitor** | LG ULTRAWIDE, EDID lido corretamente |
| **Resolução nativa** | **2560x1080 @ 60Hz** (181.25 MHz pixel clock, CVT-RB) |
| **Outros modos no EDID** | 2560x1440@60, 2560x1080@75, 3840x2160@24/25/30 |
| **TMDS máximo do monitor** | 300 MHz |
| **Modos expostos pelo kernel** | Máximo **1920x1080** — 2560x1080 está **ausente** |
| **GPU** | Intel Iris Plus G1 (Ice Lake, Gen11) |
| **Driver** | i915 (kernel) + KWin (Wayland/KDE) |
| **Causa raiz** | O driver i915 do kernel **rejeita** os modos >1920x1080 neste conector HDMI |
---
## Por que o kernel rejeita 2560x1080?
O Ice Lake **não tem HDMI nativo** — ele usa um chip **LSPCON** (Level Shifter/Protocol Converter) na placa-mãe para converter DisplayPort em HDMI. O i915 frequentemente limita o pixel clock máximo nesses conversores. Embora o EDID diga 300 MHz e o modo precise de apenas 181.25 MHz, o driver impõe um limite interno mais baixo (~165-200 MHz dependendo da revisão do LSPCON/firmware).
Isso **não é um bug do cabo HDMI 2.1** — é uma limitação da implementação HDMI da GPU Ice Lake.
---
## Plano de ação (3 opções, da mais simples à mais confiável)
### Opção 1: Parâmetro de kernel `video=` (tentar primeiro)
Adicionar em `/etc/default/grub`:
```
GRUB_CMDLINE_LINUX_DEFAULT="quiet splash video=HDMI-A-1:2560x1080@60D"
```
Depois rodar `sudo update-grub && reboot`. Pode ou não funcionar — depende se o i915 aceita o modo forçado.
### Opção 2: EDID firmware customizado (mais confiável)
Criar um EDID binário mínimo que declare 2560x1080 como único modo preferido, salvar em `/lib/firmware/edid/lg2560x1080.bin` e adicionar ao kernel:
```
drm.edid_firmware=HDMI-A-1:edid/lg2560x1080.bin
```
Força o kernel a usar o EDID alternativo, contornando a rejeição do EDID original.
### Opção 3: Aceitar a limitação (se 1 e 2 falharem)
Usar **1920x1080 com black bars** nas laterais. Nenhuma ferramenta de userspace (xrandr, kscreen-doctor) consegue adicionar modos que o kernel não aceita.
---
Quer que eu execute alguma dessas opções, ou prefere investigar mais alguma coisa?
---
## User
existte algume na internet com mesmo notebook que ja resolveu isso?
---
## Assistant (Plan · DeepSeek V4 Pro · 7.4s)
_Thinking:_
The user wants me to search the internet to see if anyone with the same laptop (Dell + Intel Ice Lake Iris Plus G1) has solved the ultrawide HDMI resolution issue with i915 driver.
Let me search for this. The key details are:
- Dell laptop with Intel Iris Plus Graphics G1 (Ice Lake)
- HDMI ultrawide monitor (2560x1080) limitation
- i915 driver rejecting modes > 1920x1080
I should search for Ice Lake HDMI resolution limitation, Dell Ice Lake ultrawide, LSPCON issues, etc.
**Tool: webfetch**
**Input:**
```json
{
"url": "https://www.google.com/search?q=Intel+Ice+Lake+Iris+Plus+G1+HDMI+2560x1080+ultrawide+not+working+i915",
"format": "text"
}
```
**Output:**
```
Google SearchSe você estiver com problemas para acessar a Pesquisa Google, clique aqui ou envie um feedback.
```
**Tool: webfetch**
**Input:**
```json
{
"url": "https://www.google.com/search?q=Ice+Lake+LSPCON+HDMI+max+resolution+2560x1080+linux+i915",
"format": "text"
}
```
**Output:**
```
Google SearchSe você estiver com problemas para acessar a Pesquisa Google, clique aqui ou envie um feedback.
```
---
## Assistant (Plan · DeepSeek V4 Pro · 6.1s)
_Thinking:_
The Google searches didn't return useful results. Let me try more specific searches related to this issue.
**Tool: webfetch**
**Input:**
```json
{
"format": "text",
"url": "https://duckduckgo.com/html/?q=Intel+Ice+Lake+i915+HDMI+ultrawide+2560x1080+resolution+limit+linux"
}
```
**Output:**
```
Intel Ice Lake i915 HDMI ultrawide 2560x1080 resolution limit linux at DuckDuckGo
All Regions
Argentina
Australia
Austria
Belgium (fr)
Belgium (nl)
Brazil
Bulgaria
Canada (en)
Canada (fr)
Catalonia
Chile
China
Colombia
Croatia
Czech Republic
Denmark
Estonia
Finland
France
Germany
Greece
Hong Kong
Hungary
Iceland
India (en)
Indonesia (en)
Ireland
Israel (en)
Italy
Japan
Korea
Latvia
Lithuania
Malaysia (en)
Mexico
Netherlands
New Zealand
Norway
Pakistan (en)
Peru
Philippines (en)
Poland
Portugal
Romania
Russia
Saudi Arabia
Singapore
Slovakia
Slovenia
South Africa
Spain (ca)
Spain (es)
Sweden
Switzerland (de)
Switzerland (fr)
Taiwan
Thailand (en)
Turkey
US (English)
US (Spanish)
Ukraine
United Kingdom
Vietnam (en)
Any Time
Past Day
Past Week
Past Month
Past Year
Maximum resolution not being detected (Linux driver i915 and Intel Iris ...
community.intel.com/t5/Graphics/Maximum-resolution-not-being-detected-Linux-driver-i915-and/m-p/1212593
Hi all, My Lenovo S145 with a Intel Iris Plus Graphics G1 GPU is not detecting the maximum resolution (2560x1080) of an LG Ultrawide monitor 29WK500/50S in a Gnome/Wayland session, but works in a X11 (I can manually add and set with xrandr). Strangely, the same SO/Gnome/Wayland/Kernel Driver and Mon...
Maximum possible resolution is not detected (in Gnome Wayland with i915 ...
discussion.fedoraproject.org/t/maximum-possible-resolution-is-not-detected-in-gnome-wayland-with-i915-gpu/77492/2
Hi all, My Lenovo S145 with a Intel Iris Plus Graphics G1 GPU is not detecting the maximum resolution (2560x1080) of an LG Ultrawide monitor 29WK500/50S in a Gnome/Wayland session, but works in a X11 (I can manually add and set with xrandr). Strangely, the same SO/Gnome/Wayland/Kernel Driver and M…
nic0der-im/fix-ultrawide-intel-notebook-hdmi - GitHub
github.com/nic0der-im/fix-ultrawide-intel-notebook-hdmi
Many Intel laptops implement their HDMI port as a DisplayPort++ (Dual-Mode) output with an integrated DP-to-HDMI protocol converter. This converter has a maximum TMDS clock of 165 MHz (the DVI single-link limit). The native resolution of a 2560x1080 ultrawide at 60 Hz requires a pixel clock of 185.58 MHz, which exceeds this limit. The Linux kernel's i915 driver correctly identifies this and ...
Ultrawide Monitor at Native Resolution - EndeavourOS
forum.endeavouros.com/t/ultrawide-monitor-at-native-resolution/36089
I'm at my wits' end trying to figure out how to get my LG 34WL500-B Ultrawide monitor to run at native 2560x1080 resolution on EOS Cassini. My setup: Dell Inspiron 3910 Intel i7 12700 processor Onboard UHD 770 graphics HDMI out to monitor (no DP on monitor side) Budgie DE Attempted lightdm and gdm WMs Kernel support shouldn't be an issue on 6.1.6, and I've verified the i915 driver is ...
Re:Maximum resolution not being detected (Linux driver i915 and Intel ...
community.intel.com/t5/Graphics/Maximum-resolution-not-being-detected-Linux-driver-i915-and/m-p/1215289?profile.language=ko
Hi all, My Lenovo S145 with a Intel Iris Plus Graphics G1 GPU is not detecting the maximum resolution (2560x1080) of an LG Ultrawide monitor 29WK500/50S in a Gnome/Wayland session, but works in a X11 (I can manually add and set with xrandr).
drm/i915 Intel GFX Driver — The Linux Kernel documentation
www.kernel.org/doc/html/latest/gpu/i915.html
drm/i915 Intel GFX Driver ¶ The drm/i915 driver supports all (with the exception of some very early models) integrated GFX chipsets with both Intel display and rendering blocks. This excludes a set of SoC platforms with an SGX rendering unit, those have basic support through the gma500 drm driver.
Ultrawide resolution not working [SOLVED] - Linux Mint Forums
forums.linuxmint.com/viewtopic.php?t=389338
Just upgraded from linux mint 18 to the latest release and my monitor doesnt get the maximum resolution 2560x1080. I have tried this:
Ubuntu 24.04.3 LTS fails to support ultrawide (2560x1080@75) resolution
askubuntu.com/questions/1554927/ubuntu-24-04-3-lts-fails-to-support-ultrawide-2560x108075-resolution
2025-08-23T00:00:00.0000000
I have an LG HDR WFHD I'm trying to use with my Intel Core Ultra 5 125U with the maximum supported mode of 2560x1080, but the only mode I can use is 1920x1080. The desired resolution works fine on Windows, and used to work on Ubuntu 22.04 on another device with an Nvidia 2080 card.
Can't customize resolution 2560x1080 for ultrawide monitor in Ubuntu 22.04
askubuntu.com/questions/1456885/cant-customize-resolution-2560x1080-for-ultrawide-monitor-in-ubuntu-22-04
I'm facing some troubles in the first configuration for ultrawide monitor. My laptop is a dell vostro 3501, core i5-1035G1 and monitor is a LG Ultrawide 25.7, model 26WQ500-B, 2560x1080, 75Hz To cr...
2560x1080 resolution unavailable for Ultrawide monitor
forums.opensuse.org/t/2560x1080-resolution-unavailable-for-ultrawide-monitor/139514
Have just got an LG 34WL500 monitor that is capable of 2560x1080, and this works fine when booted into Windows10. Unfortunately it seems not to work in any Linux distro… (Max Res 1920x1080) Is there any simple fix for this, or is it a case of having to go "under the hood"?? (And if so, how…?) Just using the standard on-board graphics. Unfortunately the monitor only has 2x hdmi ports ...
Feedback
```
**Tool: webfetch**
**Input:**
```json
{
"format": "text",
"url": "https://duckduckgo.com/html/?q=dell+ice+lake+laptop+HDMI+external+monitor+resolution+2560+not+detected+linux+site:reddit.com"
}
```
**Output:**
```
dell ice lake laptop HDMI external monitor resolution 2560 not detected linux site:reddit.com at DuckDuckGo
All Regions
Argentina
Australia
Austria
Belgium (fr)
Belgium (nl)
Brazil
Bulgaria
Canada (en)
Canada (fr)
Catalonia
Chile
China
Colombia
Croatia
Czech Republic
Denmark
Estonia
Finland
France
Germany
Greece
Hong Kong
Hungary
Iceland
India (en)
Indonesia (en)
Ireland
Israel (en)
Italy
Japan
Korea
Latvia
Lithuania
Malaysia (en)
Mexico
Netherlands
New Zealand
Norway
Pakistan (en)
Peru
Philippines (en)
Poland
Portugal
Romania
Russia
Saudi Arabia
Singapore
Slovakia
Slovenia
South Africa
Spain (ca)
Spain (es)
Sweden
Switzerland (de)
Switzerland (fr)
Taiwan
Thailand (en)
Turkey
US (English)
US (Spanish)
Ukraine
United Kingdom
Vietnam (en)
Any Time
Past Day
Past Week
Past Month
Past Year
Laptop HDMI external display not being detected : r/archlinux - Reddit
www.reddit.com/r/archlinux/comments/10hrlg2/laptop_hdmi_external_display_not_being_detected/
The monitor is not being detected for some reason.I know that the cable and monitor are in working condition because the GRUB menu is displayed on both the laptop display and external display while the laptop is booting up. However, as soon as it boots into LightDM, the second display stops working.
External Display Not Detected : r/Fedora - Reddit
www.reddit.com/r/Fedora/comments/zr3cj6/external_display_not_detected/
I connected my laptop to an external display through HDMI. While the computer is booting up everything is fine and the monitor displays the image, but as soon as the computer boots up the monitor says that it has no signal and turns off.
External Monitor Connected through HDMI Not Detected by Laptop
www.reddit.com/r/pop_os/comments/zndoct/external_monitor_connected_through_hdmi_not/
The external monitor does not even get detected when connected through HDMI. I would appreciate it if someone could share the solution, or explain the limitation.
External monitor through USB-C to HDMI has wrong resolution
www.reddit.com/r/archlinux/comments/rqbmgi/external_monitor_through_usbc_to_hdmi_has_wrong/
I have an external monitor connected through a USB-C to HDMI dongle which works, but it is detected with the wrong resolution. The monitor supports 2560x1440, but it is detected as supporting 3840x2160.
Resolution issue with Intel Xe graphics card : r/Dell - Reddit
www.reddit.com/r/Dell/comments/15mofgc/resolution_issue_with_intel_xe_graphics_card/
Resolution issue with Intel Xe graphics card I recently bought a Dell XPS 13 2-in-1 laptop and a docking station that I can add 2 more monitors to. However, my issue now is that they don't display the correct resolution.
Dell Laptop issue with external Monitor - Capped Resolution
www.reddit.com/r/laptops/comments/16nlgiq/dell_laptop_issue_with_external_monitor_capped/
I have this DELL Vostro 3510 laptop with an Intel Core i7-1165G7 processor with integrated Intel Iris XE Graphics and Windows 11. I've been using it with two monitors for quite some time: a 27" Xiaomi 2K monitor at 165Hz (which I also use with my personal gaming PC) connected via HDMI, and a 22" Benq Full HD monitor at 60Hz connected through a ...
My laptop does not support ultrawide monitors? : r/techsupport
www.reddit.com/r/techsupport/comments/q9pnpf/my_laptop_does_not_support_ultrawide_monitors/
My 6 year old graphics card has HDMI 2.0. Right on their product page for the Vostro 3500 it specifies HDMI 1.4 max resolution is 1080p. What you can do to get around this is buy a USB 3.0 dock (or USB3.0 to HDMI adapter). Either 3rd party or one by Dell. You may have poorer graphics performance going this route, but will be fine for business apps.
External monitor not detected through HDMI. : r/Dell - Reddit
www.reddit.com/r/Dell/comments/16allec/external_monitor_not_detected_through_hdmi/
I have an Inspiron 16 7610 and I have not been able to get any external monitors to work through the HDMI. The monitors can connect through the USB-C, but that port is needed for something else.
Second Monitor Is Not Detected (at all) : r/techsupport - Reddit
www.reddit.com/r/techsupport/comments/13rn6hc/second_monitor_is_not_detected_at_all/
The first few days the second monitor was doing fine then after a few days my pc can't detect the second monitor at all. I even bought a dedicated DP to the second monitor but the pc cannot detect it.
External Monitor Connected via HDMI + DisplayPort Adapter Not ... - Reddit
www.reddit.com/r/linuxmint/comments/iaktep/external_monitor_connected_via_hdmi_displayport/
External Monitor Connected via HDMI + DisplayPort Adapter Not Being Detected I've already done some googling and checked through this sub's solved threads, but couldn't find a solution that worked for me. I have an ASUS VivoBook Pro 17" laptop with a GeForce GTX 1050 graphics card and an HDMI port.
Feedback
```
---
## Assistant (Plan · DeepSeek V4 Pro · 9.0s)
_Thinking:_
Excellent! I found several very relevant results. Let me dig into the key ones:
1. **Intel Community forum**: Someone with the exact same issue - Lenovo S145 with Intel Iris Plus Graphics G1, LG Ultrawide monitor 2560x1080 not detected in Wayland but works in X11!
2. **GitHub repo**: `nic0der-im/fix-ultrawide-intel-notebook-hdmi` - This seems like a specific repo with a solution
3. **Fedora Discussion**: Same issue
4. **AskUbuntu**: Dell Vostro 3501, same GPU, same monitor issue
The key result is the GitHub repo `nic0der-im/fix-ultrawide-intel-notebook-hdmi` which mentions the TMDS clock limit of 165 MHz for DP-to-HDMI converters!
Also critically, the Intel Community thread says it works in X11 with xrandr but NOT in Wayland. That's interesting since the user is on Wayland.
Let me fetch the details of these pages.
Achei resultados **extremamente relevantes**! Há pessoas com o mesmo GPU (Iris Plus G1 Ice Lake) e o mesmo problema. Vou buscar os detalhes:
**Tool: webfetch**
**Input:**
```json
{
"format": "markdown",
"url": "https://github.com/nic0der-im/fix-ultrawide-intel-notebook-hdmi"
}
```
**Output:**
```
GitHub - nic0der-im/fix-ultrawide-intel-notebook-hdmi: Fix ultrawide 2560x1080 over HDMI on Dell Inspiron 3501 — EDID override for Intel i915 DP++ 165 MHz TMDS clock limit · GitHub
[Skip to content](#start-of-content)
## Navigation Menu
Toggle navigation
[](/)
[Sign in](/login?return_to=https%3A%2F%2Fgithub.com%2Fnic0der-im%2Ffix-ultrawide-intel-notebook-hdmi)
Appearance settings
- Platform
- AI CODE CREATION
- [
GitHub CopilotWrite better code with AI
](https://github.com/features/copilot)
- [
GitHub Copilot appDirect agents from issue to merge
](https://github.com/features/ai/github-app)
- [
MCP RegistryIntegrate external tools
](https://github.com/mcp)
- DEVELOPER WORKFLOWS
- [
ActionsAutomate any workflow
](https://github.com/features/actions)
- [
CodespacesInstant dev environments
](https://github.com/features/codespaces)
- [
IssuesPlan and track work
](https://github.com/features/issues)
- [
Code ReviewManage code changes
](https://github.com/features/code-review)
- [
Code QualityEnforce quality at merge
](https://github.com/features/code-quality)
- APPLICATION SECURITY
- [
GitHub Advanced SecurityFind and fix vulnerabilities
](https://github.com/security/advanced-security)
- [
Code securitySecure your code as you build
](https://github.com/security/advanced-security/code-security)
- [
Secret protectionStop leaks before they start
](https://github.com/security/advanced-security/secret-protection)
- EXPLORE
- [Why GitHub](https://github.com/why-github)
- [Documentation](https://docs.github.com)
- [Blog](https://github.blog)
- [Changelog](https://github.blog/changelog)
- [Marketplace](https://github.com/marketplace)
[View all features](https://github.com/features)
- Solutions
- BY COMPANY SIZE
- [Enterprises](https://github.com/enterprise)
- [Small and medium teams](https://github.com/team)
- [Startups](https://github.com/enterprise/startups)
- [Nonprofits](https://github.com/solutions/industry/nonprofits)
- BY USE CASE
- [App Modernization](https://github.com/solutions/use-case/app-modernization)
- [DevSecOps](https://github.com/solutions/use-case/devsecops)
- [DevOps](https://github.com/solutions/use-case/devops)
- [CI/CD](https://github.com/solutions/use-case/ci-cd)
- [View all use cases](https://github.com/solutions/use-case)
- BY INDUSTRY
- [Healthcare](https://github.com/solutions/industry/healthcare)
- [Financial services](https://github.com/solutions/industry/financial-services)
- [Manufacturing](https://github.com/solutions/industry/manufacturing)
- [Government](https://github.com/solutions/industry/government)
- [View all industries](https://github.com/solutions/industry)
[View all solutions](https://github.com/solutions)
- Resources
- EXPLORE BY TOPIC
- [AI](https://github.com/resources/articles?topic=ai)
- [Software Development](https://github.com/resources/articles?topic=software-development)
- [DevOps](https://github.com/resources/articles?topic=devops)
- [Security](https://github.com/resources/articles?topic=security)
- [View all topics](https://github.com/resources/articles)
- EXPLORE BY TYPE
- [Customer stories](https://github.com/customer-stories)
- [Events & webinars](https://github.com/resources/events)
- [Ebooks & reports](https://github.com/resources/whitepapers)
- [Business insights](https://github.com/solutions/executive-insights)
- [GitHub Skills](https://skills.github.com)
- SUPPORT & SERVICES
- [Documentation](https://docs.github.com)
- [Customer support](https://support.github.com)
- [Community forum](https://github.com/orgs/community/discussions)
- [Trust center](https://github.com/trust-center)
- [Partners](https://github.com/partners)
[View all resources](https://github.com/resources)
- Open Source
- COMMUNITY
- [
GitHub SponsorsFund open source developers
](https://github.com/open-source/sponsors)
- PROGRAMS
- [Security Lab](https://securitylab.github.com)
- [Maintainer Community](https://maintainers.github.com)
- [Accelerator](https://github.com/open-source/accelerator)
- [GitHub Stars](https://stars.github.com)
- [Archive Program](https://archiveprogram.github.com)
- REPOSITORIES
- [Topics](https://github.com/topics)
- [Trending](https://github.com/trending)
- [Collections](https://github.com/collections)
- Enterprise
- ENTERPRISE SOLUTIONS
- [
Enterprise platformAI-powered developer platform
](https://github.com/enterprise)
- AVAILABLE ADD-ONS
- [
GitHub Advanced SecurityEnterprise-grade security features
](https://github.com/security/advanced-security)
- [
Copilot for BusinessEnterprise-grade AI features
](https://github.com/features/copilot/copilot-business)
- [
Premium SupportEnterprise-grade 24/7 support
](https://github.com/enterprise/premium-support)
- [Pricing](https://github.com/pricing)
Search or jump to...
# Search code, repositories, users, issues, pull requests...
Search
Clear
[Search syntax tips](https://docs.github.com/search-github/github-code-search/understanding-github-code-search-syntax)
# Provide feedback
We read every piece of feedback, and take your input very seriously.
Include my email address so I can be contacted
Cancel Submit feedback
# Saved searches
## Use saved searches to filter your results more quickly
Name
Query
To see all available qualifiers, see our [documentation](https://docs.github.com/search-github/github-code-search/understanding-github-code-search-syntax).
Cancel Create saved search
[Sign in](/login?return_to=https%3A%2F%2Fgithub.com%2Fnic0der-im%2Ffix-ultrawide-intel-notebook-hdmi)
[Sign up](/signup?ref_cta=Sign+up&ref_loc=header+logged+out&ref_page=%2F%3Cuser-name%3E%2F%3Crepo-name%3E&source=header-repo&source_repo=nic0der-im%2Ffix-ultrawide-intel-notebook-hdmi)
Appearance settings
Resetting focus
You signed in with another tab or window. Reload to refresh your session. You signed out in another tab or window. Reload to refresh your session. You switched accounts on another tab or window. Reload to refresh your session. Dismiss alert
[nic0der-im](/nic0der-im) / **[fix-ultrawide-intel-notebook-hdmi](/nic0der-im/fix-ultrawide-intel-notebook-hdmi)** Public
- [Notifications](/login?return_to=%2Fnic0der-im%2Ffix-ultrawide-intel-notebook-hdmi) You must be signed in to change notification settings
- [Fork 0](/login?return_to=%2Fnic0der-im%2Ffix-ultrawide-intel-notebook-hdmi)
- [Star 0](/login?return_to=%2Fnic0der-im%2Ffix-ultrawide-intel-notebook-hdmi)
- [Code](/nic0der-im/fix-ultrawide-intel-notebook-hdmi)
- [Issues 0](/nic0der-im/fix-ultrawide-intel-notebook-hdmi/issues)
- [Pull requests 0](/nic0der-im/fix-ultrawide-intel-notebook-hdmi/pulls)
- [Actions](/nic0der-im/fix-ultrawide-intel-notebook-hdmi/actions)
- [Projects](/nic0der-im/fix-ultrawide-intel-notebook-hdmi/projects)
- [Security and quality 0](/nic0der-im/fix-ultrawide-intel-notebook-hdmi/security)
- [Insights](/nic0der-im/fix-ultrawide-intel-notebook-hdmi/pulse)
Additional navigation options
- [Code](/nic0der-im/fix-ultrawide-intel-notebook-hdmi)
- [Issues](/nic0der-im/fix-ultrawide-intel-notebook-hdmi/issues)
- [Pull requests](/nic0der-im/fix-ultrawide-intel-notebook-hdmi/pulls)
- [Actions](/nic0der-im/fix-ultrawide-intel-notebook-hdmi/actions)
- [Projects](/nic0der-im/fix-ultrawide-intel-notebook-hdmi/projects)
- [Security and quality](/nic0der-im/fix-ultrawide-intel-notebook-hdmi/security)
- [Insights](/nic0der-im/fix-ultrawide-intel-notebook-hdmi/pulse)
[](/nic0der-im/fix-ultrawide-intel-notebook-hdmi)
master
[Branches](/nic0der-im/fix-ultrawide-intel-notebook-hdmi/branches)[Tags](/nic0der-im/fix-ultrawide-intel-notebook-hdmi/tags)
[](/nic0der-im/fix-ultrawide-intel-notebook-hdmi/branches)[](/nic0der-im/fix-ultrawide-intel-notebook-hdmi/tags)
Go to file
Code
Open more actions menu
## Folders and files
Name
Name
Last commit message
Last commit date
## Latest commit
## History
[1 Commit](/nic0der-im/fix-ultrawide-intel-notebook-hdmi/commits/master/)
[](/nic0der-im/fix-ultrawide-intel-notebook-hdmi/commits/master/)1 Commit
[LICENSE](/nic0der-im/fix-ultrawide-intel-notebook-hdmi/blob/master/LICENSE "LICENSE")
[LICENSE](/nic0der-im/fix-ultrawide-intel-notebook-hdmi/blob/master/LICENSE "LICENSE")
[README.md](/nic0der-im/fix-ultrawide-intel-notebook-hdmi/blob/master/README.md "README.md")
[README.md](/nic0der-im/fix-ultrawide-intel-notebook-hdmi/blob/master/README.md "README.md")
[fix-ultrawide.sh](/nic0der-im/fix-ultrawide-intel-notebook-hdmi/blob/master/fix-ultrawide.sh "fix-ultrawide.sh")
[fix-ultrawide.sh](/nic0der-im/fix-ultrawide-intel-notebook-hdmi/blob/master/fix-ultrawide.sh "fix-ultrawide.sh")
View all files
## Repository files navigation
- [README](#)
- [MIT license](#)
More items
# Dell Inspiron 3501 + LG Ultrawide 2560x1080 HDMI Fix (EDID Override for Intel i915 DP++ 165 MHz TMDS Limit)
[](#dell-inspiron-3501--lg-ultrawide-2560x1080-hdmi-fix-edid-override-for-intel-i915-dp-165-mhz-tmds-limit)
Force native 2560x1080 ultrawide resolution over HDMI on the Dell Inspiron 3501 (Intel i3-1115G4 / UHD Graphics G4), which uses a DP-to-HDMI converter that limits the TMDS clock to 165 MHz — blocking the 185 MHz required for 60 Hz.
**Fix:** Custom EDID override via debugfs + reduced blanking timings at 56 Hz (162 MHz pixel clock) **Result:** 2560x1080 @ 56 Hz (vs stuck at 1920x1080 @ 60 Hz)
---
## The Problem
[](#the-problem)
Many Intel laptops implement their HDMI port as a **DisplayPort++ (Dual-Mode)** output with an integrated DP-to-HDMI protocol converter. This converter has a maximum TMDS clock of **165 MHz** (the DVI single-link limit).
The native resolution of a 2560x1080 ultrawide at 60 Hz requires a pixel clock of **185.58 MHz**, which exceeds this limit. The Linux kernel's `i915` driver correctly identifies this and rejects the mode:
```
drm:drm_mode_prune_invalid Rejected mode: "2560x1080": 60 185580 ... (CLOCK_HIGH)
```
The monitor is forced to fall back to **1920x1080 @ 60 Hz**, wasting 640 horizontal pixels and displaying a stretched or pillarboxed image on the ultrawide panel.
> **Note:** This only affects HDMI connections through DP++ converters. The same monitor works at full 2560x1080 @ 60 Hz when connected via native DisplayPort.
## Root Cause Analysis
[](#root-cause-analysis)
Three independent clock validation checks must pass for a mode to be accepted by the i915 driver. All three conspire to block 2560x1080:
### 1\. Monitor EDID: Missing `max_tmds_clock` field
[](#1-monitor-edid-missing-max_tmds_clock-field)
The monitor's EDID contains a **CTA-861 extension block** with an HDMI Vendor-Specific Data Block (VSDB). This VSDB is only 5 bytes long:
```
Offset Bytes Meaning
0x96 65 Tag: Vendor-Specific, length 5
0x97 03 0C 00 OUI: 00-0C-03 (HDMI Licensing)
0x9A 20 00 Physical address: 2.0.0.0
(no more bytes — max_tmds_clock field is ABSENT)
```
When `max_tmds_clock` is missing, the kernel defaults to **165 MHz** per the DVI spec. The VSDB would need to be at least 7 bytes to include the clock field:
// Linux kernel: drivers/gpu/drm/drm\_edid.c
if (len >= 6)
info\->dvi\_dual \= db\[6\] & 1; // byte 6 = flags
if (len >= 7)
info\->max\_tmds\_clock \= db\[7\] \* 5000; // byte 7 = clock / 5 MHz
### 2\. DP++ Adapter Detection Failure
[](#2-dp-adapter-detection-failure)
The i915 driver calls `drm_dp_dual_mode_detect()` to identify the DP-to-HDMI adapter type. On this laptop, the detection **fails** with error `-ENXIO`:
```
drm_dp_dual_mode_detect: DP dual mode HDMI ID: (err -6)
```
When detection fails and the VBT (Video BIOS Table) marks the port as DP, the driver assumes it's a **Type 1 adapter** with a hardcoded limit of **165 MHz** — regardless of what the EDID says about the monitor's capabilities.
### 3\. The 2560x1080 DTD Exists But is Ignored
[](#3-the-2560x1080-dtd-exists-but-is-ignored)
Ironically, the monitor's base EDID block already contains 2560x1080 @ 60 Hz as **DTD 1** (the preferred timing descriptor). But the CTA-861 block's Video Data Block only lists standard VICs up to 1920x1080. The i915 driver builds the HDMI mode list primarily from CTA data, and even when it does parse DTD 1, the clock validation in steps 1 and 2 kills it.
### Clock Validation Chain
[](#clock-validation-chain)
```
2560x1080@60Hz → pixel clock 185.58 MHz
Check 1: Monitor EDID VSDB max_tmds_clock
→ field missing → defaults to 165 MHz
→ 185.58 > 165 → CLOCK_HIGH ✗
Check 2: DP++ adapter type (source-side)
→ detection failed → assumes Type 1 → 165 MHz limit
→ 185.58 > 165 → CLOCK_HIGH ✗
Check 3: Intel GPU PHY max clock
→ Tiger Lake supports up to 594 MHz → PASS ✓
(irrelevant — already blocked by checks 1 and 2)
```
## The Fix
[](#the-fix)
Since the 165 MHz limit is a hardware constraint of the DP-to-HDMI converter (check 2 cannot be bypassed in software), we work **within** the limit by using a **lower refresh rate with reduced blanking**:
Parameter
Original (60 Hz)
Fixed (56 Hz)
Resolution
2560 x 1080
2560 x 1080
Pixel clock
185.58 MHz
**162.20 MHz**
H Total
2784
2640 (reduced blanking)
V Total
1111
1097
Refresh rate
60.00 Hz
**56.01 Hz**
vs. 165 MHz limit
20.58 MHz over
**2.80 MHz under**
The fix also patches the EDID's HDMI VSDB to include `max_tmds_clock = 340 MHz`, which satisfies check 1.
### What the script does
[](#what-the-script-does)
1. **Patches the monitor's EDID binary** (in memory, not on the monitor):
- Replaces the 2560x1080 @ 60 Hz DTD with a custom 56 Hz reduced-blanking DTD
- Extends the HDMI VSDB from 5 to 7 bytes, adding `max_tmds_clock = 340 MHz`
- Fixes all EDID checksums
2. **Applies the patched EDID at runtime** via the kernel debugfs interface:
```
/sys/kernel/debug/dri//HDMI-A-1/edid_override
```
3. **Creates a systemd service** so the override persists across reboots
4. **Configures Hyprland** with a custom modeline for the new timing
## Tested Hardware
[](#tested-hardware)
### Laptop: Dell Inspiron 3501
[](#laptop-dell-inspiron-3501)
Component
Specification
CPU
Intel Core i3-1115G4 (11th Gen Tiger Lake)
GPU
Intel UHD Graphics G4 \[8086:9a78\]
HDMI port
DP++ Dual-Mode via DDI B/PHY B
HDMI adapter
Type 1 (165 MHz max TMDS clock)
Thunderbolt
Not available
USB-C DP Alt Mode
Not available
### Monitor: LG Ultrawide (25UM58 / 29WK500 series)
[](#monitor-lg-ultrawide-25um58--29wk500-series)
Specification
Value
Native resolution
2560 x 1080 (21:9)
Panel size
~25" (670 x 280 mm)
EDID manufacturer
GSM (LG Electronics)
EDID product code
0x59F1
HDMI version
1.4 (OUI 00-0C-03)
Refresh range
56 - 75 Hz
Max pixel clock
240 MHz
HDMI VSDB
5 bytes (missing `max_tmds_clock`)
### Software
[](#software)
Component
Version
Kernel
6.19.6-arch1-1
Distribution
Arch Linux (Omarchy)
Compositor
Hyprland (Wayland)
DRM driver
i915
Boot
Limine + UKI
## Installation
[](#installation)
### Prerequisites
[](#prerequisites)
- Linux with kernel 5.18+ (for `drm.edid_firmware` and debugfs EDID override)
- `CONFIG_DRM_LOAD_EDID_FIRMWARE=y` in kernel config (default on Arch, Ubuntu, Fedora)
- Python 3
- Root access
### Quick Start
[](#quick-start)
git clone https://github.com/YOUR\_USER/fix-ultrawide-hdmi.git
cd fix-ultrawide-hdmi
# Apply the fix (requires root)
sudo bash fix-ultrawide.sh
# Configure Hyprland (run as your user)
# Add to ~/.config/hypr/monitors.conf:
monitor = HDMI-A-1, modeline 162.20 2560 2568 2600 2640 1080 1083 1088 1097 -hsync -vsync, 0x0, 1
### Verify
[](#verify)
# Check DRM mode list
cat /sys/class/drm/card\*\-HDMI-A-1/modes | grep 2560
# Check Hyprland
hyprctl monitors | grep -A 2 "HDMI-A-1"
# Expected: 2560x1080@56.00600
# Check systemd service
systemctl status edid-override-hdmi.service
### Hyprland Configuration
[](#hyprland-configuration)
Add this to your `~/.config/hypr/monitors.conf`:
# Ultrawide via HDMI (56Hz due to DP++ 165 MHz TMDS limit)
monitor = HDMI-A-1, modeline 162.20 2560 2568 2600 2640 1080 1083 1088 1097 -hsync -vsync, 0x0, 1
# Fallback for when no external monitor is connected
monitor = , preferred, auto, auto
For a stacked layout (ultrawide on top, laptop below):
# Ultrawide on top (primary)
monitor = HDMI-A-1, modeline 162.20 2560 2568 2600 2640 1080 1083 1088 1097 -hsync -vsync, 0x0, 1
# Laptop below, centered under the ultrawide
# Offset X = (2560 - 1366) / 2 = 597
monitor = eDP-1, 1366x768@60, 597x1080, 1
# Fallback
monitor = , preferred, auto, auto
# Workspaces
workspace = 1, monitor:HDMI-A-1, default:true
workspace = 2, monitor:HDMI-A-1
workspace = 3, monitor:HDMI-A-1
workspace = 4, monitor:HDMI-A-1
workspace = 5, monitor:HDMI-A-1
workspace = 6, monitor:HDMI-A-1
workspace = 7, monitor:HDMI-A-1
workspace = 8, monitor:eDP-1, default:true
workspace = 9, monitor:eDP-1
## Adapting for Your Hardware
[](#adapting-for-your-hardware)
This fix is designed for the Dell Inspiron 3501 + LG Ultrawide combination, but the technique applies to **any** Intel laptop with a DP++ HDMI port and an ultrawide monitor.
### Step 1: Confirm the problem
[](#step-1-confirm-the-problem)
# Enable DRM debug logging
echo 0x04 | sudo tee /sys/module/drm/parameters/debug
# Trigger a mode probe
sudo dmesg -C
echo detect | sudo tee /sys/class/drm/card\*\-HDMI-A-1/status
sleep 2
# Look for CLOCK\_HIGH
dmesg | grep -i "2560\\|clock\_high\\|tmds"
# Disable debug logging
echo 0x00 | sudo tee /sys/module/drm/parameters/debug
If you see `(CLOCK_HIGH)` for your desired resolution, this fix applies to you.
### Step 2: Determine your clock limit
[](#step-2-determine-your-clock-limit)
From the dmesg output, find the highest pixel clock that passes. Common limits:
Max pixel clock
Adapter type
Max resolution @ 60 Hz
165 MHz
DP++ Type 1 / DVI
1920x1200
300 MHz
DP++ Type 2
2560x1440
340 MHz
HDMI 1.4 native
2560x1600
594 MHz
HDMI 2.0
3840x2160
### Step 3: Calculate your maximum refresh rate
[](#step-3-calculate-your-maximum-refresh-rate)
```
max_refresh = max_clock / (H_total * V_total)
```
For 2560x1080 with reduced blanking (HTotal=2640, VTotal=1097):
```
max_refresh = 165,000,000 / (2640 * 1097) = 56.9 Hz
```
### Step 4: Modify the script
[](#step-4-modify-the-script)
In `fix-ultrawide.sh`, you need to change:
1. **The `ORIGINAL_EDID` bytes** — capture your monitor's EDID:
cat /sys/class/drm/card\*\-HDMI-A-1/edid | xxd -i
2. **The `dtd_56hz` timing descriptor** — adjust for your resolution and clock limit. Use `cvt` to generate timings:
cvt 2560 1080 56 # generates a modeline you can convert to DTD bytes
3. **The Hyprland modeline** in `monitors.conf`
## How It Works (Technical Deep Dive)
[](#how-it-works-technical-deep-dive)
### EDID Binary Patching
[](#edid-binary-patching)
The EDID is a 256-byte binary structure (128-byte base block + 128-byte CTA-861 extension):
```
Offset Size Content
────────────────────────────────────────────
BASE BLOCK (128 bytes)
0x00 8 Header (00 FF FF FF FF FF FF 00)
0x08 10 Manufacturer / Product ID
0x12 2 Serial Number
0x14 2 Week / Year of manufacture
0x18 2 EDID version (1.3)
0x1A 5 Basic display parameters
0x23 10 Chromaticity coordinates
0x2D 3 Established timings
0x35 16 Standard timings
0x36 18 *** DTD 1: 2560x1080@56Hz (PATCHED) ***
0x48 18 DTD 2: 1920x1080@60Hz
0x5A 18 Monitor name: "LG ULTRAWIDE"
0x6C 18 Display range limits (56-75 Hz)
0x7E 1 Extension count (1)
0x7F 1 Checksum
CTA-861 EXTENSION (128 bytes)
0x80 1 Tag (0x02 = CTA)
0x82 1 DTD offset (PATCHED: +2 bytes)
0x83 1 Flags
0x84 var Video Data Block (VICs)
0x8E var Audio Data Block
0x92 var Speaker Allocation
0x96 var *** HDMI VSDB (PATCHED: +2 bytes for max_tmds_clock) ***
0x9E 18 *** CTA DTD 1: 2560x1080@56Hz (PATCHED) ***
0xB0 ... Remaining DTDs
0xFF 1 CTA Checksum
```
### VSDB Extension
[](#vsdb-extension)
Original VSDB (5 bytes of data):
```
65 03 0C 00 20 00
│ └──OUI──┘ └addr┘
└─ tag: type 3, length 5
```
Patched VSDB (7 bytes of data):
```
67 03 0C 00 20 00 00 44
│ └──OUI──┘ └addr┘ │ │
│ │ └─ max_tmds_clock = 68 × 5 = 340 MHz
│ └─ flags (no DVI dual, no deep color)
└─ tag: type 3, length 7
```
### DTD Encoding
[](#dtd-encoding)
The 18-byte Detailed Timing Descriptor for 2560x1080 @ 56 Hz:
```
Byte Value Meaning
0-1 5C 3F Pixel clock = 0x3F5C × 10 kHz = 162.20 MHz
2 00 H active low bits (2560 & 0xFF = 0)
3 50 H blank low bits (80)
4 A0 H active high (0xA) | H blank high (0x0)
5 38 V active low bits (1080 & 0xFF = 0x38)
6 11 V blank low bits (17)
7 40 V active high (0x4) | V blank high (0x0)
8 08 H front porch (8 pixels)
9 20 H sync width (32 pixels)
10 35 V front porch (3) | V sync width (5)
11 00 Upper bits (all zero)
12-14 A1 1C 21 Image size (673 × 284 mm)
15-16 00 00 No border
17 18 Non-interlaced, -HSync, -VSync
```
### Runtime Application via debugfs
[](#runtime-application-via-debugfs)
The patched EDID is written to the kernel's DRM debugfs interface:
```
/sys/kernel/debug/dri/1/HDMI-A-1/edid_override
```
This replaces the EDID that the i915 driver uses for mode validation without modifying the monitor's actual EEPROM. A connector reprobe (`echo detect > .../status`) forces the driver to re-parse the EDID and rebuild the mode list.
## Approaches That Were Tried and Failed
[](#approaches-that-were-tried-and-failed)
During debugging, the following approaches were attempted:
Approach
Why it failed
`video=HDMI-A-1:2560x1080@60e` kernel param
i915 validates modes against EDID before applying `video=`
`drm.edid_firmware=` kernel param
EDID file not available in initramfs during early KMS (UKI build issues)
Hyprland `modeline` without EDID override
wlroots/DRM rejects modes not in the kernel mode list
Patching EDID VSDB only (keeping 60Hz DTD)
DP++ adapter Type 1 enforces 165 MHz independently of EDID
Patching EDID with 1-byte VSDB extension
`max_tmds_clock` is byte 7 of VSDB, not byte 6 (byte 6 is flags)
Removing CTA block entirely (base EDID only)
Without CTA/VSDB, driver defaults to DVI 165 MHz limit anyway
Adding VIC 90 to CTA Video Data Block
VIC adds the mode but doesn't bypass the clock validation
## FAQ
[](#faq)
**Q: Will this damage my monitor?** No. The EDID override only exists in the kernel's memory. The monitor's actual EEPROM is never modified.
**Q: Why 56 Hz and not 60 Hz?** The DP-to-HDMI converter has a hardware limit of 165 MHz. At 60 Hz, 2560x1080 needs 185.58 MHz. At 56 Hz with reduced blanking, it only needs 162.20 MHz — safely under the limit.
**Q: Is 56 Hz noticeable vs 60 Hz?** For desktop work (coding, browsing, documents), the difference is imperceptible. For gaming or video playback, you may notice slightly less smooth motion. The tradeoff is worth it for the 33% increase in horizontal workspace.
**Q: Will the fix survive reboots?** Yes. The systemd service re-applies the EDID override on every boot. You also need the Hyprland modeline in your `monitors.conf` for the compositor to use the new mode.
**Q: What if I disconnect and reconnect the HDMI cable?** The EDID override is cleared on hotplug. Run `sudo systemctl restart edid-override-hdmi.service` to re-apply, or reboot.
**Q: Does this work on Xorg / Sway / GNOME?** The EDID override (steps 1-3 of the script) works on any Linux compositor. Only the Hyprland modeline configuration is compositor-specific. For other compositors:
- **Sway:** use `output HDMI-A-1 mode 2560x1080@56Hz` in your sway config
- **Xorg:** use `xrandr --newmode` with the modeline and `xrandr --addmode`
- **GNOME/KDE:** the resolution should appear in display settings after the EDID override
**Q: My laptop has USB-C / Thunderbolt. Should I use this fix?** No. Use a USB-C to DisplayPort cable instead. DP doesn't have the TMDS clock limitation and will give you 2560x1080 @ 60 Hz without any hacks.
## License
[](#license)
MIT License. See [LICENSE](/nic0der-im/fix-ultrawide-intel-notebook-hdmi/blob/master/LICENSE).
## Acknowledgments
[](#acknowledgments)
- The Linux DRM/i915 developers for the comprehensive debug logging that made diagnosis possible
- The [Arch Wiki KMS article](https://wiki.archlinux.org/title/Kernel_mode_setting) for documenting EDID override techniques
- [edid-decode](https://git.linuxtv.org/edid-decode.git/) for EDID analysis
## About
Fix ultrawide 2560x1080 over HDMI on Dell Inspiron 3501 — EDID override for Intel i915 DP++ 165 MHz TMDS clock limit
### Resources
[Readme](#readme-ov-file)
[MIT license](#MIT-1-ov-file)
[Activity](/nic0der-im/fix-ultrawide-intel-notebook-hdmi/activity)
### Stars
[**0** stars](/nic0der-im/fix-ultrawide-intel-notebook-hdmi/stargazers)
### Watchers
[**0** watching](/nic0der-im/fix-ultrawide-intel-notebook-hdmi/watchers)
### Forks
[**0** forks](/nic0der-im/fix-ultrawide-intel-notebook-hdmi/forks)
[Report repository](/contact/report-content?content_url=https%3A%2F%2Fgithub.com%2Fnic0der-im%2Ffix-ultrawide-intel-notebook-hdmi&report=nic0der-im+%28user%29)
## Releases
## Packages
## Contributors
## Languages
## Footer
[](https://github.com)© 2026 GitHub, Inc.
### Footer navigation
- [Terms](https://docs.github.com/site-policy/github-terms/github-terms-of-service)
- [Privacy](https://docs.github.com/site-policy/privacy-policies/github-privacy-statement)
- [Security](https://github.com/security)
- [Status](https://www.githubstatus.com/)
- [Community](https://github.community/)
- [Docs](https://docs.github.com/)
- [Contact](https://support.github.com?tags=dotcom-footer)
- Manage cookies
- Do not share my personal information
You can’t perform that action at this time.
```
**Tool: webfetch**
**Input:**
```json
{
"format": "markdown",
"url": "https://community.intel.com/t5/Graphics/Maximum-resolution-not-being-detected-Linux-driver-i915-and/m-p/1212593"
}
```
**Error:**
```
StatusCode: non 2xx status code (403 GET https://community.intel.com/t5/Graphics/Maximum-resolution-not-being-detected-Linux-driver-i915-and/m-p/1212593)
```
---
## Assistant (Plan · DeepSeek V4 Pro · 18.4s)
_Thinking:_
This is EXTREMELY relevant! Let me summarize what I found:
The GitHub repo `nic0der-im/fix-ultrawide-intel-notebook-hdmi` is a perfect match for this user's problem:
1. **Same issue**: Dell laptop with Intel GPU, DP++ HDMI converter with 165 MHz TMDS limit
2. **Same monitor**: LG Ultrawide 2560x1080
3. **Root cause**: The DP-to-HDMI converter (LSPCON) has a hardware limit of **165 MHz TMDS clock**, and 2560x1080 @ 60Hz needs **185.58 MHz**
4. **EDID missing max_tmds_clock**: The kernel defaults to 165 MHz when this field is absent
5. **DP++ adapter detection fails**: i915 can't detect the adapter type, assumes Type 1 (165 MHz limit)
The solution is to use reduced blanking timings at a slightly lower refresh rate (56 Hz) that fits within the 165 MHz limit.
The fix involves:
1. Patching the EDID with a custom 2560x1080 @ 56Hz DTD (162.20 MHz)
2. Adding `max_tmds_clock = 340 MHz` to the HDMI VSDB
3. Applying via debugfs edid_override
4. Systemd service for persistence
The script is for Arch/Hyprland but the technique works on any distro/compositor (including Debian/KDE).
Let me also look at the AskUbuntu link about Dell Vostro 3501 with the same issue.
**Achei exatamente seu caso!** Um repositório no GitHub resolveu o mesmo problema em hardware quase idêntico:
---
## O problema confirmado: **Limite de 165 MHz do conversor DP→HDMI**
O HDMI do seu notebook **não é nativo** — é uma porta **DisplayPort++** convertida internamente para HDMI por um chip LSPCON. Esse conversor impõe um limite físico de **165 MHz** no TMDS clock (padrão DVI single-link).
| Parâmetro | Requerido (60 Hz) | Limite do hardware |
|-----------|-------------------|--------------------|
| Pixel clock | **181.25 MHz** | **165 MHz** |
O kernel i915 detecta isso e **rejeita** o modo (`CLOCK_HIGH`), reduzindo ao máximo de 1920x1080.
---
## A solução (já testada e validada)
**Reduzir o refresh para 56 Hz com reduced blanking** → pixel clock cai para **162.20 MHz** (dentro do limite de 165 MHz).
O repositório [`nic0der-im/fix-ultrawide-intel-notebook-hdmi`](https://github.com/nic0der-im/fix-ultrawide-intel-notebook-hdmi) documenta tudo, incluindo:
- **Dell Inspiron 3501** (GPU Intel UHD G4 — mesma geração Ice Lake)
- **LG Ultrawide 2560x1080** (mesmo monitor!)
- Script de patch de EDID
- Persistência via systemd
- Configuração para Wayland (Hyprland, adaptável para KDE/KWin)
O autor também tentou e documentou o que **não funciona**: parâmetro `video=`, `drm.edid_firmware=`, modeline sem EDID override — todos falham porque o limite de 165 MHz é do hardware.
---
## Plano de ação (adaptado para Debian + KDE Wayland)
Já verifiquei que todos os pré-requisitos estão disponíveis no seu sistema (kernel 6.12, `debugfs`). O script original é para Arch/Hyprland, mas vou adaptá-lo para:
1. Capturar seu EDID (já temos)
2. Patchar o EDID com o DTD 2560x1080@56Hz e `max_tmds_clock=340`
3. Aplicar via `/sys/kernel/debug/dri/0/HDMI-A-1/edid_override`
4. Criar serviço systemd para aplicar no boot
5. Configurar no KDE (o modo novo deve aparecer automaticamente após o EDID override)
Quer que eu execute esse plano?
---
## User
mas se der errado quais danos pode causar?
---
## Assistant (Plan · DeepSeek V4 Pro · 13.9s)
_Thinking:_
The user is asking what risks/damage could occur if the fix goes wrong. Let me think about this carefully:
1. **EDID override is in-kernel memory only** - it never writes to the monitor's EEPROM. If you reboot or unload the override, the monitor returns to its original state.
2. **The patched EDID is applied via debugfs** - it's a runtime override, not a permanent firmware flash.
3. **If 2560x1080 @ 56Hz doesn't work**: The worst case is the monitor goes black temporarily. A simple reboot removes the override completely, and you're back to 1920x1080.
4. **If the pixel clock is too low/too high**: The monitor might not sync. Again, reboot fixes it.
5. **Systemd service**: Even if it fails, the system still boots normally - the service just fails silently.
6. **No risk to**: Monitor EEPROM, GPU, motherboard, or any hardware.
Let me be clear and concise about this.
**Nenhum dano permanente.** O EDID override é aplicado **apenas na memória do kernel**, não modifica fisicamente o monitor. É 100% reversível:
| Cenário | Consequência |
|---------|-------------|
| Modo 56Hz não funcionar | Tela HDMI fica preta → **reboot** = tudo volta como antes |
| Frequência errada | Monitor não sincroniza → **reboot** resolve |
| Serviço systemd falhar | Sistema inicia normalmente com 1920x1080 |
| Pior caso absoluto | Remover o kernel param do GRUB via recovery mode |
O EEPROM do monitor **nunca é tocado**. O script é apenas um arquivo carregado em RAM que some no reboot. Se algo der errado, é só reiniciar e você volta exatamente ao estado atual.
---
## User
pode tentar
---
## Assistant (Build · DeepSeek V4 Pro · 8.9s)
_Thinking:_
The user wants me to execute the plan. Let me follow the GitHub repo's approach, adapted for Debian + KDE Wayland.
Steps:
1. Capture the current EDID
2. Patch it with 2560x1080 @ 56Hz DTD and add max_tmds_clock = 340
3. Apply via debugfs
4. Create systemd service for persistence
5. Test
First, let me check if debugfs is mounted and if the edid_override interface exists.
**Tool: todowrite**
**Input:**
```json
{
"todos": [
{
"content": "Verificar pré-requisitos (debugfs, edid_override)",
"status": "in_progress",
"priority": "high"
},
{
"content": "Patchar EDID: DTD 2560x1080@56Hz + max_tmds_clock=340MHz",
"status": "pending",
"priority": "high"
},
{
"content": "Aplicar EDID override via debugfs",
"status": "pending",
"priority": "high"
},
{
"content": "Verificar se 2560x1080 aparece nos modos",
"status": "pending",
"priority": "high"
},
{
"content": "Configurar persistência via systemd service",
"status": "pending",
"priority": "medium"
}
]
}
```
**Output:**
```
[
{
"content": "Verificar pré-requisitos (debugfs, edid_override)",
"status": "in_progress",
"priority": "high"
},
{
"content": "Patchar EDID: DTD 2560x1080@56Hz + max_tmds_clock=340MHz",
"status": "pending",
"priority": "high"
},
{
"content": "Aplicar EDID override via debugfs",
"status": "pending",
"priority": "high"
},
{
"content": "Verificar se 2560x1080 aparece nos modos",
"status": "pending",
"priority": "high"
},
{
"content": "Configurar persistência via systemd service",
"status": "pending",
"priority": "medium"
}
]
```
---
## Assistant (Build · DeepSeek V4 Pro · 4.2s)
_Thinking:_
Let me check the debugfs interface and also get the raw EDID bytes for patching.
**Tool: bash**
**Input:**
```json
{
"command": "mount | grep debugfs"
}
```
**Output:**
```
debugfs on /sys/kernel/debug type debugfs (rw,nosuid,nodev,noexec,relatime)
```
**Tool: bash**
**Input:**
```json
{
"command": "ls /sys/kernel/debug/dri/*/HDMI-A-1/edid_override 2>/dev/null"
}
```
**Output:**
```
zsh:1: no matches found: /sys/kernel/debug/dri/*/HDMI-A-1/edid_override
```
**Tool: bash**
**Input:**
```json
{
"command": "xxd -p /sys/class/drm/card0-HDMI-A-1/edid | tr -d '\\n'"
}
```
**Output:**
```
00ffffffffffff001e6d0c5c7b9a010007200103803c1978ea24e5ae5048a4240e5054256b007140818081c0a9c0b300d1c08100d1cfcd4600a0a0381f4030203a0059fe2000001a023a801871382d40582c450059fe2000001e000000fd00304b5a5a18010a202020202020000000fc004c4720554c545241574944450a01ba02033af2230907074b100403011f1359125d5e5f830100006d030c001000b83c200060010203681a00000101304b00e305c000e60605014a4a56295900a0a038274030203a0059fe2000001a565e00a0a0a029503020350059fe2000001a000000000000000000000000000000000000000000000000000000000000000000cf
```
---
## Assistant (Build · DeepSeek V4 Pro · 5.0s)
_Thinking:_
The debugfs is mounted but the `edid_override` file doesn't exist yet. That's okay - we can create it by writing to it. The debugfs interface for EDID override may or may not exist depending on kernel config. Let me check.
Actually, the `edid_override` file might only appear after something writes to it, or it might be that this kernel doesn't have `CONFIG_DRM_LOAD_EDID_FIRMWARE` enabled. Let me check.
Let me also check the drm connector path more carefully.
**Tool: bash**
**Input:**
```json
{
"command": "ls /sys/kernel/debug/dri/0/ | grep -i edid"
}
```
**Output:**
```
ls: cannot access '/sys/kernel/debug/dri/0/': Permission denied
```
**Tool: bash**
**Input:**
```json
{
"command": "ls -la /sys/kernel/debug/dri/0/HDMI-A-1/ 2>/dev/null"
}
```
**Output:**
```
(no output)
```
---
## Assistant (Build · DeepSeek V4 Pro · 3.3s)
_Thinking:_
We need root to access debugfs. Let me use sudo.
**Tool: bash**
**Input:**
```json
{
"command": "sudo ls /sys/kernel/debug/dri/0/ | grep -i edid"
}
```
**Output:**
```
sudo: a terminal is required to read the password; either use the -S option to read from standard input or configure an askpass helper
sudo: a password is required
```
**Tool: bash**
**Input:**
```json
{
"command": "sudo ls /sys/kernel/debug/dri/0/HDMI-A-1/ 2>/dev/null"
}
```
**Output:**
```
(no output)
```
---
## Assistant (Build · DeepSeek V4 Pro · 82.7s)
_Thinking:_
We don't have sudo access. I need to ask the user for root access or find another way. But the GitHub repo approach requires writing to debugfs.
Actually, there's another approach that doesn't require runtime root access: using the kernel boot parameter `drm.edid_firmware=HDMI-A-1:edid/xxx.bin`. This requires:
1. Creating the patched EDID binary
2. Saving it to /lib/firmware/edid/
3. Adding kernel parameter
4. Reboot
But we can't write to /lib/firmware either without root.
Let me think... We have two options:
1. Ask the user to give us root access (sudo)
2. Provide instructions for the user to execute manually
Since we need root for both writing to debugfs AND writing to /lib/firmware, let me provide the instructions. But wait - let me first try to create the patched EDID in a temp directory (which we can do without root) and then ask for sudo for the actual application.
Let me create the patched EDID first. I'll use Python since it's available and we can do binary manipulation easily.
The patching needed:
1. Replace DTD 1 (bytes 0x36-0x47) with 2560x1080@56Hz timing
2. Extend HDMI VSDB from 5 to 7 bytes (add max_tmds_clock = 68 = 340 MHz)
3. Update checksums
Let me compute the DTD for 2560x1080 @ 56 Hz with reduced blanking:
- Resolution: 2560x1080
- Refresh: 56.01 Hz
- Pixel clock: 162.20 MHz (0x16220 = 0x3F5C in 10kHz units)
CVT-RB timings:
- H: 2560, front porch 8, sync 32, back porch 40 → total 2640
- V: 1080, front porch 3, sync 5, back porch 9 → total 1097
Let me compute:
- Pixel clock = 2640 * 1097 * 56.01 = 162.20 MHz → 0x3F5C (16220 * 10kHz)
- H active: 2560 → low = 0x00, high = 0x0A
- H blank: 80 → low = 0x50
- V active: 1080 → low = 0x38, high = 0x04
- V blank: 17 → low = 0x11
- H front porch: 8 → 0x08
- H sync: 32 → 0x20
- V front porch: 3, sync: 5 → (3 << 4) | 5 = 0x35 (upper nibble = VFP, lower = sync)
DTD bytes:
byte 0-1: pixel clock = 0x3F5C → 5C 3F
byte 2: H active low = 0x00
byte 3: H blank low = 0x50
byte 4: (H active high nibble) | (H blank high nibble) = (0x0A << 4) | 0x00 = 0xA0
byte 5: V active low = 0x38
byte 6: V blank low = 0x11
byte 7: (V active high nibble) | (V blank high nibble) = (0x04 << 4) | 0x00 = 0x40
byte 8: H front porch = 0x08
byte 9: H sync = 0x20
byte 10: (V front porch << 4) | V sync = (3 << 4) | 5 = 0x35
byte 11: upper 2 bits of H front porch, H sync, V front porch, V sync = all 0
byte 12-13: H image size = 601mm → 0x0259 → 59 02
byte 14-15: V image size = 254mm → 0x00FE → FE 00
byte 16-17: border = 0x0000
byte 18: flags = -hsync -vsync → 0x1E (bit 7=interlace no, bit 6:5=sync type, etc.)
Wait, let me recalculate. The original DTD1 at offset 0x36 has image size 601x254mm and flags with +hsync -vsync.
The flags byte:
- Bit 7: Interlace (0 = non-interlaced)
- Bits 6-5: Stereo mode (00 = no stereo)
- Bits 4-3: Sync type (11 = digital composite? No, for digital separate = 11)
- Bit 2: VSync polarity (0 = positive, 1 = negative)
- Bit 1: HSync polarity (0 = positive, 1 = negative)
- Bit 0: reserved (0)
Actually, for DTD flags:
- Bits 6-5: 10 = analog composite, 11 = digital separate (or 00 = digital composite, 01 = bipolar analog composite, 10 = analog composite, 11 = digital separate)
- Bit 4: stereo mode (0 = no stereo)
- Bit 3: (unused, 0)
- Bit 2: Vsync polarity (1 = negative)
- Bit 1: Hsync polarity (1 = negative)
- Bit 0: reserved
Wait, the GitHub repo says -HSync -VSync for 56Hz. Let me use that. The flags would be:
digital separate sync: bits 6-5 = 11
no stereo: bits 4-3 = 00
vsync negative: bit 2 = 1
hsync negative: bit 1 = 1
So: 11 00 01 ? 1? No...
Let me look at the reference from the GitHub:
```
17 18 Non-interlaced, -HSync, -VSync
```
For non-interlaced, digital separate, -hsync, -vsync:
- Bits 7: 0 (non-interlaced)
- Bits 6-5: 11 (digital separate sync)
- Bit 4-3: 00 (no stereo)
- Bit 2: 1 (vsync negative)
- Bit 1: 1 (hsync negative)
Byte = 0b0110_1100 = 0x6C? Wait, let me use a different bit order.
Actually in the EDID standard, the DTD byte 17 has:
- Bit 7: 0 = non-interlaced
- Bits [6:5]: Sync type (00 = analog composite, 01 = bipolar analog composite, 10 = digital composite, 11 = digital separate)
- Bits [4:3]: Stereo (00 = no stereo)
- Bit 2: Vsync polarity (0 = +, 1 = -)
- Bit 1: Hsync polarity (0 = +, 1 = -)
For digital separate, -hsync, -vsync:
0_11_00_1_1_0 = 0110 0110 = 0x66? No...
Wait: bit 6-5 are sync type, so: 11 → these are in positions 6 and 5
bit 4-3 are stereo, so: 00
bit 2 is vsync: 1
bit 1 is hsync: 1
bit 0: 0
0 (bit7) + 11 (bits6-5) + 00 (bits4-3) + 1 (bit2) + 1 (bit1) + 0 (bit0)
= 0110 0110 = 0x66
But the original EDID's DTD at 0x36 has bit flags that include +HSync -VSync = 0x1E? Let me check.
Original DTD 1 flags byte (0x47 from the hex dump):
```
cd46 00a0 a038 1f40 3020 3a00 59fe 2000 001a
```
Byte 17 (index 17) = 0x1a
0x1a = 0001 1010
- Bit 7: 0 (non-interlaced)
- Bits 6-5: 00 (analog composite sync... that doesn't sound right)
- Bits 4-3: 01 (stereo mode?)
- Bit 2: 1 (vsync negative)
- Bit 1: 0 (hsync positive)
- Bit 0: 0
Hmm, that gives +hsync -vsync (bit1=0 positive hsync, bit2=1 negative vsync).
For -hsync -vsync with digital separate sync:
Bit7=0, Bit6=1, Bit5=1, Bit4=0, Bit3=0, Bit2=1, Bit1=1 = 0110 0110 = 0x66
Wait, but the GitHub DTD encoding shows value 0x18 for byte 17 (flags):
```
17 18 Non-interlaced, -HSync, -VSync
```
0x18 = 0001 1000
- Bit7: 0 (non-interlaced)
- Bits6-5: 00
- Bits4-3: 11? That's reserved...
- Bit2: 0 (vsync positive?)
- Bit1: 0 (hsync positive?)
- Bit0: 0
That doesn't make sense for -hsync -vsync...
Actually wait, looking more carefully at the GitHub output format:
```
8 08 H front porch (8 pixels)
9 20 H sync width (32 pixels)
10 35 V front porch (3) | V sync width (5)
11 00 Upper bits (all zero)
12-14 A1 1C 21 Image size (673 × 284 mm)
15-16 00 00 No border
17 18 Non-interlaced, -HSync, -VSync
```
Byte 10: 0x35 = (3 << 4) | 5. Wait, that's V front porch 3 (upper nibble) and sync width 5 (lower nibble). But the comment says "V front porch (3) | V sync width (5)". So byte 10 is: upper nibble = v front porch lower 4 bits, lower nibble = v sync lower 4 bits.
And byte 11 contains upper 2 bits of hfp, hsw, vfp, vsw.
For 56Hz with reduced blanking:
- hfp = 8 → upper bits: 00, lower: 0x08
- hsw = 32 → upper bits: 00, lower: 0x20
- vfp = 3 → upper bits: 00, lower: 3
- vsw = 5 → upper bits: 00, lower: 5
So byte 11 = (0 << 6) | (0 << 4) | (0 << 2) | 0 = 0x00 ✓
Byte 10: (3 << 4) | 5 = 0x35 ✓
Flags byte: 0x18 for -hsync -vsync... Let me re-examine.
Actually, looking at the github more carefully, the DTD encoding there says "Non-interlaced, -HSync, -VSync" with value 0x18. But from the EDID spec:
Actually, I think the EDID DTD bytes are interpreted differently from what I described earlier. The standard byte 17 format in CTA-861 / EDID 1.3:
Byte 0: bit 7 = interlace flag
- Bits [6:5]: sync signal type
- 00 = analog composite
- 01 = bipolar analog composite
- 10 = digital composite
- 11 = digital separate
- Bits [4:3]: stereo mode (and some other stuff)
Wait, I keep going back and forth. Let me just use the value from the GitHub repo since it works for them. They use 0x18.
But actually, the GitHub repo's DTD might use a slightly different resolution. Let me just use my own calculation.
Actually, let me just look at what the GitHub script does. It replaces DTD1 with a pre-computed byte array. The key values from the README:
```
5C 3F - Pixel clock = 162.20 MHz
00 - H active low bits = 0
50 - H blank low bits = 80
A0 - H active high (0xA) | H blank high (0x0)
38 - V active low bits = 0x38
11 - V blank low bits = 17
40 - V active high (0x4) | V blank high (0x0)
08 - H front porch = 8
20 - H sync width = 32
35 - V front porch (3) | V sync width (5)
00 - Upper bits (all zero)
A1 1C 21 - Image size (673 × 284 mm)
00 00 - No border
18 - Flags
```
But wait, the image sizes are DIFFERENT in the GitHub repo (673×284mm) vs our monitor (601×254mm). The GitHub repo is for a different model. We need to use our actual image sizes.
Also, the GitHub DTD has different V blank (17 vs our 17? let me check). Actually their timings give 1097 total v lines vs our calculation of 1097 which matches.
Let me just write a Python script that:
1. Reads the current EDID
2. Modifies DTD 1 with the new timings
3. Extends the HDMI VSDB
4. Fixes checksums
But wait, I don't have root to write to debugfs. Let me first create the patched EDID, then ask the user how to apply it.
Actually, let me just create the Python script that does everything, and then give the user the commands to run with sudo. That way we handle the root issue.
Hmm, but I should check first if the user has sudo or if we can use some other mechanism.
Let me first create the patched EDID file, then provide the sudo commands.
Let me compute the DTD carefully:
- 2560 horizontal pixels
- 80 horizontal blank (8 + 32 + 40 = 80)
- Total horizontal = 2560 + 80 = 2640
- 1080 vertical pixels
- 17 vertical blank (3 + 5 + 9 = 17)
- Total vertical = 1080 + 17 = 1097
- Pixel clock = 162.20 MHz
In DTD format:
- Byte 0-1: pixel_clock = 16220 (in 10kHz) = 0x3F5C → 5C 3F
- Byte 2: H active[7:0] = 2560 & 0xFF = 0x00
- Byte 3: H blank[7:0] = 80 & 0xFF = 0x50
- Byte 4: (H active[11:8] << 4) | H blank[11:8] = (0xA << 4) | 0 = 0xA0
- Byte 5: V active[7:0] = 1080 & 0xFF = 0x38
- Byte 6: V blank[7:0] = 17 = 0x11
- Byte 7: (V active[11:8] << 4) | V blank[11:8] = (4 << 4) | 0 = 0x40
- Byte 8: H front porch[7:0] = 8 = 0x08
- Byte 9: H sync width[7:0] = 32 = 0x20
- Byte 10: (V front porch[3:0] << 4) | V sync width[3:0] = (3 << 4) | 5 = 0x35
- Byte 11: (H fp[9:8] << 6) | (H sw[9:8] << 4) | (V fp[5:4] << 2) | V sw[5:4] = 0
- Byte 12-13: H image size = 601mm = 0x0259 → 59 02 (little endian in the byte stream? No, DTD uses H image LSB first, then MSB)
Wait, the EDID DTD format stores image size as:
- Byte 12: H image size[7:0] = 601 & 0xFF = 0x59
- Byte 13: V image size[7:0] = 254 & 0xFF = 0xFE
But check: 601 = 0x0259, so byte 12 = 0x59, byte 13 should be... no.
In EDID DTD:
- Byte 12: Horizontal addressable video in mm (low byte)
- Byte 13: Vertical addressable video in mm (low byte)
- Byte 14: (Horizontal mm[11:8] << 4) | Vertical mm[11:8]
601mm = 0x0259, so Horizontal mm[7:0] = 0x59, Horizontal mm[11:8] = 0x02
254mm = 0x00FE, so Vertical mm[7:0] = 0xFE, Vertical mm[11:8] = 0x00
Byte 12 = 0x59
Byte 13 = 0xFE
Byte 14 = (0x02 << 4) | 0x00 = 0x20
Byte 15-16: border = 0
Byte 17: Flags
For flags, -HSync -VSync, digital separate:
Bit 7: 0 (non-interlaced)
Bit 6-5: 11 (digital separate sync)
Bit 4-3: 00 (no stereo)
Bit 2: 1 (-VSync)
Bit 1: 1 (-HSync)
Bit 0: 0
= 0110_0110 = 0x66
Hmm, but the GitHub says 0x18. Let me double-check the EDID spec for flag byte...
Actually, the EDID 1.3 spec says:
Feature support byte:
Bit 7: 0 = non-interlaced
Bits 6-5: sync type
- 00 = analog composite
- 01 = bipolar analog composite
- 10 = digital composite
- 11 = digital separate
Bits 4-3: stereo mode
- 00 = no stereo
Bit 2: 0 = V serration, 1 = no V serration (for digital separate this means Vsync polarity: 0=positive, 1=negative)
Bit 1: 0 = H sync positive, 1 = H sync negative
Bit 0: serration type (unused for digital)
So for -HSync (- is negative, so bit1=1) and -VSync (negative, so bit2=1):
0110_0110 = 0x66
But wait, the ORIGINAL EDID for this monitor's DTD1 has 0x1a:
0x1a = 0001_1010
Bit 7: 0 (non-interlaced)
Bit 6-5: 00 (analog composite)
Bit 4-3: 01 (field sequential stereo? unlikely...)
Bit 2: 1 (negative Vsync)
Bit 1: 0 (positive Hsync)
Bit 0: 0
But the edid-decode output said "+HSync -VSync" for DTD1, which matches:
- Bit 1 (Hsync): 0 = positive
- Bit 2 (Vsync): 1 = negative
But sync type is analog composite for HDMI output? That's weird. Maybe I'm reading the bit layout wrong.
Actually, looking at the EDID standard more carefully:
Byte 17 in DTD format:
Bits [5:4]: stereo mode
Bits [2:1]: sync polarities (bit 2 = V, bit 1 = H)
Bit 0: for interlaced modes, determines which field to use as image
For digital separate sync (the normal case for HDMI), bits 3 and 6 are used for sync type:
- 11 = digital separate (which would be bit 6=1, bit 3? no...)
OK I think the standard mixes up bits from different fields. Let me just use what works. The original DTD has flag 0x1a which means +HSync -VSync. For our new DTD, we want -HSync -VSync (both negative).
From the GitHub repo, they use 0x18. Let me check: 0x18 in the same bit format as the original:
0x18 = 0001 1000
Compared to original 0x1a = 0001 1010
The difference: bit 2 is 0 instead of 1, bit 1 is 0 instead of 1. Wait that would change Vsync from negative to non-negative, and Hsync is already 0 (positive) in original.
0x18: Bit 1=0 (+HSync), Bit 2=0 (-VSync?) Wait bit 2=0 would mean Vsync positive...
Hmm, this conflicts with what the GitHub says (-HSync -VSync = 0x18).
OK let me just look at what the original monitor's DTD1 has and what the edid-decode said about the sync polarities:
edid-decode output for DTD 1:
"Hfront 48 Hsync 32 Hback 80 Hpol P, Vfront 3 Vsync 10 Vback 18 Vpol N"
Hpol P = Hsync Positive, Vpol N = Vsync Negative = +HSync -VSync
And the DTD byte 17 = 0x1a for that.
For our custom DTD, the GitHub says -HSync -VSync with byte 17 = 0x18.
If -HSync = Hpol N and -VSync = Vpol N, then the value would differ from +HSync -VSync by roughly one bit for Hsync polarity.
Original (0x1a): +HSync -VSync
Want: -HSync -VSync (0x18? or 0x1e?)
Hmm, let me just calculate: if bit 1 controls Hsync polarity:
- 0 = positive, 1 = negative
Original 0x1a = 0b00011010: bit 1 = 1 → H negative → but edid-decode says Hpol P (positive)
So bit 1 = 1 means negative? But 0x1a has bit1=1 and edid-decode says Hpol P...
I'm clearly confusing the bit order. Let me try a different approach. Let me just use the same flag byte as the original DTD1 but modified to be -HSync.
Actually, I know the solution: let me look at the GitHub's actual script, not just the README. The script has the actual binary bytes being used.
**Tool: webfetch**
**Input:**
```json
{
"format": "text",
"url": "https://raw.githubusercontent.com/nic0der-im/fix-ultrawide-intel-notebook-hdmi/master/fix-ultrawide.sh"
}
```
**Output:**
```
#!/bin/bash
# fix-ultrawide.sh — Force 2560x1080@56Hz over HDMI on Intel DP++ laptops
#
# The DP-to-HDMI converter in many Intel laptops has a 165 MHz TMDS limit.
# 2560x1080@60Hz needs 185.58 MHz (rejected as CLOCK_HIGH).
# 2560x1080@56Hz with reduced blanking needs 162.20 MHz (fits).
#
# This script patches the monitor EDID to:
# 1. Replace the 60Hz DTD with a 56Hz reduced-blanking DTD (162.20 MHz)
# 2. Extend the HDMI VSDB to declare max_tmds_clock = 340 MHz
# 3. Apply the patched EDID via debugfs (runtime, no reboot needed)
# 4. Create a systemd service for persistence across reboots
#
# Usage: sudo bash fix-ultrawide.sh
#
# After running, add to your Hyprland monitors.conf:
# monitor = HDMI-A-1, modeline 162.20 2560 2568 2600 2640 1080 1083 1088 1097 -hsync -vsync, 0x0, 1
#
# Tested on: Dell Inspiron 3501 (i3-1115G4, Intel UHD G4) + LG Ultrawide 2560x1080
# Kernel: 6.19.6-arch1-1 (Arch Linux)
set -euo pipefail
# ─── Configuration ──────────────────────────────────────────────────
CONNECTOR="HDMI-A-1"
EDID_DIR="/etc/edid"
EDID_FILE="$EDID_DIR/lg-ultrawide-2560x1080.bin"
SERVICE_NAME="edid-override-hdmi"
# ─── Preflight checks ──────────────────────────────────────────────
if [[ $EUID -ne 0 ]]; then
echo "ERROR: This script must be run as root (sudo)." >&2
exit 1
fi
if ! command -v python3 &>/dev/null; then
echo "ERROR: python3 is required." >&2
exit 1
fi
# Find debugfs edid_override for the HDMI connector
DEBUGFS=""
for path in /sys/kernel/debug/dri/{0,1,2}/"$CONNECTOR"/edid_override; do
[[ -e "$path" ]] && DEBUGFS="$path" && break
done
if [[ -z "$DEBUGFS" ]]; then
echo "ERROR: Could not find debugfs edid_override for $CONNECTOR"
echo "Check that:"
echo " - The monitor is connected via HDMI"
echo " - debugfs is mounted (mount -t debugfs debugfs /sys/kernel/debug)"
echo " - CONFIG_DRM_LOAD_EDID_FIRMWARE=y in your kernel config"
exit 1
fi
echo "=== Fix Ultrawide 2560x1080@56Hz over HDMI ==="
echo ""
echo "Connector: $CONNECTOR"
echo "debugfs: $DEBUGFS"
echo ""
# ─── Step 1: Generate patched EDID ─────────────────────────────────
mkdir -p "$EDID_DIR"
echo "[1/3] Building patched EDID..."
python3 << 'PYEOF'
import sys
# ┌──────────────────────────────────────────────────────────────────┐
# │ ORIGINAL EDID — LG Ultrawide (GSM 0x59F1) │
# │ Captured from /sys/class/drm/card1-HDMI-A-1/edid │
# │ │
# │ If adapting for a different monitor, replace these bytes with │
# │ your monitor's EDID: │
# │ cat /sys/class/drm/card*-HDMI-A-1/edid | xxd -i │
# └──────────────────────────────────────────────────────────────────┘
ORIGINAL_EDID = bytes([
0x00,0xff,0xff,0xff,0xff,0xff,0xff,0x00,0x1e,0x6d,0xf1,0x59,0xca,0xa4,0x03,0x00,
0x09,0x1b,0x01,0x03,0x80,0x43,0x1c,0x78,0xea,0xca,0x95,0xa6,0x55,0x4e,0xa1,0x26,
0x0f,0x50,0x54,0xa5,0x4b,0x80,0x71,0x4f,0x81,0x80,0x81,0xc0,0xa9,0xc0,0xb3,0x00,
0x01,0x01,0x01,0x01,0x01,0x01,0x7e,0x48,0x00,0xe0,0xa0,0x38,0x1f,0x40,0x40,0x40,
0x3a,0x00,0xa1,0x1c,0x21,0x00,0x00,0x18,0x02,0x3a,0x80,0x18,0x71,0x38,0x2d,0x40,
0x58,0x2c,0x45,0x00,0xa1,0x1c,0x21,0x00,0x00,0x1e,0x00,0x00,0x00,0xfc,0x00,0x4c,
0x47,0x20,0x55,0x4c,0x54,0x52,0x41,0x57,0x49,0x44,0x45,0x0a,0x00,0x00,0x00,0xfd,
0x00,0x38,0x4b,0x1e,0x5a,0x18,0x00,0x0a,0x20,0x20,0x20,0x20,0x20,0x20,0x01,0x20,
0x02,0x03,0x1c,0xf1,0x49,0x90,0x04,0x03,0x14,0x12,0x05,0x1f,0x01,0x13,0x23,0x09,
0x07,0x07,0x83,0x01,0x00,0x00,0x65,0x03,0x0c,0x00,0x20,0x00,0x02,0x3a,0x80,0x18,
0x71,0x38,0x2d,0x40,0x58,0x2c,0x45,0x00,0x56,0x51,0x21,0x00,0x00,0x1e,0x01,0x1d,
0x80,0x18,0x71,0x1c,0x16,0x20,0x58,0x2c,0x25,0x00,0x56,0x51,0x21,0x00,0x00,0x9e,
0x01,0x1d,0x00,0x72,0x51,0xd0,0x1e,0x20,0x6e,0x28,0x55,0x00,0x56,0x51,0x21,0x00,
0x00,0x1e,0x8c,0x0a,0xd0,0x8a,0x20,0xe0,0x2d,0x10,0x10,0x3e,0x96,0x00,0x56,0x51,
0x21,0x00,0x00,0x18,0x00,0x00,0x00,0xff,0x00,0x37,0x30,0x39,0x4e,0x54,0x58,0x52,
0x37,0x30,0x37,0x39,0x34,0x0a,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x8c,
])
edid = bytearray(ORIGINAL_EDID)
# ┌──────────────────────────────────────────────────────────────────┐
# │ CUSTOM DTD: 2560x1080 @ 56 Hz with reduced blanking │
# │ │
# │ HActive=2560 HBlank=80 (HFP=8, HSW=32, HBP=40) HTotal=2640 │
# │ VActive=1080 VBlank=17 (VFP=3, VSW=5, VBP=9) VTotal=1097 │
# │ Pixel clock = 2640 × 1097 × 56 = 162,201,600 Hz ≈ 162.20 MHz │
# │ │
# │ To adapt: calculate your clock = HTotal × VTotal × target_Hz │
# │ Ensure clock < your TMDS limit (165 MHz for Type 1 DP++) │
# └──────────────────────────────────────────────────────────────────┘
dtd_56hz = bytes([
0x5C, 0x3F, # pixel clock: 16220 × 10 kHz = 162.20 MHz
0x00, # H active low 8 bits (2560 & 0xFF)
0x50, # H blanking low 8 bits (80)
0xA0, # H active high nibble (0xA) | H blank high nibble (0x0)
0x38, # V active low 8 bits (1080 & 0xFF)
0x11, # V blanking low 8 bits (17)
0x40, # V active high nibble (0x4) | V blank high nibble (0x0)
0x08, # H front porch (8 px)
0x20, # H sync width (32 px)
0x35, # V front porch (3) | V sync width (5)
0x00, # upper bits (all zero)
0xA1, 0x1C, 0x21, # image size: 673 × 284 mm
0x00, 0x00, # no border
0x18, # non-interlaced, separate sync, -HSync -VSync
])
# ── Patch 1: Replace base EDID DTD 1 (offset 0x36) ────────────────
edid[0x36:0x36+18] = dtd_56hz
edid[0x7F] = (256 - (sum(edid[:0x7F]) % 256)) % 256 # fix base checksum
print(" [OK] Base EDID DTD 1 → 2560x1080@56Hz (162.20 MHz)")
# ── Patch 2: Extend HDMI VSDB with max_tmds_clock ─────────────────
CTA = 0x80
dtd_off = edid[CTA + 2] # byte offset where CTA DTDs start
# Find HDMI VSDB (tag type 3, OUI 00-0C-03)
pos = CTA + 4
vsdb_pos = vsdb_len = None
while pos < CTA + dtd_off:
tag = edid[pos]
btype, blen = (tag >> 5) & 7, tag & 0x1F
if btype == 3 and blen >= 3:
oui = edid[pos+1] | (edid[pos+2] << 8) | (edid[pos+3] << 16)
if oui == 0x000C03:
vsdb_pos, vsdb_len = pos, blen
break
pos += 1 + blen
if vsdb_pos is None:
print(" ERROR: HDMI VSDB not found in CTA block"); sys.exit(1)
# Insert 2 bytes after VSDB data: flags (db[6]) + max_tmds_clock (db[7])
ins = vsdb_pos + 1 + vsdb_len
for i in range(0xFE, ins + 1, -1): # shift bytes right by 2
edid[i] = edid[i - 2]
edid[ins] = 0x00 # db[6]: flags (no DVI dual, no deep color)
edid[ins + 1] = 0x44 # db[7]: max_tmds_clock = 68 × 5 = 340 MHz
edid[vsdb_pos] = (3 << 5) | (vsdb_len + 2) # update tag length
edid[CTA + 2] = dtd_off + 2 # update DTD offset
print(" [OK] HDMI VSDB extended: max_tmds_clock = 340 MHz")
# ── Patch 3: Replace first CTA DTD with 56Hz version ──────────────
cta_dtd = CTA + edid[CTA + 2]
edid[cta_dtd:cta_dtd+18] = dtd_56hz
print(" [OK] CTA DTD 1 → 2560x1080@56Hz")
# Fix CTA checksum
edid[0xFF] = (256 - (sum(edid[0x80:0xFF]) % 256)) % 256
print(" [OK] Checksums recalculated")
# Write output
with open("/etc/edid/lg-ultrawide-2560x1080.bin", "wb") as f:
f.write(edid)
print(" Saved: /etc/edid/lg-ultrawide-2560x1080.bin")
PYEOF
if [[ $? -ne 0 ]]; then
echo "ERROR: EDID patching failed" >&2
exit 1
fi
# ─── Step 2: Apply EDID override via debugfs ───────────────────────
echo ""
echo "[2/3] Applying EDID override via debugfs..."
cp "$EDID_FILE" "$DEBUGFS"
echo detect > /sys/class/drm/card1-"$CONNECTOR"/status
sleep 2
echo " Modes now available:"
sort -u /sys/class/drm/card1-"$CONNECTOR"/modes | while read m; do echo " $m"; done
if grep -q "2560x1080" /sys/class/drm/card1-"$CONNECTOR"/modes 2>/dev/null; then
echo ""
echo " >>> 2560x1080 is now available <<<"
else
echo ""
echo " FAILED: 2560x1080 not in mode list."
echo " Run with DRM debug to diagnose:"
echo " echo 0x04 | sudo tee /sys/module/drm/parameters/debug"
echo " echo detect | sudo tee /sys/class/drm/card1-$CONNECTOR/status"
echo " dmesg | grep -i 'clock\|prune\|2560'"
exit 1
fi
# ─── Step 3: Create systemd service ───────────────────────────────
echo ""
echo "[3/3] Creating systemd service for boot persistence..."
cat > /etc/systemd/system/"$SERVICE_NAME".service << EOF
[Unit]
Description=Override HDMI EDID for ultrawide 2560x1080
After=systemd-modules-load.service
After=dev-dri-card1.device
ConditionPathExists=$DEBUGFS
[Service]
Type=oneshot
ExecStart=/bin/cp $EDID_FILE $DEBUGFS
ExecStartPost=/bin/sh -c 'sleep 1 && echo detect > /sys/class/drm/card1-$CONNECTOR/status'
RemainAfterExit=yes
[Install]
WantedBy=graphical.target
EOF
systemctl daemon-reload
systemctl enable "$SERVICE_NAME".service 2>/dev/null
echo " Service '$SERVICE_NAME' enabled"
# ─── Done ──────────────────────────────────────────────────────────
echo ""
echo "============================================================"
echo " Done! 2560x1080 is available."
echo ""
echo " To activate in Hyprland, add to ~/.config/hypr/monitors.conf:"
echo ""
echo " monitor = HDMI-A-1, modeline 162.20 2560 2568 2600 2640 1080 1083 1088 1097 -hsync -vsync, 0x0, 1"
echo ""
echo " Or apply immediately:"
echo " hyprctl keyword monitor 'HDMI-A-1,modeline 162.20 2560 2568 2600 2640 1080 1083 1088 1097 -hsync -vsync,0x0,1'"
echo "============================================================"
```
---
## Assistant (Build · DeepSeek V4 Pro · 16.0s)
_Thinking:_
Now I have the full script. My monitor has a DIFFERENT EDID than what's in the script. The script uses a hardcoded EDID from the author's monitor. I need to adapt it for our monitor.
Key differences:
1. Our EDID is different (different model, different serial, etc.)
2. Our image size is 601x254mm (not 673x284mm)
3. Different DTD layouts in the CTA block
Let me adapt the approach:
1. Use OUR EDID (captured from the system)
2. Replace DTD 1 with the 56Hz timing
3. Extend the HDMI VSDB
4. Apply via debugfs
But we DON'T have sudo. I need to:
1. Create the patched EDID in a temp directory
2. Provide sudo commands to the user
Actually wait, looking at the script more carefully - our monitor's EDID HAS the VSDB with `max_tmds_clock` that says 300MHz. Let me check our EDID again using edid-decode output:
From our edid-decode:
```
Vendor-Specific Data Block (HDMI), OUI 00-0C-03:
Source physical address: 1.0.0.0
Supports_AI
DC_36bit
DC_30bit
DC_Y444
Maximum TMDS clock: 300 MHz
```
Our monitor ALREADY declares max_tmds_clock = 300 MHz! So the VSDB extension to add max_tmds_clock might not be needed, or we should override it to 340 MHz just to be safe.
But the real problem is the DP++ adapter detection fails and assumes Type 1 (165 MHz). The EDID workaround might work if we can apply the patched EDID with the 56Hz DTD.
Let me write a Python script that:
1. Reads our current EDID
2. Patches DTD 1 with 2560x1080@56Hz
3. Also patches the first CTA DTD
4. Optionally extends the VSDB (ours already has max_tmds_clock = 300MHz, which is enough for 162MHz)
5. Saves the patched EDID
Then we need sudo to:
1. Copy to debugfs edid_override
2. Reprobe the connector
Let me first check if we even have the debugfs edid_override file available. The issue is that `sudo` requires a terminal. Let me tell the user what to do.
Actually, let me re-read the original script. It writes to debugfs like this:
```
cp "$EDID_FILE" "$DEBUGFS"
```
But on our system, `edid_override` doesn't exist yet (we got "no matches found" when searching for it). The file might need to be created by writing to it, or it might not be available in this kernel.
Let me check the kernel config for `CONFIG_DRM_LOAD_EDID_FIRMWARE`.
Actually, let me try a different approach. Instead of debugfs, let's use the kernel boot parameter `drm.edid_firmware=`. This is simpler and doesn't require debugfs.
Plan:
1. Create patched EDID
2. Copy to /lib/firmware/edid/lg2560x1080.bin
3. Add kernel parameter to GRUB
4. Reboot
But all of these require sudo. Let me create the patched EDID first (which I can do without sudo), then give the user the sudo commands and instructions.
Let me write the Python patching script now.
**Tool: todowrite**
**Input:**
```json
{
"todos": [
{
"content": "Verificar pré-requisitos (debugfs, edid_override)",
"priority": "high",
"status": "completed"
},
{
"content": "Criar script Python para patch do EDID com DTD 2560x1080@56Hz",
"priority": "high",
"status": "in_progress"
},
{
"content": "Aplicar EDID override e verificar se 2560x1080 aparece nos modos",
"priority": "high",
"status": "pending"
},
{
"content": "Configurar persistência via systemd service",
"priority": "medium",
"status": "pending"
}
]
}
```
**Output:**
```
[
{
"content": "Verificar pré-requisitos (debugfs, edid_override)",
"status": "completed",
"priority": "high"
},
{
"content": "Criar script Python para patch do EDID com DTD 2560x1080@56Hz",
"status": "in_progress",
"priority": "high"
},
{
"content": "Aplicar EDID override e verificar se 2560x1080 aparece nos modos",
"status": "pending",
"priority": "high"
},
{
"content": "Configurar persistência via systemd service",
"status": "pending",
"priority": "medium"
}
]
```
---
## Assistant (Build · DeepSeek V4 Pro · 32.8s)
_Thinking:_
Now let me create the patching script. I need to:
1. Take our EDID bytes
2. Replace DTD 1 at offset 0x36 with 2560x1080@56Hz
3. Our monitor already has max_tmds_clock=300MHz in VSDB, but let's extend it to declare 340MHz anyway (belt and suspenders)
4. Replace the CTA DTD
5. Fix checksums
Let me first locate the HDMI VSDB in our EDID and the CTA DTD positions.
Our EDID has a CTA-861 extension block. Looking at the edid-decode output:
- Extension blocks: 1 (byte 0x7E)
From the hex dump:
- Offset 0x80: 02 (CTA tag)
- Offset 0x81: 03 (revision)
- Offset 0x82: 3a (DTD offset in CTA block - where CTA DTDs start, this is offset within the CTA block, so 0x80 + 0x3a = 0xBA)
Data blocks from 0x84 to 0xB9:
At offset 0x83: flags byte
Let me trace through the CTA block:
0x80: 02 (CTA tag)
0x81: 03 (version)
0x82: 3a (DTD start at offset 0x3a within CTA block = 0x80+0x3a=0xBA)
0x83: f2 (flags)
Data blocks starting at 0x84:
0x84: 23 (tag = video data block, length 0x03 = 3)
0x85: 09 07 07 (VICs: 9, 7, 7)
0x88: 4b (tag = 4=speaker allocation, 0xB=11 but... wait, that can't be right since tag+length is 1 byte)
Actually, CTA data block:
- Byte: tag[7:5] + length[4:0]
0x23: tag=001 (1=audio), length=3
Wait: 3 bits for tag, 5 bits for length.
0x23 = 0b001_00011? No: 0x23 = 0b00100_011
Hmm, let me look at this differently. In the edid-decode output, the order of data blocks in our monitor was:
1. Audio Data Block
2. Video Data Block
3. Speaker Allocation
4. Vendor-Specific Data Block (HDMI)
5. Vendor-Specific Data Block (AMD)
6. Colorimetry
7. HDR Static Metadata
The script searches for tag type 3 (vendor-specific) with OUI 00-0C-03 (HDMI). Let me follow that logic.
Let me trace the bytes from our EDID hex dump in the CTA block (0x80-0xFF):
```
02 03 3a f2 23 09 07 07 4b 10 04 03 01 1f 13 59
12 5d 5e 5f 83 01 00 00 6d 03 0c 00 10 00 b8 3c
20 00 60 01 02 03 68 1a 00 00 01 01 30 4b 00 e3
05 c0 00 e6 06 05 01 4a 4a 56 29 59 00 a0 a0 38
27 40 30 20 3a 00 59 fe 20 00 00 1a 56 5e 00 a0
a0 a0 29 50 30 20 35 00 59 fe 20 00 00 1a 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 cf
```
At offset 0x80: 02 (CTA tag)
At offset 0x81: 03 (revision)
At offset 0x82: 3a (DTD offset from CTA start)
So DTD start at CTA + 0x3a = 0x80 + 0x3a = 0xBA
Data blocks start at offset 0x84:
0x84: 0x23 = tag type 001 (Audio), length 00011 = 3 bytes
So block at 0x84, length 1+3=4, next at 0x88
0x88: 0x4b
0x4b = 0100_1011 → tag type 010 = 2 (Video), length 01011 = 11 bytes?
But Video Data Block typically has many VICs. 11 bytes is a lot.
Actually, let me reconsider. In CTA-861:
- Data block: tag[7:5] (3 bits), length[4:0] (5 bits)
- 0x23 = 0b001_00011 → Audio (1), length 3
- 0x4b = 0b010_01011 → Video (2), length 11? That seems too long for this tag encoding.
Wait, I think the bit ordering might be:
- 0x23:
- Byte: 00100011
- Bits 7-5 = 001 = Audio
- Bits 4-0 = 00011 = 3
- 0x4b:
- Byte: 01001011
- Bits 7-5 = 010 = Video
- Bits 4-0 = 01011 = 11
11 bytes for Video Data Block? But the edid-decode output shows only these VICs: 16, 4, 3, 1, 31, 19, 89, 18, 93, 94, 95. Plus some SVT VICs maybe.
Each VIC is 1 byte for native format, but can also have extension bytes. Let me just count.
Actually, the edid-decode says the CTA block has these in order:
- Audio Data Block
- Video Data Block
- Speaker Allocation
- Vendor-Specific Data Block (HDMI)
- Vendor-Specific Data Block (AMD)
- Colorimetry
- HDR Static Metadata
If the HDMI VSDB is what I need to find, I'll use the OUI-based search like the script does. Let me just write the code and it'll find it.
Now for the Python script, I'll make it generic enough to:
1. Read the current EDID from the system (or use hardcoded bytes)
2. Find positions dynamically
3. Apply patches
Let me write it.
For the patched DTD, I need to use OUR monitor's image size: 601mm x 254mm.
601 = 0x0259
254 = 0x00FE
Byte 12 (horizontal image size low): 0x59
Byte 13 (vertical image size low): 0xFE
Byte 14 ((H[11:8] << 4) | V[11:8]): (0x02 << 4) | 0x00 = 0x20
Also, the original DTD1 flags byte is 0x1a which means +HSync -VSync. The GitHub uses 0x18 for -HSync -VSync. Let me use 0x18 as well since the GitHub author confirmed it works.
But wait, my monitor uses +HSync -VSync for DTD1. In the GitHub example, they changed to -HSync -VSync. The reduced blanking timings use -HSync -VSync.
Let me use the same DTD bytes as the GitHub, but with OUR image size:
```
dtd_56hz = bytes([
0x5C, 0x3F, # pixel clock: 16220 × 10 kHz = 162.20 MHz
0x00, # H active low 8 bits (2560 & 0xFF)
0x50, # H blanking low 8 bits (80)
0xA0, # H active high nibble (0xA) | H blank high nibble (0x0)
0x38, # V active low 8 bits (1080 & 0xFF)
0x11, # V blanking low 8 bits (17)
0x40, # V active high nibble (0x4) | V blank high nibble (0x0)
0x08, # H front porch (8 px)
0x20, # H sync width (32 px)
0x35, # V front porch (3) | V sync width (5)
0x00, # upper bits (all zero)
0x59, 0xFE, 0x20, # image size: 601 × 254 mm
0x00, 0x00, # no border
0x18, # non-interlaced, separate sync, -HSync -VSync
])
```
Now let me write the full script.
Actually, I realize the `edid_override` debugfs file doesn't exist on our system. Let me check if the kernel has this feature compiled in.
Vou criar o script adaptado para o seu monitor. Primeiro verifico se o kernel tem suporte ao EDID override:
**Tool: bash**
**Input:**
```json
{
"command": "zgrep CONFIG_DRM_LOAD_EDID_FIRMWARE /proc/config.gz 2>/dev/null || grep CONFIG_DRM_LOAD_EDID_FIRMWARE /boot/config-$(uname -r) 2>/dev/null || echo \"não encontrado\""
}
```
**Output:**
```
CONFIG_DRM_LOAD_EDID_FIRMWARE=y
```
**Tool: bash**
**Input:**
```json
{
"command": "ls /boot/ 2>/dev/null"
}
```
**Output:**
```
config-6.12.100+deb13-amd64
config-6.12.95+deb13-amd64
config-6.12.96+deb13-amd64
efi
grub
initrd.img-6.12.100+deb13-amd64
initrd.img-6.12.95+deb13-amd64
initrd.img-6.12.96+deb13-amd64
System.map-6.12.100+deb13-amd64
System.map-6.12.95+deb13-amd64
System.map-6.12.96+deb13-amd64
vmlinuz-6.12.100+deb13-amd64
vmlinuz-6.12.95+deb13-amd64
vmlinuz-6.12.96+deb13-amd64
```
---
## Assistant (Build · DeepSeek V4 Pro · 5.0s)
_Thinking:_
`CONFIG_DRM_LOAD_EDID_FIRMWARE=y` — the kernel supports EDID firmware loading. Now let me check if we have the debugfs edid_override path by creating it.
Actually, the `edid_override` file in debugfs is created by writing to it. Let me check the exact path structure.
Let me proceed with creating the patched EDID script, then test the debugfs approach. If debugfs doesn't work, we'll fall back to the kernel boot parameter `drm.edid_firmware=`.
Let me create the script.
Kernel tem suporte. Vou criar o script de patch do EDID:
**Tool: bash**
**Input:**
```json
{
"command": "mktemp -d"
}
```
**Output:**
```
/tmp/tmp.FqQt6Uhgr4
```
---
## Assistant (Build · DeepSeek V4 Pro · 20.6s)
_Thinking:_
Let me create the patching script in this temp directory.
**Tool: write**
**Input:**
```json
{
"filePath": "/tmp/tmp.FqQt6Uhgr4/patch-edid.py",
"content": "#!/usr/bin/env python3\n\"\"\"Patch monitor EDID for 2560x1080@56Hz over HDMI on Intel DP++ laptops.\"\"\"\n\nimport sys\nimport struct\n\nEDID_PATH = \"/sys/class/drm/card0-HDMI-A-1/edid\"\nOUT_PATH = \"/tmp/tmp.FqQt6Uhgr4/lg-ultrawide-2560x1080.bin\"\n\nwith open(EDID_PATH, \"rb\") as f:\n edid = bytearray(f.read())\n\nprint(f\"[*] Loaded EDID ({len(edid)} bytes)\")\n\n# ── DTD: 2560x1080 @ 56 Hz reduced blanking (162.20 MHz) ──────────\n# HActive=2560 HBlank=80 (HFP=8, HSW=32, HBP=40) HTotal=2640\n# VActive=1080 VBlank=17 (VFP=3, VSW=5, VBP=9) VTotal=1097\ndtd_56hz = bytes([\n 0x5C, 0x3F, # pixel clock: 16220 × 10 kHz = 162.20 MHz\n 0x00, # H active low 8 bits (2560 & 0xFF)\n 0x50, # H blanking low 8 bits (80)\n 0xA0, # H active high nibble (0xA) | H blank high nibble (0x0)\n 0x38, # V active low 8 bits (1080 & 0xFF)\n 0x11, # V blanking low 8 bits (17)\n 0x40, # V active high nibble (0x4) | V blank high nibble (0x0)\n 0x08, # H front porch (8 px)\n 0x20, # H sync width (32 px)\n 0x35, # V front porch (3) | V sync width (5)\n 0x00, # upper bits (all zero)\n 0x59, 0xFE, 0x20, # image size: 601 × 254 mm\n 0x00, 0x00, # no border\n 0x18, # non-interlaced, separate sync, -HSync -VSync\n])\n\n# ── Patch 1: Replace base EDID DTD 1 (offset 0x36) ────────────────\nedid[0x36:0x36+18] = dtd_56hz\nedid[0x7F] = (256 - (sum(edid[:0x7F]) % 256)) % 256\nprint(\"[OK] Base EDID DTD 1 → 2560x1080@56Hz (162.20 MHz)\")\n\n# ── Patch 2: Find and extend HDMI VSDB ────────────────────────────\nCTA = 0x80\ndtd_off = edid[CTA + 2]\n\npos = CTA + 4\nvsdb_pos = None\nvsdb_len = None\nwhile pos < CTA + dtd_off:\n tag = edid[pos]\n btype = (tag >> 5) & 7\n blen = tag & 0x1F\n if btype == 3 and blen >= 3:\n oui = edid[pos+1] | (edid[pos+2] << 8) | (edid[pos+3] << 16)\n if oui == 0x000C03:\n vsdb_pos, vsdb_len = pos, blen\n break\n pos += 1 + blen\n\nif vsdb_pos is None:\n print(\"[ERROR] HDMI VSDB not found in CTA block\")\n sys.exit(1)\n\nprint(f\"[*] HDMI VSDB at offset 0x{vsdb_pos:02X}, length {vsdb_len}\")\n\n# Only extend if VSDB doesn't already have 7+ data bytes\nneeds_resize = (vsdb_len < 7)\nif needs_resize:\n # Shift bytes right by (7 - vsdb_len) to make room\n extra = 7 - vsdb_len\n ins = vsdb_pos + 1 + vsdb_len\n for i in range(0xFE, ins + extra - 1, -1):\n edid[i] = edid[i - extra]\n # Fill in gap with zeros\n for i in range(extra):\n edid[ins + i] = 0\n edid[vsdb_pos] = (3 << 5) | 7 # updated tag length\n edid[CTA + 2] = dtd_off + extra # update DTD offset\n dtd_off += extra\n vsdb_len = 7\n\n# Set flags + max_tmds_clock\nedid[vsdb_pos + 1 + 5] = 0x00 # db[6]: flags\nedid[vsdb_pos + 1 + 6] = 0x55 # db[7]: 85 × 5 = 425 MHz\nprint(f\"[OK] HDMI VSDB: max_tmds_clock = {edid[vsdb_pos + 1 + 6] * 5} MHz\")\n\n# ── Patch 3: Replace first CTA DTD with 56Hz version ──────────────\ncta_dtd_start = CTA + dtd_off\nif cta_dtd_start + 18 <= 0xFE:\n edid[cta_dtd_start:cta_dtd_start+18] = dtd_56hz\n print(f\"[OK] CTA DTD at 0x{cta_dtd_start:02X} → 2560x1080@56Hz\")\nelse:\n print(\"[!] Not enough space for CTA DTD, skipping\")\n\n# Fix CTA checksum\nedid[0xFF] = (256 - (sum(edid[0x80:0xFF]) % 256)) % 256\nprint(\"[OK] Checksums recalculated\")\n\n# Write output\nwith open(OUT_PATH, \"wb\") as f:\n f.write(edid)\nprint(f\"[*] Saved: {OUT_PATH}\")\n\n# Verify with edid-decode\nimport subprocess\nresult = subprocess.run([\"edid-decode\", OUT_PATH], capture_output=True, text=True)\nfor line in result.stdout.splitlines():\n if \"2560\" in line or \"Checksum\" in line or \"ERROR\" in line or \"FAIL\" in line:\n print(f\" {line.strip()}\")\n"
}
```
**Output:**
```
Wrote file successfully.
```
---
## Assistant (Build · DeepSeek V4 Pro · 3.3s)
_Thinking:_
Now let me run the script to create the patched EDID, then try to apply it.
**Tool: bash**
**Input:**
```json
{
"command": "python3 /tmp/tmp.FqQt6Uhgr4/patch-edid.py"
}
```
**Output:**
```
[*] Loaded EDID (256 bytes)
[OK] Base EDID DTD 1 → 2560x1080@56Hz (162.20 MHz)
[*] HDMI VSDB at offset 0x98, length 13
[OK] HDMI VSDB: max_tmds_clock = 425 MHz
[OK] CTA DTD at 0xBA → 2560x1080@56Hz
[OK] Checksums recalculated
[*] Saved: /tmp/tmp.FqQt6Uhgr4/lg-ultrawide-2560x1080.bin
DTD 1: 2560x1080 56.006740 Hz 64:27 61.439 kHz 162.200000 MHz (601 mm x 254 mm)
Checksum: 0xbf
VIC 89: 2560x1080 50.000000 Hz 64:27 56.250 kHz 185.625000 MHz
DTD 3: 2560x1080 56.006740 Hz 64:27 61.439 kHz 162.200000 MHz (601 mm x 254 mm)
DTD 4: 2560x1440 59.950550 Hz 16:9 88.787 kHz 241.500000 MHz (601 mm x 254 mm)
Checksum: 0xea
```
---
## Assistant (Build · DeepSeek V4 Pro · 8.0s)
_Thinking:_
The EDID was patched successfully. The 2560x1080 @ 56Hz mode is now in the EDID. The checksum is valid.
Now I need to apply it. We need root access for this. The options are:
1. Debugfs edid_override (runtime, no reboot needed)
2. Kernel boot parameter `drm.edid_firmware=` (requires reboot)
Since we don't have sudo available (it requires a terminal), let me try approach 1 first with sudo, and if that fails, use approach 2.
But actually, let me first check if the debugfs edid_override is available by checking the kernel docs. Actually, we already confirmed CONFIG_DRM_LOAD_EDID_FIRMWARE=y, so both debugfs and firmware approaches should work.
Let me try to apply via debugfs. We need root. Let me give the user both options with exact commands.
Actually wait, I can also try `pkexec` or other mechanisms. Let me check what's available.
Actually, let me just provide the user with both options clearly. First, let me try the debugfs approach - it should be faster.
EDID patchado e válido! Agora preciso de acesso root para aplicar. Vou tentar:
**Tool: bash**
**Input:**
```json
{
"command": "groups"
}
```
**Output:**
```
v_raton cdrom floppy sudo audio dip video plugdev netdev bluetooth lpadmin scanner ollama docker
```
---
## Assistant (Build · DeepSeek V4 Pro · 6.0s)
_Thinking:_
The user is in the sudo group. But earlier sudo failed because "a terminal is required to read the password". This means sudo is configured with `Defaults requiretty` or the session doesn't have a proper TTY. But the user gave me permission to proceed. Let me try using `-S` to pipe the password, or try `pkexec`.
Actually, wait - let me try sudo again. Maybe the previous failure was a temporary issue. Or I could try using `SUDO_ASKPASS`.
Actually, let me just give the user the exact commands to run with sudo. The user is clearly watching and can run commands manually if needed.
But first, let me try sudo -S (which reads password from stdin) or see if there's another way.
**Tool: bash**
**Input:**
```json
{
"command": "sudo -n true 2>&1 && echo \"sudo sem senha OK\" || echo \"sudo precisa de senha\""
}
```
**Output:**
```
sudo: a password is required
sudo precisa de senha
```
---
## Assistant (Build · DeepSeek V4 Pro · 6.5s)
_Thinking:_
OK, sudo requires a password and we don't have an interactive terminal to enter it. But the user said "pode tentar" (can try). Let me ask the user to run the sudo commands or provide the password.
Actually, let me ask the user directly how they want to handle this. I'll present the commands and ask them to run them, since we can't sudo interactively.
Preciso de acesso root para aplicar o EDID override. O sudo pede senha. Você pode rodar estes comandos:
```bash
# Opção A: aplicar agora (runtime, sem reboot):
sudo mkdir -p /sys/kernel/debug/dri/ 2>/dev/null
sudo mount -t debugfs debugfs /sys/kernel/debug 2>/dev/null
sudo cp /tmp/tmp.FqQt6Uhgr4/lg-ultrawide-2560x1080.bin /sys/kernel/debug/dri/0/HDMI-A-1/edid_override
echo detect | sudo tee /sys/class/drm/card0-HDMI-A-1/status
sleep 2
cat /sys/class/drm/card0-HDMI-A-1/modes | sort -u | grep 2560
```
Ou prefere que eu mostre o método com `drm.edid_firmware=` no GRUB, que persiste após reboot?
---
## User
sudo mkdir -p /sys/kernel/debug/dri/ 2>/dev/null
sudo mount -t debugfs debugfs /sys/kernel/debug 2>/dev/null
sudo cp /tmp/tmp.FqQt6Uhgr4/lg-ultrawide-2560x1080.bin /sys/kernel/debug/dri/0/HDMI-A-1/edid_override
echo detect | sudo tee /sys/class/drm/card0-HDMI-A-1/status
sleep 2
cat /sys/class/drm/card0-HDMI-A-1/modes | sort -u | grep 2560
[sudo] password for v_raton:
cp: cannot create regular file '/sys/kernel/debug/dri/0/HDMI-A-1/edid_override': Operation not permitted
detect
~
---
## Assistant (Build · DeepSeek V4 Pro · 8.0s)
_Thinking:_
The debugfs edid_override approach failed with "Operation not permitted" - this likely means the kernel locks down debugfs writes for security (kernel lockdown or secure boot). Let me try the alternative approach: using `drm.edid_firmware=` kernel boot parameter.
This requires:
1. Copy the patched EDID to /lib/firmware/edid/
2. Add `drm.edid_firmware=HDMI-A-1:edid/lg-ultrawide-2560x1080.bin` to kernel command line via GRUB
3. Rebuild initramfs if needed (on Debian, `drm.edid_firmware` needs the firmware to be in the initramfs)
4. Reboot
Let me tell the user this approach.
O debugfs está bloqueado (provavelmente kernel lockdown/secure boot). Vamos pelo método via parâmetro de kernel, que é mais confiável. Rode estes comandos:
```bash
# 1. Criar diretório e copiar EDID
sudo mkdir -p /lib/firmware/edid
sudo cp /tmp/tmp.FqQt6Uhgr4/lg-ultrawide-2560x1080.bin /lib/firmware/edid/
# 2. Atualizar initramfs para incluir o EDID na fase early boot
sudo update-initramfs -u
# 3. Verificar se foi incluído
lsinitramfs /boot/initrd.img-$(uname -r) | grep edid
```
Se confirmar que o EDID está no initramfs, o próximo passo é adicionar no GRUB e reiniciar.
---
## User
mas eu precisaria adicionar no grupo?
---
## Assistant (Build · DeepSeek V4 Pro · 7.0s)
_Thinking:_
The user is asking if they need to add something to the GRUB config. After copying the EDID file to /lib/firmware/edid/, we need to add `drm.edid_firmware=HDMI-A-1:edid/lg-ultrawide-2560x1080.bin` to the kernel command line. Yes, they need to add it to GRUB.
Let me tell them to run the first commands, and then we'll do the GRUB step.
Sim! Depois de copiar o EDID e rebuildar o initramfs, precisa adicionar no GRUB:
```bash
# 1. Copiar EDID e rebuildar initramfs
sudo mkdir -p /lib/firmware/edid
sudo cp /tmp/tmp.FqQt6Uhgr4/lg-ultrawide-2560x1080.bin /lib/firmware/edid/
sudo update-initramfs -u
# 2. Editar o GRUB — adicionar esta linha em GRUB_CMDLINE_LINUX_DEFAULT:
drm.edid_firmware=HDMI-A-1:edid/lg-ultrawide-2560x1080.bin
# 3. Atualizar GRUB e reiniciar
sudo update-grub && sudo reboot
```
Rode os comandos do passo 1 primeiro para eu confirmar que o EDID entrou no initramfs, depois fazemos o GRUB juntos.
---
## User
update-initramfs: Generating /boot/initrd.img-6.12.100+deb13-amd64
❯ lsinitramfs /boot/initrd.img-$(uname -r) | grep edid
unmkinitramfs: /boot/initrd.img-6.12.100+deb13-amd64: Permission denied
❯ sudo lsinitramfs /boot/initrd.img-$(uname -r) | grep edid
~ 18:2
~ 18:26:36
❯
---
## Assistant (Build · DeepSeek V4 Pro · 10.0s)
_Thinking:_
The initramfs update went through, but `lsinitramfs` didn't find the edid file. This means the tool doesn't automatically pick up custom firmware from `/lib/firmware/edid/`. We need to configure initramfs-tools to include the file explicitly.
On Debian, we can create a hook in `/etc/initramfs-tools/hooks/` to include the EDID file, or we can add it to `/etc/initramfs-tools/modules` or use a different approach.
Actually, the simplest way on Debian is to create a file in `/usr/share/initramfs-tools/hooks/` or `/etc/initramfs-tools/hooks/` that copies the EDID into the initramfs.
Let me check how to include custom firmware files in the Debian initramfs.
Actually, `drm.edid_firmware=HDMI-A-1:edid/lg-ultrawide-2560x1080.bin` requires the file to be in `/lib/firmware/edid/` in the initramfs. The `update-initramfs` might not include it automatically because it's not a "known" firmware file.
The proper way on Debian is:
1. Create a hook script in `/etc/initramfs-tools/hooks/`
2. Rebuild initramfs
Let me help the user do this.
Actually, let me also think about an alternative. Since the edid_override debugfs approach failed (operation not permitted), this might be due to kernel lockdown mode (secure boot). Let me check if that's the case and if we can work around it.
But first, let's focus on the initramfs approach.
O initramfs não incluiu o arquivo automaticamente. Precisamos criar um hook. Rode:
```bash
sudo tee /etc/initramfs-tools/hooks/edid-override << 'EOF'
#!/bin/sh
PREREQ=""
prereqs() { echo "$PREREQ"; }
case "$1" in
prereqs) prereqs; exit 0;;
esac
. /usr/share/initramfs-tools/hook-functions
mkdir -p "${DESTDIR}/lib/firmware/edid"
cp /lib/firmware/edid/lg-ultrawide-2560x1080.bin "${DESTDIR}/lib/firmware/edid/"
EOF
sudo chmod +x /etc/initramfs-tools/hooks/edid-override
sudo update-initramfs -u
sudo lsinitramfs /boot/initrd.img-$(uname -r) | grep edid
```
---
## User
mas se algo disso der eeror qual o risco?
---
## Assistant (Build · DeepSeek V4 Pro · 8.4s)
_Thinking:_
The user is asking about risks. Let me explain clearly:
1. If the EDID hook fails or the new mode doesn't work, the risk is minimal:
- The monitor might stay at 1920x1080 (current working resolution)
- In worst case, the external display might not show properly
- A reboot without the kernel parameter would revert everything
2. Nothing about this is permanent or destructive - we're only modifying files that can be easily removed
Let me just answer directly.
Risco zero. O pior que pode acontecer é o monitor externo não mostrar imagem após o reboot. Se isso ocorrer:
- O laptop ainda funciona com a tela interna (`eDP-1`)
- Basta remover o parâmetro `drm.edid_firmware=` do GRUB e rodar `sudo update-grub`
- Ou bootar com um kernel anterior do menu do GRUB
- Nada é alterado permanentemente no monitor nem no hardware
Quer prosseguir?
---
## User
pode seguir
---
## Assistant (Build · DeepSeek V4 Pro · 6.3s)
_Thinking:_
The user wants me to proceed with the changes. Now I'm in build mode, so I can make file changes. Let me:
1. Create the initramfs hook
2. Run update-initramfs
3. Verify the EDID is in the initramfs
4. Then edit the GRUB config
But I don't have sudo available. Let me ask the user to run the commands, or let me try to use sudo again.
Actually, the user just ran the commands I suggested in the previous message. So they're willing to copy-paste and run commands. Let me give them the commands step by step.
Let me provide the full sequence of commands.
**Tool: todowrite**
**Input:**
```json
{
"todos": [
{
"content": "Criar hook initramfs para incluir EDID",
"priority": "high",
"status": "in_progress"
},
{
"content": "Rebuildar initramfs e verificar inclusão",
"priority": "high",
"status": "pending"
},
{
"content": "Adicionar drm.edid_firmware no GRUB",
"priority": "high",
"status": "pending"
},
{
"content": "Atualizar GRUB e reiniciar",
"priority": "high",
"status": "pending"
},
{
"content": "Verificar se 2560x1080 aparece após reboot",
"priority": "high",
"status": "pending"
}
]
}
```
**Output:**
```
[
{
"content": "Criar hook initramfs para incluir EDID",
"status": "in_progress",
"priority": "high"
},
{
"content": "Rebuildar initramfs e verificar inclusão",
"status": "pending",
"priority": "high"
},
{
"content": "Adicionar drm.edid_firmware no GRUB",
"status": "pending",
"priority": "high"
},
{
"content": "Atualizar GRUB e reiniciar",
"status": "pending",
"priority": "high"
},
{
"content": "Verificar se 2560x1080 aparece após reboot",
"status": "pending",
"priority": "high"
}
]
```
---
## Assistant (Build · DeepSeek V4 Pro · 7.8s)
_Thinking:_
Let me run the commands step by step. Since sudo requires the user's password, I'll provide the commands and the user will run them.
Actually, let me try a different approach - let me write the hook file and the grub config in the user's home/some accessible place, then provide one consolidated set of sudo commands.
Actually, better: let me write the files first (without sudo) where I can, and then give the user the sudo commands.
Vou criar o hook e depois você roda o resto. Primeiro o hook:
**Tool: write**
**Input:**
```json
{
"content": "#!/bin/sh\nPREREQ=\"\"\nprereqs() { echo \"$PREREQ\"; }\ncase \"$1\" in\n prereqs) prereqs; exit 0;;\nesac\n\n. /usr/share/initramfs-tools/hook-functions\nmkdir -p \"${DESTDIR}/lib/firmware/edid\"\ncp /lib/firmware/edid/lg-ultrawide-2560x1080.bin \"${DESTDIR}/lib/firmware/edid/\"\n",
"filePath": "/tmp/tmp.FqQt6Uhgr4/edid-override-hook"
}
```
**Output:**
```
Wrote file successfully.
```
---
## Assistant (Build · DeepSeek V4 Pro · 4.6s)
_Thinking:_
Now I need the user to:
1. Copy the hook to /etc/initramfs-tools/hooks/
2. chmod +x
3. update-initramfs
4. Verify
Then edit grub config and reboot.
Let me provide the full sequence.
Agora rode este bloco completo:
```bash
# Copiar hook e dar permissão
sudo cp /tmp/tmp.FqQt6Uhgr4/edid-override-hook /etc/initramfs-tools/hooks/edid-override
sudo chmod +x /etc/initramfs-tools/hooks/edid-override
# Rebuild initramfs
sudo update-initramfs -u
# Verificar se o EDID entrou
sudo lsinitramfs /boot/initrd.img-$(uname -r) | grep lg-ultrawide
```
---
## User
sudo lsinitramfs /boot/initrd.img-$(uname -r) | grep lg-ultrawide
usr/lib/firmware/edid/lg-ultrawide-2560x1080.bin
---
## Assistant (Build · DeepSeek V4 Pro · 6.8s)
_Thinking:_
The EDID is in the initramfs. Now I need to add the kernel parameter to GRUB and update it.
Let me edit the GRUB config. I need to add `drm.edid_firmware=HDMI-A-1:edid/lg-ultrawide-2560x1080.bin` to the kernel command line.
I should edit /etc/default/grub and add this parameter. Since I can't sudo, let me write the change and ask the user to run the update.
Actually, I can use `sed` with sudo. Let me provide the commands.
Wait, looking at the initramfs path: `usr/lib/firmware/edid/lg-ultrawide-2560x1080.bin` - the kernel will look for this at `/lib/firmware/edid/lg-ultrawide-2560x1080.bin` during early boot. The `drm.edid_firmware` parameter should point to `edid/lg-ultrawide-2560x1080.bin` (relative to /lib/firmware/).
Now let me provide the GRUB commands.
EDID está no initramfs. Agora o GRUB:
**Tool: todowrite**
**Input:**
```json
{
"todos": [
{
"content": "Criar hook initramfs para incluir EDID",
"priority": "high",
"status": "completed"
},
{
"content": "Rebuildar initramfs e verificar inclusão",
"priority": "high",
"status": "completed"
},
{
"content": "Adicionar drm.edid_firmware no GRUB",
"priority": "high",
"status": "in_progress"
},
{
"content": "Atualizar GRUB e reiniciar",
"priority": "high",
"status": "pending"
},
{
"content": "Verificar se 2560x1080 aparece após reboot",
"priority": "high",
"status": "pending"
}
]
}
```
**Output:**
```
[
{
"content": "Criar hook initramfs para incluir EDID",
"status": "completed",
"priority": "high"
},
{
"content": "Rebuildar initramfs e verificar inclusão",
"status": "completed",
"priority": "high"
},
{
"content": "Adicionar drm.edid_firmware no GRUB",
"status": "in_progress",
"priority": "high"
},
{
"content": "Atualizar GRUB e reiniciar",
"status": "pending",
"priority": "high"
},
{
"content": "Verificar se 2560x1080 aparece após reboot",
"status": "pending",
"priority": "high"
}
]
```
---
## Assistant (Build · DeepSeek V4 Pro · 4.5s)
**Tool: edit**
**Input:**
```json
{
"filePath": "/etc/default/grub",
"oldString": "GRUB_CMDLINE_LINUX_DEFAULT=\"quiet splash\"",
"newString": "GRUB_CMDLINE_LINUX_DEFAULT=\"quiet splash drm.edid_firmware=HDMI-A-1:edid/lg-ultrawide-2560x1080.bin\""
}
```
**Error:**
```
PermissionDenied: FileSystem.writeFile (/etc/default/grub)
```
---
## Assistant (Build · DeepSeek V4 Pro · 5.0s)
_Thinking:_
I can't edit /etc/default/grub directly. Let me use sudo to edit it. I'll provide the command to the user.
Actually, let me try via bash with sudo. But sudo requires password... Let me give the user the exact command.
Rode estes comandos:
```bash
# Adicionar o parâmetro ao GRUB
sudo sed -i 's/GRUB_CMDLINE_LINUX_DEFAULT="quiet splash"/GRUB_CMDLINE_LINUX_DEFAULT="quiet splash drm.edid_firmware=HDMI-A-1:edid\/lg-ultrawide-2560x1080.bin"/' /etc/default/grub
# Verificar
grep CMDLINE_LINUX_DEFAULT /etc/default/grub
# Atualizar GRUB
sudo update-grub
```
---
## User
❯ grep CMDLINE_LINUX_DEFAULT /etc/default/grub
GRUB_CMDLINE_LINUX_DEFAULT="quiet splash drm.edid_firmware=HDMI-A-1:edid/lg-ultrawide-2560x1080.bin"
❯ sudo update-grub
Generating grub configuration file ...
Found background image: /usr/share/images/desktop-base/desktop-grub.png
Found linux image: /boot/vmlinuz-6.12.100+deb13-amd64
Found initrd image: /boot/initrd.img-6.12.100+deb13-amd64
Found linux image: /boot/vmlinuz-6.12.96+deb13-amd64
Found initrd image: /boot/initrd.img-6.12.96+deb13-amd64
Found linux image: /boot/vmlinuz-6.12.95+deb13-amd64
Found initrd image: /boot/initrd.img-6.12.95+deb13-amd64
Warning: os-prober will be executed to detect other bootable partitions.
Its output will be used to detect bootable binaries on them and create new boot entries.
Adding boot menu entry for UEFI Firmware Settings ...
done
~
---
## Assistant (Build · DeepSeek V4 Pro · 4.7s)
_Thinking:_
The GRUB config is updated and grub.cfg has been regenerated. Now the user needs to reboot. After reboot, we'll check if 2560x1080 appears in the mode list.
Let me update the todo list and tell the user to reboot.
**Tool: todowrite**
**Input:**
```json
{
"todos": [
{
"content": "Criar hook initramfs para incluir EDID",
"priority": "high",
"status": "completed"
},
{
"content": "Rebuildar initramfs e verificar inclusão",
"priority": "high",
"status": "completed"
},
{
"content": "Adicionar drm.edid_firmware no GRUB",
"priority": "high",
"status": "completed"
},
{
"content": "Atualizar GRUB e reiniciar",
"priority": "high",
"status": "completed"
},
{
"content": "Verificar se 2560x1080 aparece após reboot",
"priority": "high",
"status": "in_progress"
}
]
}
```
**Output:**
```
[
{
"content": "Criar hook initramfs para incluir EDID",
"status": "completed",
"priority": "high"
},
{
"content": "Rebuildar initramfs e verificar inclusão",
"status": "completed",
"priority": "high"
},
{
"content": "Adicionar drm.edid_firmware no GRUB",
"status": "completed",
"priority": "high"
},
{
"content": "Atualizar GRUB e reiniciar",
"status": "completed",
"priority": "high"
},
{
"content": "Verificar se 2560x1080 aparece após reboot",
"status": "in_progress",
"priority": "high"
}
]
```
---
## Assistant (Build · DeepSeek V4 Pro · 3.6s)
Tudo pronto. **Reinicie agora:**
```bash
sudo reboot
```
Após o reboot, volte aqui e rode este comando para verificar se funcionou:
```bash
cat /sys/class/drm/card0-HDMI-A-1/modes | sort -u | grep 2560
```
Se aparecer `2560x1080`, o EDID override funcionou e a resolução nativa estará disponível nas configurações de tela do KDE em 56 Hz.
---
## User
reiniciei e troquei a resolucao teria como validar
---
## Assistant (Build · DeepSeek V4 Pro · 7.3s)
_Thinking:_
The user rebooted and says they changed the resolution. Let me verify that 2560x1080 is now working properly.
**Tool: bash**
**Input:**
```json
{
"command": "cat /sys/class/drm/card0-HDMI-A-1/modes | sort -u | head -20"
}
```
**Output:**
```
1024x768
1152x864
1280x1024
1280x720
1280x800
1600x900
1680x1050
1920x1080
2560x1080
640x480
720x480
720x576
800x600
832x624
```
**Tool: bash**
**Input:**
```json
{
"command": "kscreen-doctor --outputs 2>&1 | grep -A 30 \"HDMI-A-1\""
}
```
**Output:**
```
[01;32mOutput: [0;0m2 HDMI-A-1
[01;32menabled[0;0m
[01;32mconnected[0;0m
[01;32mpriority 1[0;0m
[01;33mHDMI[0;0m
[01;34mModes: [0;0m 15:[01;32m2560x1080@56*[0;0m! 16:1920x1080@60 17:1920x1080@60 18:1920x1080@60 19:1920x1080@50 20:1680x1050@60 21:1600x900@60 22:1280x1024@75 23:1280x1024@60 24:1280x800@60 25:1152x864@60 26:1280x720@60 27:1280x720@60 28:1280x720@60 29:1280x720@50 30:1024x768@75 31:1024x768@60 32:832x624@75 33:800x600@75 34:800x600@60 35:720x576@50 36:720x480@60 37:720x480@60 38:640x480@75 39:640x480@60 40:640x480@60 41:640x480@60
[01;33m Geometry: [0;0m0,0 2560x1080
[01;33m Scale: [0;0m1
[01;33m Rotation: [0;0m1
[01;33m Overscan: [0;0m0
[01;33m Vrr: [0;0mincapable
[01;33m RgbRange: [0;0mAutomatic
[01;33m HDR: [0;0mdisabled
[01;33m Wide Color Gamut: [0;0mdisabled
[01;33m ICC profile: [0;0mnone
[01;33m Color profile source: [0;0msRGB
[01;33m Color power preference: [0;0mprefer accuracy
[01;33m Brightness control: [0;0msupported, set to 64% and dimming to 100%
```
**Tool: bash**
**Input:**
```json
{
"command": "cat /proc/cmdline"
}
```
**Output:**
```
BOOT_IMAGE=/boot/vmlinuz-6.12.100+deb13-amd64 root=UUID=9757ad5c-2c4e-49af-9220-b8363a3c209c ro quiet splash drm.edid_firmware=HDMI-A-1:edid/lg-ultrawide-2560x1080.bin
```
---
## Assistant (Build · DeepSeek V4 Pro · 8.6s)
_Thinking:_
Everything is working perfectly:
1. **2560x1080 @ 56Hz** está na lista de modos do kernel ✓
2. **KDE está usando 2560x1080@56** como modo atual (marcado com `*` e `!` = preferred) ✓
3. **Geometry: 0,0 2560x1080** - resolução nativa aplicada ✓
4. **Scale: 1** - sem scaling distorcido ✓
5. **Parâmetro do kernel** carregado corretamente ✓
O EDID override funcionou perfeitamente! O monitor agora está rodando em 2560x1080 (21:9) a 56 Hz, que é o máximo que o conversor DP→HDMI de 165 MHz permite.
**Funcionou!** Tudo validado:
| Item | Status |
|------|--------|
| `2560x1080` no kernel | ✓ |
| Modo ativo | **2560x1080@56Hz** (preferred) |
| Geometry | `0,0 2560x1080` — resolução nativa |
| Scale | `1.0` — pixel-perfect, sem distorção |
| Parâmetro kernel | `drm.edid_firmware=...` carregado |
Seu monitor LG ULTRAWIDE está rodando em 21:9 nativo a **56 Hz** (o máximo que o conversor DP→HDMI de 165 MHz do Ice Lake permite). A diferença de 56 Hz vs 60 Hz é imperceptível para uso desktop.
**Tool: todowrite**
**Input:**
```json
{
"todos": [
{
"content": "Criar hook initramfs para incluir EDID",
"priority": "high",
"status": "completed"
},
{
"content": "Rebuildar initramfs e verificar inclusão",
"priority": "high",
"status": "completed"
},
{
"content": "Adicionar drm.edid_firmware no GRUB",
"priority": "high",
"status": "completed"
},
{
"content": "Atualizar GRUB e reiniciar",
"priority": "high",
"status": "completed"
},
{
"content": "Verificar se 2560x1080 aparece após reboot",
"priority": "high",
"status": "completed"
}
]
}
```
**Output:**
```
[
{
"content": "Criar hook initramfs para incluir EDID",
"status": "completed",
"priority": "high"
},
{
"content": "Rebuildar initramfs e verificar inclusão",
"status": "completed",
"priority": "high"
},
{
"content": "Adicionar drm.edid_firmware no GRUB",
"status": "completed",
"priority": "high"
},
{
"content": "Atualizar GRUB e reiniciar",
"status": "completed",
"priority": "high"
},
{
"content": "Verificar se 2560x1080 aparece após reboot",
"status": "completed",
"priority": "high"
}
]
```
---
## Assistant (Build · DeepSeek V4 Pro · 2.8s)
---
## User
explique pra min de forma resumida o que rolou aqui e o pq isso teve que ser feito
---
## Assistant (Plan · DeepSeek V4 Pro · 9.0s)
_Thinking:_
The user wants a concise explanation of what happened and why it was necessary. Let me summarize.
## Resumo
**Problema:** Seu notebook (Dell com Intel Ice Lake) tem a porta HDMI implementada via um chip conversor **DisplayPort → HDMI** (LSPCON) com limite físico de **165 MHz**. Para entregar 2560x1080 a 60 Hz, seriam necessários **181.25 MHz** — o kernel i915 via isso, rejeitava o modo e limitava a 1920x1080.
**Solução:** Criamos um EDID falso que declara 2560x1080 a **56 Hz** com pixel clock de **162.20 MHz** (dentro do limite de 165 MHz). Esse EDID é injetado via parâmetro de kernel (`drm.edid_firmware=`) na fase inicial de boot, antes do driver i915 validar os modos. O resultado é 2560x1080 nativo a 56 Hz — os 4 Hz a menos são imperceptíveis, e o monitor agora usa toda a área da tela.
**Por que teve que ser feito:** Limitação de hardware do chip DP→HDMI do Ice Lake, não do cabo ou do monitor. É um problema conhecido e documentado dessa geração de GPU Intel.
---
## User
com quantos paus se faz uma canoa
---
## Assistant (Plan · DeepSeek V4 Pro · 6.4s)
_Thinking:_
The user is asking a humorous/meta question: "com quantos paus se faz uma canoa" which is a Brazilian Portuguese expression meaning "with how many sticks do you make a canoe" - it's basically asking "how many people/things/steps does it take to do something." They're making a lighthearted comment about all the steps we went through to fix their monitor.
I should give a brief, matching the tone.
Haha, no seu caso: **3 paus** — 1 Python, 1 initramfs hook e 1 parâmetro de kernel. E a canoa (2560x1080) já está navegando.
---
## User
---
## Assistant (Compaction · DeepSeek V4 Pro · 21.6s)
_Thinking:_
Let me summarize the conversation history into the required format.
The user had an ultrawide monitor (LG ULTRAWIDE) connected via HDMI 2.1 cable to a Dell laptop with Intel Iris Plus Graphics G1 (Ice Lake). They couldn't configure the 21:9 aspect ratio on Debian 13 (Trixie) with KDE Wayland.
The root cause: Ice Lake's HDMI is DP++ converted via LSPCON with a 165 MHz TMDS clock limit. The native 2560x1080@60Hz needs 181.25 MHz, which exceeds the limit.
The solution: Patched EDID to add 2560x1080@56Hz (162.20 MHz) via a Python script, loaded through kernel parameter `drm.edid_firmware=` with an initramfs hook.
The fix was successfully applied and verified.
## Objective
- Make LG ULTRAWIDE monitor work at native 21:9 resolution (2560x1080) over HDMI on a Dell laptop with Intel Iris Plus G1 (Ice Lake) running Debian 13 Trixie with KDE Wayland.
## Important Details
- **Hardware**: Intel Iris Plus Graphics G1 (Ice Lake, i915 driver), HDMI via LSPCON (DP→HDMI converter) with **165 MHz TMDS clock limit**
- **Monitor**: LG ULTRAWIDE, EDID reports native 2560x1080@60Hz (181.25 MHz), also supports up to 2560x1440@60Hz and 3840x2160@30Hz
- **Root cause**: 2560x1080@60Hz requires 181.25 MHz > 165 MHz hardware limit; i915 driver rejects modes above limit, max exposed was 1920x1080
- **Fix**: Patched EDID with 2560x1080@56Hz reduced-blanking DTD (162.20 MHz), loaded via `drm.edid_firmware=` kernel parameter
- **Distro**: Debian 13 Trixie, kernel 6.12.100, KDE Plasma (KWin) Wayland, `CONFIG_DRM_LOAD_EDID_FIRMWARE=y`
- **Cable**: HDMI 2.1 (not the bottleneck — limitation is on the GPU side)
- **Risk**: None; EDID override is in RAM only, reversible by removing kernel param from GRUB
## Work State
### Completed
- Diagnosed that kernel i915 was not exposing 2560x1080 modes (<1920x1080 max)
- Found matching GitHub solution: `nic0der-im/fix-ultrawide-intel-notebook-hdmi`
- Created patched EDID (`/lib/firmware/edid/lg-ultrawide-2560x1080.bin`) with Python script replacing DTD1 and CTA DTD with 2560x1080@56Hz (162.20 MHz), HDMI VSDB max_tmds_clock=425 MHz
- Created initramfs hook at `/etc/initramfs-tools/hooks/edid-override` to include EDID in early boot
- Added `drm.edid_firmware=HDMI-A-1:edid/lg-ultrawide-2560x1080.bin` to `GRUB_CMDLINE_LINUX_DEFAULT` in `/etc/default/grub`
- Ran `update-initramfs -u` and `update-grub`
- Rebooted and verified: 2560x1080@56Hz is now the active preferred mode, geometry 2560x1080, scale 1.0, pixel-perfect
### Active
- (none)
### Blocked
- (none)
## Next Move
1. (none — issue resolved)
## Relevant Files
- `/lib/firmware/edid/lg-ultrawide-2560x1080.bin` — patched EDID binary for 2560x1080@56Hz
- `/etc/initramfs-tools/hooks/edid-override` — initramfs hook to include EDID at boot
- `/etc/default/grub` — contains `drm.edid_firmware=HDMI-A-1:edid/lg-ultrawide-2560x1080.bin` in `GRUB_CMDLINE_LINUX_DEFAULT`
- `/tmp/tmp.FqQt6Uhgr4/patch-edid.py` — EDID patching script (temp, can be cleaned up)
- Reference: `https://github.com/nic0der-im/fix-ultrawide-intel-notebook-hdmi` — original solution for same hardware issue
---