- Updates
- 2025-10-04:
- Test If Issue Relates to HW or SW → issue sticks to SSD when switched → it's a software bug
- done: gdctl comparison
- done: Compare BIOS settings
- done: Compare GRUB settings
- still: different "Capabilities" listed by
lspci -v
are probably the hottest candidate to the solution.
- 2025-10-05: found and solve the issue
- 2025-10-04:
Problem description: Lenovo x13 2-in-1 Gen 5 with Debian 13 GNOME 48: I can't select the native screen resolution for the external 34" TFT which is 2560x1080. Hostname = Cosmo.
In the GNOME screen configuration dialog, I may only choose a resolution (among others) that is similar but not correct: 2560x1440
2025-10-05: TL;DR: For some particular package, I needed testing/unstable Debian sources on Jackson and pinned this package to testing or unstable. Somehow, Jackson took all packages from Debian unstable. So I got a newer kernel than Debian 13 stable/trixie on Jackson without realizing but not on Cosmo. It seems to be the case that the stable kernel from Debian 13 is not able to properly recognize the external TFT. By installing the newer kernel to Cosmo, the external TFT now works with its native resolution. I still need to figure out how to define the unstable package exception for the kernel only. This could have been much easier when I would have checked the kernel version right away.
Testing GRUB parameter
CLOSED: [2025-10-04 Sat 14:20]
I modified /tmp/etc/default/grub
and added a video-parameter that did not change anythig:
GRUB_CMDLINE_LINUX_DEFAULT="quiet video=eDP-1:2560x1080@30"
Testing Another, Almost Identical Device
Testing a different Lenovo x13 2-in-1 Gen 5 (hostname = Jackson; same generation, different battery, i7 CPU instead of i5) with the same OS + GNOME: display resolution is detected and selected correctly!
-
do a firmware-update
- did install but did not fix the issue.
- Firmware is now identical on both devices.
Compare output of lspci -v
Cosmo: (wrong resolution)
00:02.0 VGA compatible controller: Intel Corporation Meteor Lake-P [Intel Graphics] (rev 08) (prog-if 00 [VGA controller]) Subsystem: Lenovo Device 232a Flags: bus master, fast devsel, latency 0, IRQ 192, IOMMU group 0 Memory at 4058000000 (64-bit, prefetchable) [size=16M] Memory at 4000000000 (64-bit, prefetchable) [size=256M] Expansion ROM at 000c0000 [virtual] [disabled] [size=128K] Capabilities: [40] Vendor Specific Information: Len=0c <?> Capabilities: [70] Express Root Complex Integrated Endpoint, IntMsgNum 0 Capabilities: [ac] MSI: Enable+ Count=1/1 Maskable+ 64bit+ Capabilities: [d0] Power Management version 3 Capabilities: [100] Null Capabilities: [110] Process Address Space ID (PASID) Capabilities: [200] Address Translation Service (ATS) Capabilities: [420] Physical Resizable BAR Capabilities: [320] Single Root I/O Virtualization (SR-IOV) Capabilities: [400] Latency Tolerance Reporting Kernel driver in use: i915 Kernel modules: i915, xe
jackson: (resolution OK)
00:02.0 VGA compatible controller: Intel Corporation Meteor Lake-P [Intel Graphics] (rev 08) (prog-if 00 [VGA controller]) Subsystem: Lenovo Device 232a Flags: bus master, fast devsel, latency 0, IRQ 192, IOMMU group 0 Memory at 4058000000 (64-bit, prefetchable) [size=16M] Memory at 4000000000 (64-bit, prefetchable) [size=256M] Expansion ROM at 000c0000 [virtual] [disabled] [size=128K] Capabilities: [40] Vendor Specific Information: Intel Capabilities v1 CapA: Peg60Dis- Peg12Dis- Peg11Dis- Peg10Dis- PeLWUDis- DmiWidth=x4 EccDis- ForceEccEn- VTdDis- DmiG2Dis- PegG2Dis- DDRMaxSize=Unlimited 1NDis- CDDis- DDPCDis- X2APICEn- PDCDis- IGDis- CDID=0 CRID=0 DDROCCAP+ OCEn- DDRWrtVrefEn+ DDR3LEn+ CapB: ImguDis- OCbySSKUCap- OCbySSKUEn- SMTCap- CacheSzCap 0x0 SoftBinCap- DDR3MaxFreqWithRef100=Disabled PegG3Dis- PkgTyp- AddGfxEn- AddGfxCap- PegX16Dis- DmiG3Dis- GmmDis- DDR3MaxFreq=2932MHz LPDDR3En- Capabilities: [70] Express Root Complex Integrated Endpoint, IntMsgNum 0 Capabilities: [ac] MSI: Enable+ Count=1/1 Maskable+ 64bit+ Capabilities: [d0] Power Management version 3 Capabilities: [100] Null Capabilities: [110] Process Address Space ID (PASID) Capabilities: [200] Address Translation Service (ATS) Capabilities: [420] Physical Resizable BAR Capabilities: [320] Single Root I/O Virtualization (SR-IOV) Capabilities: [400] Latency Tolerance Reporting Kernel driver in use: i915 Kernel modules: i915, xe
So I've got the same graphics hardware, same kernel driver, same version.
However, the difference is:
non-working host: Capabilities: [40] Vendor Specific Information: Len=0c <?> vs. working host: Capabilities: [40] Vendor Specific Information: Intel Capabilities v1 CapA: Peg60Dis- Peg12Dis- Peg11Dis- Peg10Dis- PeLWUDis- DmiWidth=x4 EccDis- ForceEccEn- VTdDis- DmiG2Dis- PegG2Dis- DDRMaxSize=Unlimited 1NDis- CDDis- DDPCDis- X2APICEn- PDCDis- IGDis- CDID=0 CRID=0 DDROCCAP+ OCEn- DDRWrtVrefEn+ DDR3LEn+ CapB: ImguDis- OCbySSKUCap- OCbySSKUEn- SMTCap- CacheSzCap 0x0 SoftBinCap- DDR3MaxFreqWithRef100=Disabled PegG3Dis- PkgTyp- AddGfxEn- AddGfxCap- PegX16Dis- DmiG3Dis- GmmDis- DDR3MaxFreq=2932MHz LPDDR3En-
This seems to be the most important hint, why those two devices differ. However, I have no idea what to do next.
STARTED Find Out What This Difference Means and How to Get Cosmo to the Same Capabilities
Any idea? Drop me a line.
Test If Issue Relates to HW or SW
CLOSED: [2025-10-04 Sat 13:35]
I switched SSDs between the two x13 devices I've got.
The wrongly identified native screen resolution sticks to the SSD, not the actual hardware device.
In other words: The issue does not relate to the hardware, it relates to the booted operating system and its configuration.
Compare /etc between the two hosts
CLOSED: [2025-09-17 Wed 18:36]
I did a comparison using "meld" of the two /etc
hierarchies and did not find any obvious difference that could explain the situation.
Using gdctl
CLOSED: [2025-10-04 Sat 14:28]
GNOME 48 has a new tool as an in-place replacement of (x)randr
named gdctl
.
Here's the output for cosmo which shows the wrong "Current mode" for HDMI-1:
gdctl show Monitors: ├──Monitor HDMI-1 (LG Electronics 34") │ ├──Vendor: GSM │ ├──Product: LG ULTRAWIDE │ ├──Serial: 0x0002de64 │ ├──Current mode │ │ └──2560x1440@59.951 │ └──Preferences: │ └──Luminances: │ ├──default ⇒ 100.0 (default) (current) │ └──bt2100 ⇒ 100.0 (default) └──Monitor eDP-1 (Built-in display) ├──Vendor: AUO ├──Product: 0x6693 ├──Serial: 0x00000000 ├──Current mode │ └──1920x1200@60.026 └──Preferences: └──Luminances: └──default ⇒ 100.0 (default) (current) Logical monitors: ├──Logical monitor #1 │ ├──Position: (2560, 480) │ ├──Scale: 1.25 │ ├──Transform: 180 │ ├──Primary: no │ └──Monitors: (1) │ └──eDP-1 (Built-in display) └──Logical monitor #2 ├──Position: (0, 0) ├──Scale: 1.0 ├──Transform: normal ├──Primary: yes └──Monitors: (1) └──HDMI-1 (LG Electronics 34")
user@cosmo ~ % gdctl show -m Monitors: ├──Monitor HDMI-1 (LG Electronics 34") │ ├──Vendor: GSM │ ├──Product: LG ULTRAWIDE │ ├──Serial: 0x0002de64 │ └──Modes (23) │ ├──3840x2160@30.000 │ ├──3840x2160@29.970 │ ├──3840x2160@25.000 │ ├──3840x2160@24.000 │ ├──3840x2160@23.976 │ ├──2560x1440@59.951 │ ├──1920x1080@60.000 │ ├──1920x1080@59.940 │ ├──1920x1080@50.000 │ ├──1680x1050@59.883 │ ├──1600x900@60.000 │ ├──1280x1024@75.025 │ ├──1280x1024@60.020 │ ├──1280x800@59.910 │ ├──1280x720@60.000 │ ├──1280x720@59.940 │ ├──1280x720@50.000 │ ├──1024x768@75.029 │ ├──1024x768@60.004 │ ├──832x624@74.551 │ ├──800x600@75.000 │ ├──800x600@60.317 │ └──720x576@50.000 │ └──Preferences: [...]
- try setting via gdctl:
user@cosmo ~ % gdctl set -LpM HDMI-1 --mode 2560x1080@60 Failed to create configuration: No mode 2560x1080@60 available for HDMI-1 1 user@cosmo ~ %
→ fails.
- Compare with output of host jackson when connected to same TFT
user@jackson ~ % gdctl show Monitors: ├──Monitor HDMI-1 (LG Electronics 34") │ ├──Vendor: GSM │ ├──Product: LG ULTRAWIDE │ ├──Serial: 0x0002de64 │ ├──Current mode │ │ └──2560x1080@59.978 │ └──Preferences: │ └──Luminances: │ ├──default ⇒ 100.0 (default) (current) │ └──bt2100 ⇒ 100.0 (default) └──Monitor eDP-1 (Built-in display) ├──Vendor: AUO ├──Product: 0x6693 ├──Serial: 0x00000000 ├──Current mode │ └──1920x1200@60.026 └──Preferences: └──Luminances: └──default ⇒ 100.0 (default) (current) Logical monitors: ├──Logical monitor #1 │ ├──Position: (0, 0) │ ├──Scale: 1.25 │ ├──Transform: normal │ ├──Primary: yes │ └──Monitors: (1) │ └──eDP-1 (Built-in display) └──Logical monitor #2 ├──Position: (1536, 0) ├──Scale: 1.0 ├──Transform: normal ├──Primary: no └──Monitors: (1) └──HDMI-1 (LG Electronics 34")
user@jackson ~ % gdctl show -m Monitors: ├──Monitor HDMI-1 (LG Electronics 34") │ ├──Vendor: GSM │ ├──Product: LG ULTRAWIDE │ ├──Serial: 0x0002de64 │ └──Modes (28) │ ├──3840x2160@30.000 │ ├──3840x2160@29.970 │ ├──3840x2160@25.000 │ ├──3840x2160@24.000 │ ├──3840x2160@23.976 │ ├──2560x1440@59.951 │ ├──2560x1080@74.991 │ ├──2560x1080@59.978 │ ├──2560x1080@50.000 │ ├──1920x1080@74.986 │ ├──1920x1080@60.000 │ ├──1920x1080@59.940 │ ├──1920x1080@50.000 │ ├──1680x1050@59.883 │ ├──1600x900@60.000 │ ├──1280x1024@75.025 │ ├──1280x1024@60.020 │ ├──1280x800@59.910 │ ├──1280x720@60.000 │ ├──1280x720@59.940 │ ├──1280x720@50.000 │ ├──1152x864@59.967 │ ├──1024x768@75.029 │ ├──1024x768@60.004 │ ├──832x624@74.551 │ ├──800x600@75.000 │ ├──800x600@60.317 │ └──720x576@50.000 │ └──Preferences: │ └──Luminances: │ ├──default ⇒ 100.0 (default) (current) │ └──bt2100 ⇒ 100.0 (default) └──Monitor eDP-1 (Built-in display) [...] Logical monitors: ├──Logical monitor #1 │ ├──Position: (0, 0) │ ├──Scale: 1.25 │ ├──Transform: normal │ ├──Primary: yes │ └──Monitors: (1) │ └──eDP-1 (Built-in display) └──Logical monitor #2 ├──Position: (1536, 0) ├──Scale: 1.0 ├──Transform: normal ├──Primary: no └──Monitors: (1) └──HDMI-1 (LG Electronics 34")
So it seems as if everything is exactly the same except the listed Modes/resolutions.
Compare BIOS settings
CLOSED: [2025-10-04 Sat 14:05]
- Why? https://graz.social/@alienghic@timeloop.cafe/115203647620325001
- uh. something different about the ACPI? Not that I could find how to check or update that.
- Do they both have the same grub settings? There's some settings that can change how the kernel detects hardware.
- It seems like one system is able to detecting more information about the
- Oh did you go into the bios settings and compare them? Maybe something is set slightly differently?
What? | Working installation | Non-working installation | Notes |
---|---|---|---|
UEFI BIOS Version | N45ET25W (1.15) | same | still most current as of 2025-10-04 |
Embedded Controller Version | N45HT20W (1.11) | same | |
ME Firmware Version | 18.0.5.2155 | 18.0.15.2515 | actually, it's newer on the non-working setup |
Machine Type Model | 21LWCTO1WW | same |
- (German) Lenovo page with most current BIOS Update versions
- Intel ME Firmware should not cause this issue, I would guess.
Comparing the BIOS settings, I also got same settings for:
- Config: (everything the same)
- Network
- USB
- Keyboard/Mouse
- Display
- Power
- Beep and Alarm
- CPU
- Thunderbolt 4
- Intel AMT
- Security
- (everything the same)
Compare GRUB settings
CLOSED: [2025-10-04 Sat 14:18]
- Why? https://graz.social/@alienghic@timeloop.cafe/115203647620325001
- uh. something different about the ACPI? Not that I could find how to check or update that.
- Do they both have the same grub settings? There's some settings that can change how the kernel detects hardware.
- It seems like one system is able to detecting more information about the
- Oh did you go into the bios settings and compare them? Maybe something is set slightly differently?
The info in /etc/default/grub
was identical on both machines.
GRUB_CMDLINE_LINUX_DEFAULT="quiet"
I once tried following adaption on Cosmo:
GRUB_CMDLINE_LINUX_DEFAULT="quiet video=HDMI-1:2560x1080@60"
Unfornately, this did not help as mentioned above.
My Cry For Help
- [2025-09-14 Sun 17:41] Mastodon-thread: https://graz.social/@publicvoit/115203409039346508
Check Driver
CLOSED: [2025-10-05 Sun 17:50] SCHEDULED: <2025-09-15 Mon>
- https://graz.social/@gnomon@mastodon.social/115203465545303106
- since you're using the i915 driver instead of the xe driver per your dmesg output, what is the value of your 'enableguc' kernel parameter, and what are the specific versions of the firmware blobs at /lib/firmware/i915/mtl* ?
- I'm not sure that this is necessarily your problem but it's the first thing I would check after looking at the info you provided.
user@cosmo ~ % l /lib/firmware/i915/mtl_* -rw-r--r-- 1 root root 52712 Apr 24 18:35 /lib/firmware/i915/mtl_dmc.bin -rw-r--r-- 1 root root 1142784 Apr 24 18:35 /lib/firmware/i915/mtl_gsc_1.bin -rw-r--r-- 1 root root 312064 Apr 24 18:35 /lib/firmware/i915/mtl_guc_70.bin -rw-r--r-- 1 root root 561152 Apr 24 18:35 /lib/firmware/i915/mtl_huc_gsc.bin user@cosmo ~ %
... which is identical (file name and size) on jackson, the host where it works.
Not sure how to determine my 'enable_guc' kernel parameter:
user@cosmo /etc/modprobe.d % l total 20 drwxr-xr-x 2 root root 4096 Aug 7 19:06 . drwxr-xr-x 134 root root 12288 Sep 17 15:23 .. -rw-r--r-- 1 root root 154 May 17 06:35 intel-microcode-blacklist.conf user@cosmo /etc/modprobe.d % cat intel-microcode-blacklist.conf # The microcode module attempts to apply a microcode update when # it autoloads. This is not always safe, so we block it by default. blacklist microcode user@cosmo /etc/modprobe.d %
Ask Claude.ai
CLOSED: [2025-10-05 Sun 17:50]
I've got access to Sonnet 4.5 and Opus 4.1 from Athropic.
Here's my prompt:
I've got two Lenovo x13 2-in-1 Gen 5 with Debian 13 GNOME 48 with hostnames Cosmo and Jackson. On Cosmo, I can't select the native screen resolution for the external LG 34" TFT which is 2560x1080. In the GNOME screen configuration dialog, I may only choose a resolution (among others) that is similar but not correct: 2560x1440. On Jackson, the native screen resolution is recognized out of the box. Both machines have same: - graphics hardware - Linux driver - BIOS firmware: "UEFI BIOS Version", "Embedded Controller Version", "Machine Type Model" - BIOS settings - operating system - GRUB config with: GRUB_CMDLINE_LINUX_DEFAULT="quiet" - I also tried with no success: GRUB_CMDLINE_LINUX_DEFAULT="quiet video=eDP-1:2560x1080@30" Different is ME Firmware Version with "18.0.5.2155" on Jackson and 18.0.15.2515 on Cosmo although I think that this has no effect on the issue. Also same on both machines: ``` user@cosmo% l /lib/firmware/i915/mtl_* -rw-r--r-- 1 root root 52712 Apr 24 18:35 /lib/firmware/i915/mtl_dmc.bin -rw-r--r-- 1 root root 1142784 Apr 24 18:35 /lib/firmware/i915/mtl_gsc_1.bin -rw-r--r-- 1 root root 312064 Apr 24 18:35 /lib/firmware/i915/mtl_guc_70.bin -rw-r--r-- 1 root root 561152 Apr 24 18:35 /lib/firmware/i915/mtl_huc_gsc.bin user@cosmo
% ``` I switched the SSDs between Cosmo and Jackson and the issue with the wrong resoltion sticks with the SSD. So it's not an hardware issue. -------------------- The output of "gdctl show" is: On Cosmo: ``` Monitors: ├──Monitor HDMI-1 (LG Electronics 34") │ ├──Vendor: GSM │ ├──Product: LG ULTRAWIDE │ ├──Serial: 0x0002de64 │ ├──Current mode │ │ └──2560x1440@59.951 │ └──Preferences: │ └──Luminances: │ ├──default ⇒ 100.0 (default) (current) │ └──bt2100 ⇒ 100.0 (default) [...] Logical monitors: ├──Logical monitor #1 │ ├──Position: (2560, 480) │ ├──Scale: 1.25 │ ├──Transform: 180 │ ├──Primary: no │ └──Monitors: (1) │ └──eDP-1 (Built-in display) └──Logical monitor #2 ├──Position: (0, 0) ├──Scale: 1.0 ├──Transform: normal ├──Primary: yes └──Monitors: (1) └──HDMI-1 (LG Electronics 34") ``` On Jackson: ``` Monitors: ├──Monitor HDMI-1 (LG Electronics 34") │ ├──Vendor: GSM │ ├──Product: LG ULTRAWIDE │ ├──Serial: 0x0002de64 │ ├──Current mode │ │ └──2560x1080@59.978 │ └──Preferences: │ └──Luminances: │ ├──default ⇒ 100.0 (default) (current) │ └──bt2100 ⇒ 100.0 (default) [...] Logical monitors: ├──Logical monitor #1 │ ├──Position: (0, 0) │ ├──Scale: 1.25 │ ├──Transform: normal │ ├──Primary: yes │ └──Monitors: (1) │ └──eDP-1 (Built-in display) └──Logical monitor #2 ├──Position: (1536, 0) ├──Scale: 1.0 ├──Transform: normal ├──Primary: no └──Monitors: (1) └──HDMI-1 (LG Electronics 34") ``` -------------------- The output of "gdctl show -m": Cosmo: ``` Monitors: ├──Monitor HDMI-1 (LG Electronics 34") │ ├──Vendor: GSM │ ├──Product: LG ULTRAWIDE │ ├──Serial: 0x0002de64 │ └──Modes (23) │ ├──3840x2160@30.000 │ ├──3840x2160@29.970 │ ├──3840x2160@25.000 │ ├──3840x2160@24.000 │ ├──3840x2160@23.976 │ ├──2560x1440@59.951 │ ├──1920x1080@60.000 │ ├──1920x1080@59.940 │ ├──1920x1080@50.000 │ ├──1680x1050@59.883 │ ├──1600x900@60.000 │ ├──1280x1024@75.025 │ ├──1280x1024@60.020 │ ├──1280x800@59.910 │ ├──1280x720@60.000 │ ├──1280x720@59.940 │ ├──1280x720@50.000 │ ├──1024x768@75.029 │ ├──1024x768@60.004 │ ├──832x624@74.551 │ ├──800x600@75.000 │ ├──800x600@60.317 │ └──720x576@50.000 │ └──Preferences: [...] ``` -------------------- Jackson: ``` Monitors: ├──Monitor HDMI-1 (LG Electronics 34") │ ├──Vendor: GSM │ ├──Product: LG ULTRAWIDE │ ├──Serial: 0x0002de64 │ └──Modes (28) │ ├──3840x2160@30.000 │ ├──3840x2160@29.970 │ ├──3840x2160@25.000 │ ├──3840x2160@24.000 │ ├──3840x2160@23.976 │ ├──2560x1440@59.951 │ ├──2560x1080@74.991 │ ├──2560x1080@59.978 │ ├──2560x1080@50.000 │ ├──1920x1080@74.986 │ ├──1920x1080@60.000 │ ├──1920x1080@59.940 │ ├──1920x1080@50.000 │ ├──1680x1050@59.883 │ ├──1600x900@60.000 │ ├──1280x1024@75.025 │ ├──1280x1024@60.020 │ ├──1280x800@59.910 │ ├──1280x720@60.000 │ ├──1280x720@59.940 │ ├──1280x720@50.000 │ ├──1152x864@59.967 │ ├──1024x768@75.029 │ ├──1024x768@60.004 │ ├──832x624@74.551 │ ├──800x600@75.000 │ ├──800x600@60.317 │ └──720x576@50.000 │ └──Preferences: │ └──Luminances: │ ├──default ⇒ 100.0 (default) (current) │ └──bt2100 ⇒ 100.0 (default) └──Monitor eDP-1 (Built-in display) [...] Logical monitors: ├──Logical monitor #1 │ ├──Position: (0, 0) │ ├──Scale: 1.25 │ ├──Transform: normal │ ├──Primary: yes │ └──Monitors: (1) │ └──eDP-1 (Built-in display) └──Logical monitor #2 ├──Position: (1536, 0) ├──Scale: 1.0 ├──Transform: normal ├──Primary: no └──Monitors: (1) └──HDMI-1 (LG Electronics 34") ``` -------------------- I tried to set the resolution but that failed as well: ``` user@cosmo% gdctl set -LpM HDMI-1 --mode 2560x1080@60 Failed to create configuration: No mode 2560x1080@60 available for HDMI-1 1 user@cosmo
% ``` -------------------- "lspci -v" shows different output though: Cosmo: ``` 00:02.0 VGA compatible controller: Intel Corporation Meteor Lake-P [Intel Graphics] (rev 08) (prog-if 00 [VGA controller]) Subsystem: Lenovo Device 232a Flags: bus master, fast devsel, latency 0, IRQ 192, IOMMU group 0 Memory at 4058000000 (64-bit, prefetchable) [size=16M] Memory at 4000000000 (64-bit, prefetchable) [size=256M] Expansion ROM at 000c0000 [virtual] [disabled] [size=128K] Capabilities: [40] Vendor Specific Information: Len=0c <?> Capabilities: [70] Express Root Complex Integrated Endpoint, IntMsgNum 0 Capabilities: [ac] MSI: Enable+ Count=1/1 Maskable+ 64bit+ Capabilities: [d0] Power Management version 3 Capabilities: [100] Null Capabilities: [110] Process Address Space ID (PASID) Capabilities: [200] Address Translation Service (ATS) Capabilities: [420] Physical Resizable BAR Capabilities: [320] Single Root I/O Virtualization (SR-IOV) Capabilities: [400] Latency Tolerance Reporting Kernel driver in use: i915 Kernel modules: i915, xe ``` Jackson: ``` 00:02.0 VGA compatible controller: Intel Corporation Meteor Lake-P [Intel Graphics] (rev 08) (prog-if 00 [VGA controller]) Subsystem: Lenovo Device 232a Flags: bus master, fast devsel, latency 0, IRQ 192, IOMMU group 0 Memory at 4058000000 (64-bit, prefetchable) [size=16M] Memory at 4000000000 (64-bit, prefetchable) [size=256M] Expansion ROM at 000c0000 [virtual] [disabled] [size=128K] Capabilities: [40] Vendor Specific Information: Intel Capabilities v1 CapA: Peg60Dis- Peg12Dis- Peg11Dis- Peg10Dis- PeLWUDis- DmiWidth=x4 EccDis- ForceEccEn- VTdDis- DmiG2Dis- PegG2Dis- DDRMaxSize=Unlimited 1NDis- CDDis- DDPCDis- X2APICEn- PDCDis- IGDis- CDID=0 CRID=0 DDROCCAP+ OCEn- DDRWrtVrefEn+ DDR3LEn+ CapB: ImguDis- OCbySSKUCap- OCbySSKUEn- SMTCap- CacheSzCap 0x0 SoftBinCap- DDR3MaxFreqWithRef100=Disabled PegG3Dis- PkgTyp- AddGfxEn- AddGfxCap- PegX16Dis- DmiG3Dis- GmmDis- DDR3MaxFreq=2932MHz LPDDR3En- Capabilities: [70] Express Root Complex Integrated Endpoint, IntMsgNum 0 Capabilities: [ac] MSI: Enable+ Count=1/1 Maskable+ 64bit+ Capabilities: [d0] Power Management version 3 Capabilities: [100] Null Capabilities: [110] Process Address Space ID (PASID) Capabilities: [200] Address Translation Service (ATS) Capabilities: [420] Physical Resizable BAR Capabilities: [320] Single Root I/O Virtualization (SR-IOV) Capabilities: [400] Latency Tolerance Reporting Kernel driver in use: i915 Kernel modules: i915, xe ``` I don't know why there is a difference in this output and what to do in order to get the same "Capabilities" on both machines. Please analyse the information above carefully and tell me what I may check or change so that Cosmo gets the native screen resolution for the external TFT as well.
I had to add:
Related to your xrandr tips: Debian 13 GNOME 48 runs Wayland. I guess that xrandr and probably other mentioned X11 related stuff won't work that way.
Opus 4.1 Answer
You're absolutely right! I apologize for the X11-centric suggestions. With Wayland and GNOME 48, the approach is quite different. Let me provide Wayland-appropriate solutions:
1. Check EDID under Wayland
# Check what the kernel/DRM sees sudo cat /sys/class/drm/card*-HDMI-A-1/edid | edid-decode # or sudo cat /sys/class/drm/card*-HDMI-A-1/modes # Check current mode cat /sys/class/drm/card*-HDMI-A-1/modes | grep 2560x1080 # See what mutter/GNOME detects journalctl -b | grep -i "2560x1080" journalctl -b | grep -i edid
2. Clear GNOME/Mutter Display Cache (Wayland-specific)
# Remove GNOME's monitor configurations rm ~/.config/monitors.xml rm ~/.config/monitors.xml~ # If using GDM sudo rm /var/lib/gdm3/.config/monitors.xml sudo rm /var/lib/gdm3/.config/monitors.xml~ # Clear mutter's cache rm -rf ~/.cache/mutter/ # Restart GNOME Shell (on Wayland) # Either logout/login or: systemctl --user restart gnome-shell
3. Force Mode via Kernel/KMS
Since Wayland relies on KMS (Kernel Mode Setting), add the mode at the kernel level:
# In /etc/default/grub GRUB_CMDLINE_LINUX_DEFAULT="quiet video=HDMI-A-1:2560x1080@60" # Update and reboot sudo update-grub sudo reboot
4. Create Custom EDID
Since Jackson reads the EDID correctly, you can extract and force it on Cosmo:
On Jackson:
# Extract working EDID sudo cat /sys/class/drm/card*-HDMI-A-1/edid > ~/lg_monitor.edid # Copy this file to Cosmo
On Cosmo:
# Place the EDID file sudo mkdir -p /lib/firmware/edid sudo cp lg_monitor.edid /lib/firmware/edid/ # Force kernel to use this EDID # In /etc/default/grub GRUB_CMDLINE_LINUX_DEFAULT="quiet drm.edid_firmware=HDMI-A-1:edid/lg_monitor.edid" # Update and reboot sudo update-grub sudo reboot
5. Use Mutter Debug Settings
Create a debug configuration for mutter:
# Create mutter debug config mkdir -p ~/.config/mutter # Enable experimental features that might help with display detection gsettings set org.gnome.mutter experimental-features "['scale-monitor-framebuffer']"
6. Check Mutter/GNOME Logs
# Check what mutter sees MUTTER_DEBUG=kms journalctl -f # In another terminal, restart GNOME systemctl --user restart gnome-shell # Look for messages about available modes
7. Compare Working System Configuration
On Jackson, gather the working configuration:
# Get the exact mode timings from DRM cat /sys/class/drm/card*-HDMI-A-1/modes cat /sys/class/drm/card*-HDMI-A-1/mode # Get monitor info as seen by mutter gdbus call --session --dest org.gnome.Mutter.DisplayConfig \ --object-path /org/gnome/Mutter/DisplayConfig \ --method org.gnome.Mutter.DisplayConfig.GetCurrentState # Export current monitor.xml if it has correct config cat ~/.config/monitors.xml
8. Manual Configuration via monitors.xml
If GNOME saved a working configuration on Jackson, you can copy its ~/.config/monitors.xml
to Cosmo. Make sure to adjust any system-specific identifiers.
9. Try Forcing with gdctl
Directly
Since you mentioned gdctl
recognizes the monitor but not the mode:
# First check if the mode is detected at kernel level cat /sys/class/drm/card*-HDMI-A-1/modes | grep 2560x1080 # If it shows up there but not in gdctl, try: # Force a display reconfiguration gdctl apply
Most Likely Solution for Wayland
Given that: - The issue follows the SSD (not hardware) - Jackson shows more modes (28 vs 23) - The same monitor and cable work fine on Jackson
I'd prioritize: 1. Extracting and forcing the EDID from Jackson (#4) - this is the most reliable solution 2. Clearing all monitor configurations (#2) and letting GNOME re-detect 3. Using kernel parameters to force the mode (#3)
The EDID solution is particularly good because it completely bypasses any detection issues and forces the kernel to use the known-good EDID data from Jackson.
Trying Opus 4.1 Suggestions
4. Create Custom EDID
This resulted in a weird situation on Cosmo: desktop background image was shown on external TFT only and just in the upper right hand corner. Opened windows are not all visible. I had to revert this.
I re-tried this a second time and this time, the weird effects were gone but the wrong resolution still persisted.
1. Check EDID under Wayland
Had to install dependencies:
sudo apt install edid-decode
Then I executed:
user@jackson ~ % sudo cat /sys/class/drm/card*-HDMI-A-1/edid | edid-decode > jackson-edid-decode.log
user@jackson ~ % cat /sys/class/drm/card*-HDMI-A-1/modes | grep 2560x1080 2560x1080 2560x1080 2560x1080
user@jackson ~ % sudo journalctl -b | grep -i "2560x1080" 1 user@jackson ~ %
user@jackson ~ % sudo journalctl -b | grep -i edid Oct 05 14:21:43 jackson sudo[6209]: user : TTY=pts/1 ; PWD=/home/user ; USER=root ; COMMAND=/usr/bin/cat /sys/class/drm/card0-HDMI-A-1/edid Oct 05 14:23:31 jackson sudo[6316]: user : TTY=pts/1 ; PWD=/sys/devices/pci0000:00/0000:00:02.0/drm/card0/card0-HDMI-A-1 ; USER=root ; COMMAND=/usr/bin/cat /sys/class/drm/card0-HDMI-A-1/edid Oct 05 14:24:04 jackson sudo[6330]: user : TTY=pts/1 ; PWD=/sys/devices/pci0000:00/0000:00:02.0/drm/card0/card0-HDMI-A-1 ; USER=root ; COMMAND=/usr/bin/cat /sys/class/drm/card0-HDMI-A-1/edid Oct 05 14:24:36 jackson sudo[6340]: user : TTY=pts/1 ; PWD=/sys/devices/pci0000:00/0000:00:02.0/drm/card0/card0-HDMI-A-1 ; USER=root ; COMMAND=/usr/bin/cat /sys/class/drm/card0-HDMI-A-1/edid Oct 05 14:34:13 jackson sudo[6548]: user : TTY=pts/1 ; PWD=/sys/devices/pci0000:00/0000:00:02.0/drm/card0/card0-HDMI-A-1 ; USER=root ; COMMAND=/usr/bin/cat /sys/class/drm/card0-HDMI-A-1/edid Oct 05 14:34:34 jackson sudo[6566]: user : TTY=pts/1 ; PWD=/sys/devices/pci0000:00/0000:00:02.0/drm/card0/card0-HDMI-A-1 ; USER=root ; COMMAND=/usr/bin/apt install edid-decode Oct 05 14:34:49 jackson sudo[6726]: user : TTY=pts/1 ; PWD=/sys/devices/pci0000:00/0000:00:02.0/drm/card0/card0-HDMI-A-1 ; USER=root ; COMMAND=/usr/bin/cat /sys/class/drm/card0-HDMI-A-1/edid Oct 05 14:34:52 jackson sudo[6736]: user : TTY=pts/1 ; PWD=/sys/devices/pci0000:00/0000:00:02.0/drm/card0/card0-HDMI-A-1 ; USER=root ; COMMAND=/usr/bin/cat /sys/class/drm/card0-HDMI-A-1/edid Oct 05 14:35:50 jackson sudo[6778]: user : TTY=pts/1 ; PWD=/home/shared/shares/sting/abzulegen ; USER=root ; COMMAND=/usr/bin/cat /sys/class/drm/card0-HDMI-A-1/edid
And now compare with Cosmo:
user@cosmo ~ % cat /sys/class/drm/card*-HDMI-A-1/modes | grep 2560x1080 1 user@cosmo ~ %
user@cosmo ~ % sudo journalctl -b | grep -i "2560x1080" Oct 05 14:33:28 cosmo kernel: Command line: BOOT_IMAGE=/vmlinuz-6.12.48+deb13-amd64 root=/dev/mapper/cosmo--vg-root ro quiet video=HDMI-1:2560x1080@60 Oct 05 14:33:28 cosmo kernel: Kernel command line: BOOT_IMAGE=/vmlinuz-6.12.48+deb13-amd64 root=/dev/mapper/cosmo--vg-root ro quiet video=HDMI-1:2560x1080@60 user@cosmo ~ %
user@cosmo ~ % sudo journalctl -b | grep -i edid Oct 05 14:40:06 cosmo sudo[2787]: user : TTY=pts/0 ; PWD=/home/user ; USER=root ; COMMAND=/usr/bin/apt install edid-decode Oct 05 14:40:22 cosmo sudo[2934]: user : TTY=pts/0 ; PWD=/home/user ; USER=root ; COMMAND=/usr/bin/cat /sys/class/drm/card0-HDMI-A-1/edid user@cosmo ~ %
Well, there are differences but as it looks to my eye, this actually looks better on Cosmo, doesn't it?
Comparing the edid-decode.log
files:
user@sting ~ % diff jackson-edid-decode.log cosmo-edid-decode.log user@sting ~ %
They're same.
2. Clear GNOME/Mutter Display Cache
Situation before:
user@cosmo ~ % cat ~/.config/monitors.xml <monitors version="2"> <configuration> <layoutmode>logical</layoutmode> <logicalmonitor> <x>2560</x> <y>480</y> <scale>1.25</scale> <monitor> <monitorspec> <connector>eDP-1</connector> <vendor>AUO</vendor> <product>0x6693</product> <serial>0x00000000</serial> </monitorspec> <mode> <width>1920</width> <height>1200</height> <rate>60.026</rate> </mode> </monitor> </logicalmonitor> <logicalmonitor> <x>0</x> <y>0</y> <scale>1</scale> <primary>yes</primary> <monitor> <monitorspec> <connector>HDMI-1</connector> <vendor>GSM</vendor> <product>LG ULTRAWIDE</product> <serial>0x0002de64</serial> </monitorspec> <mode> <width>2560</width> <height>1440</height> <rate>59.951</rate> </mode> </monitor> </logicalmonitor> </configuration> </monitors> user@cosmo ~ % cat /home/user/.config/monitors.xml~ <monitors version="2"> <configuration> <layoutmode>logical</layoutmode> <logicalmonitor> <x>1920</x> <y>480</y> <scale>1.25</scale> <monitor> <monitorspec> <connector>eDP-1</connector> <vendor>AUO</vendor> <product>0x6693</product> <serial>0x00000000</serial> </monitorspec> <mode> <width>1920</width> <height>1200</height> <rate>60.026</rate> </mode> </monitor> </logicalmonitor> <logicalmonitor> <x>0</x> <y>0</y> <scale>1</scale> <primary>yes</primary> <monitor> <monitorspec> <connector>HDMI-1</connector> <vendor>GSM</vendor> <product>LG ULTRAWIDE</product> <serial>0x0002de64</serial> </monitorspec> <mode> <width>1920</width> <height>1080</height> <rate>60.000</rate> </mode> </monitor> </logicalmonitor> </configuration> </monitors> user@cosmo ~ %
No /var/lib/gdm3/.config/monitors.xm*
found:
user@cosmo ~ % sudo ls -la /var/lib/gdm3/.config/monitors.xm* zsh: no matches found: /var/lib/gdm3/.config/monitors.xm* 1 user@cosmo ~ %
OK, let's remove the files:
user@cosmo ~ % sudo rm ~/.config/monitors.x* user@cosmo ~ % sudo rm -rf ~/.cache/mutter/ user@cosmo ~ % sudo reboot
No change of the issue after reboot finishes. :-(
3. Force Mode via Kernel/KMS
Well, this is similar to what I've already tried but let's re-try this.
vim /etc/default/grub # GRUB_CMDLINE_LINUX_DEFAULT="quiet video=HDMI-A-1:2560x1080@60" # Update and reboot sudo update-grub sudo reboot
Did not fix the issue.
9. Try Forcing with gdctl
Directly
user@cosmo ~ % sudo cat /sys/class/drm/card*-HDMI-A-1/modes | grep 2560x1080 1 user@cosmo ~ %
No luck here: not detected on kernel level.
5. Use Mutter Debug Settings
I didn't try this since this should be the same on both X13 machines anyway.
7. Compare Working System Configuration
On Jackson:
user@jackson ~ % sudo cat /sys/class/drm/card*-HDMI-A-1/modes 2560x1080 3840x2160 3840x2160 3840x2160 3840x2160 3840x2160 2560x1440 2560x1080 2560x1080 1920x1080 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 user@jackson ~ % sudo cat /sys/class/drm/card*-HDMI-A-1/mode zsh: no matches found: /sys/class/drm/card*-HDMI-A-1/mode 1 user@jackson ~ %
Something's wrong with this call:
user@jackson ~ % sudo gdbus call --session --dest org.gnome.Mutter.DisplayConfig \ --object-path /org/gnome/Mutter/DisplayConfig \ --method org.gnome.Mutter.DisplayConfig.GetCurrentState Error connecting: Cannot autolaunch D-Bus without X11 $DISPLAY 1 user@jackson ~ %
Copy ~/.config/monitors.xml
On Jackson, I fetch ~/.config/monitors.xml
and copy to Cosmo.
user@cosmo ~ % mv ~/.config/monitors.xml ~/.config/monitors.xml_OLD user@cosmo ~ % mv jackson_monitors.xml ~/.config/monitors.xml user@cosmo ~ %
Reboot and test.
No change. :-(
Sending Back My Notes To Opus 4.1 And Getting Answer From Opus 4.l
Excellent debugging work! The key finding is that Cosmo doesn't detect 2560x1080 at the kernel DRM level - it's not in /sys/class/drm/card*-HDMI-A-1/modes
. This means the issue is happening before GNOME/Mutter even gets involved.
Let's focus on why the kernel isn't detecting the mode properly:
1. Compare EDID Raw Data
Since the kernel isn't seeing the 2560x1080 mode, let's compare the raw EDID data:
On both machines:
# Get raw EDID in hex sudo cat /sys/class/drm/card*-HDMI-A-1/edid | xxd > edid-raw.txt # Get decoded EDID sudo cat /sys/class/drm/card*-HDMI-A-1/edid | edid-decode > edid-decoded.txt # Get MD5 hash to quickly check if they're identical sudo cat /sys/class/drm/card*-HDMI-A-1/edid | md5sum
Compare these files between Jackson and Cosmo. If they're different, the monitor is sending different EDID data to each machine.
2. Check i915 Driver Debug Info
The kernel driver might be filtering modes for some reason:
# Check i915 parameters on both machines sudo cat /sys/module/i915/parameters/* > i915-params.txt # Enable verbose DRM debugging temporarily echo 0x1ff | sudo tee /sys/module/drm/parameters/debug # Reconnect the monitor (unplug/replug HDMI) # Then check kernel messages sudo dmesg | grep -i "2560x1080" sudo dmesg | grep -i "pruning\|reject\|filter" # Disable debug mode after echo 0 | sudo tee /sys/module/drm/parameters/debug
3. Check Display Port/HDMI Bandwidth Limits
The i915 driver might be rejecting modes due to perceived bandwidth limitations:
# Check if there are different link rates sudo cat /sys/kernel/debug/dri/0/i915_display_info | grep -A10 HDMI # Check connector status sudo cat /sys/class/drm/card*-HDMI-A-1/status sudo cat /sys/class/drm/card*-HDMI-A-1/enabled
4. Force EDID via Kernel (Different Approach)
Since the previous EDID forcing had issues, try a different method:
On Jackson:
# Save the EDID sudo cat /sys/class/drm/card*-HDMI-A-1/edid > ~/lg-good.bin # Copy to Cosmo
On Cosmo:
# Place in firmware directory sudo cp lg-good.bin /lib/firmware/edid/lg-ultrawide.bin # Use different kernel parameter syntax # In /etc/default/grub: GRUB_CMDLINE_LINUX_DEFAULT="quiet drm_kms_helper.edid_firmware=HDMI-A-1:edid/lg-ultrawide.bin video=HDMI-A-1:e" sudo update-grub sudo reboot
The =video=HDMI-A-1:e= forces the connector to be enabled.
5. Check HDMI Cable/Port Version
This is interesting - could there be a difference in HDMI capability detection?
# Check what the driver thinks about HDMI version sudo dmesg | grep -i "hdmi\|tmds" # Look for maximum pixel clock sudo cat /sys/kernel/debug/dri/*/i915_display_info | grep -i "max\|clock\|tmds"
6. Try i915 Module Options
Create /etc/modprobe.d/i915.conf
:
# Try disabling some automatic features options i915 enable_dp_mst=0 options i915 enable_psr=0 options i915 enable_fbc=0
Then rebuild initramfs:
sudo update-initramfs -u sudo reboot
7. Most Revealing Test - Boot with drm.debug
Add to GRUB for one boot:
# At boot, edit GRUB entry (press 'e' at GRUB menu) # Add to kernel line: drm.debug=0x1e log_buf_len=16M # Boot and immediately after login, save the log: sudo dmesg > /tmp/drm-debug.log # Search for why 2560x1080 is rejected: grep -C5 "2560x1080\|2560 x 1080" /tmp/drm-debug.log grep -C5 "pruning\|removing\|reject" /tmp/drm-debug.log
Most Likely Cause
Given that: - The kernel doesn't see 2560x1080 in available modes - The same hardware with Jackson's SSD works fine - The GRUB parameter =video=HDMI-A-1:2560x1080@60= doesn't help
This points to either: 1. Different EDID being received (monitor sending different data) 2. i915 driver filtering the mode due to some configuration 3. A stored bad EDID somewhere that persists across reboots
The raw EDID comparison (#1) will tell us definitively if the monitor is sending different data. The debug output (#7) will show why the kernel is rejecting the mode if the EDID is the same.
Trying Opus 4.1 Suggestions Again
OK, so Opus thinks that with the additional information, the issue does not involve Wayland/Mutter. So let's do that.
1. Compare EDID Raw Data
Requires:
sudo apt install xxd
user@cosmo ~ % sudo cat /sys/class/drm/card*-HDMI-A-1/edid | xxd > ~/share/sting/abzulegen/cosmo-edid-raw.txt user@cosmo ~ % sudo cat /sys/class/drm/card*-HDMI-A-1/edid | edid-decode > ~/share/sting/abzulegen/cosmo-edid-decoded.txt user@cosmo ~ % sudo cat /sys/class/drm/card*-HDMI-A-1/edid | md5sum > ~/share/sting/abzulegen/cosmo-edid-md5sum.txt user@cosmo ~ %
user@jackson ~ % sudo cat /sys/class/drm/card*-HDMI-A-1/edid | xxd > ~/share/sting/abzulegen/jackson-edid-raw.txt user@jackson ~ % sudo cat /sys/class/drm/card*-HDMI-A-1/edid | edid-decode > ~/share/sting/abzulegen/jackson-edid-decoded.txt user@jackson ~ % sudo cat /sys/class/drm/card*-HDMI-A-1/edid | md5sum > ~/share/sting/abzulegen/jackson-edid-md5sum.txt
Comparing:
user@sting ~/share/business/abzulegen % diff jackson-edid-raw.txt ~/share/user/abzulegen/cosmo-edid-raw.txt user@sting ~/share/business/abzulegen % diff jackson-edid-decoded.txt ~/share/user/abzulegen/cosmo-edid-decoded.txt user@sting ~/share/business/abzulegen % diff jackson-edid-md5sum.txt ~/share/user/abzulegen/cosmo-edid-md5sum.txt user@sting ~/share/business/abzulegen %
... they are the same on both machines.
2. Check i915 Driver Debug Info
user@cosmo ~ % sudo cat /sys/module/i915/parameters/* > ~/share/sting/abzulegen/cosmo-i915-parameters.log user@cosmo ~
user@jackson ~ % sudo cat /sys/module/i915/parameters/* > ~/share/sting/abzulegen/jackson-i915-parameters.log user@jackson ~ %
Comparing:
user@sting ~/share/business/abzulegen % diff jackson-i915-parameters.log ~/share/user/abzulegen/cosmo-i915-parameters.log 6c6 < -1 --- > N 1 user@sting ~/share/business/abzulegen %
Yes, there are differences.
3. Check Display Port/HDMI Bandwidth Limits
user@cosmo ~ % sudo cat /sys/kernel/debug/dri/0/i915_display_info | grep -A10 HDMI [CONNECTOR:250:HDMI-A-1]: status: connected physical dimensions: 800x340mm subpixel order: Unknown CEA rev: 3 audio support: yes HDCP version: HDCP1.4 HDCP2.2 max bpc: 12 modes: "3840x2160": 30 297000 3840 4016 4104 4400 2160 2168 2178 2250 0x40 0x5 "3840x2160": 30 296703 3840 4016 4104 4400 2160 2168 2178 2250 0x40 0x5 "3840x2160": 25 297000 3840 4896 4984 5280 2160 2168 2178 2250 0x40 0x5 user@cosmo ~ % sudo cat /sys/kernel/debug/dri/0/i915_display_info | grep -A10 HDMI > ~/share/sting/abzulegen/cosmo--link-rates.log user@cosmo ~ %
user@jackson ~ % sudo cat /sys/kernel/debug/dri/0/i915_display_info | grep -A10 HDMI [CONNECTOR:271:HDMI-A-1] [PLANE:90:plane 1B]: type=PRI uapi: [FB:323] XR30 little-endian (0x30335258),0x10000000000000f,2560x1080, visible=visible, src=2560.000000x1080.000000+0.000000+0.000000, dst=2560x1080+0+0, rotation=0 (0x00000001) hw: [FB:323] XR30 little-endian (0x30335258),0x10000000000000f,2560x1080, visible=yes, src=2560.000000x1080.000000+0.000000+0.000000, dst=2560x1080+0+0, rotation=0 (0x00000001) [PLANE:100:plane 2B]: type=OVL uapi: [FB:0] n/a,0x0,0x0,, visible=hidden, src=0.000000x0.000000+0.000000+0.000000, dst=0x0+0+0, rotation=0 (0x00000001) [PLANE:110:plane 3B]: type=OVL uapi: [FB:0] n/a,0x0,0x0,, visible=hidden, src=0.000000x0.000000+0.000000+0.000000, dst=0x0+0+0, rotation=0 (0x00000001) [PLANE:120:plane 4B]: type=OVL uapi: [FB:0] n/a,0x0,0x0,, visible=hidden, src=0.000000x0.000000+0.000000+0.000000, dst=0x0+0+0, rotation=0 (0x00000001) [PLANE:130:plane 5B]: type=OVL -- [CONNECTOR:271:HDMI-A-1]: status: connected physical dimensions: 800x340mm subpixel order: Unknown CEA rev: 3 audio support: yes HDCP version: HDCP1.4 HDCP2.2 max bpc: 12 modes: "2560x1080": 60 181250 2560 2608 2640 2720 1080 1083 1093 1111 0x48 0x9 "3840x2160": 30 297000 3840 4016 4104 4400 2160 2168 2178 2250 0x40 0x5 "3840x2160": 30 296703 3840 4016 4104 4400 2160 2168 2178 2250 0x40 0x5 user@jackson ~ % sudo cat /sys/kernel/debug/dri/0/i915_display_info | grep -A10 HDMI > ~/share/sting/abzulegen/jackson-link-rates.log user@jackson ~ %
Oh, there are differences!
4. Force EDID via Kernel (Different Approach)
user@jackson ~ % sudo cat /sys/class/drm/card*-HDMI-A-1/edid > ~/share/sting/abzulegen/jackson-lg-good.bin
Apply on Cosmo:
user@cosmo ~ % sudo cp ~/share/sting/abzulegen/jackson-lg-good.bin /lib/firmware/edid/lg-ultrawide.bin user@cosmo ~ %
# Use different kernel parameter syntax # In /etc/default/grub: GRUB_CMDLINE_LINUX_DEFAULT="quiet drm_kms_helper.edid_firmware=HDMI-A-1:edid/lg-ultrawide.bin video=HDMI-A-1:e" sudo update-grub sudo reboot
This resulted in showing 1024x768 on the external TFT which was labeled as "Unknown" in GNOME display settings. No higher resolution was available.
I reverted those changes again.
5. Check HDMI Cable/Port Version
user@cosmo ~ % sudo dmesg | grep -i "hdmi\|tmds" [ 28.446711] skl_hda_dsp_generic skl_hda_dsp_generic: hda_dsp_hdmi_build_controls: no PCM in topology for HDMI converter 3 [ 28.463438] input: sof-hda-dsp HDMI/DP,pcm=3 as /devices/pci0000:00/0000:00:1f.3/skl_hda_dsp_generic/sound/card0/input31 [ 28.463470] input: sof-hda-dsp HDMI/DP,pcm=4 as /devices/pci0000:00/0000:00:1f.3/skl_hda_dsp_generic/sound/card0/input32 [ 28.463499] input: sof-hda-dsp HDMI/DP,pcm=5 as /devices/pci0000:00/0000:00:1f.3/skl_hda_dsp_generic/sound/card0/input33 user@cosmo ~ % sudo cat /sys/kernel/debug/dri/*/i915_display_info | grep -i "max\|clock\|tmds" zsh: no matches found: /sys/kernel/debug/dri/*/i915_display_info user@cosmo ~ % sudo find /sys/kernel/debug -name 'i915_display_info' /sys/kernel/debug/dri/0000:00:02.0/i915_display_info 1 user@cosmo ~ % sudo cat /sys/kernel/debug/dri/0000:00:02.0/i915_display_info | grep -i "max\|clock\|tmds" max bpc: 8 max bpc: 12 user@cosmo ~ %
user@jackson ~ % sudo dmesg | grep -i "hdmi\|tmds" [ 12.490709] skl_hda_dsp_generic skl_hda_dsp_generic: hda_dsp_hdmi_build_controls: no PCM in topology for HDMI converter 3 [ 12.507576] input: sof-hda-dsp HDMI/DP,pcm=3 as /devices/pci0000:00/0000:00:1f.3/skl_hda_dsp_generic/sound/card0/input26 [ 12.507615] input: sof-hda-dsp HDMI/DP,pcm=4 as /devices/pci0000:00/0000:00:1f.3/skl_hda_dsp_generic/sound/card0/input27 [ 12.507652] input: sof-hda-dsp HDMI/DP,pcm=5 as /devices/pci0000:00/0000:00:1f.3/skl_hda_dsp_generic/sound/card0/input28 user@jackson ~ % sudo cat /sys/kernel/debug/dri/0000:00:02.0/i915_display_info | grep -i "max\|clock\|tmds" port_clock=0, lane_count=0 port_clock=0, lane_count=0 port_clock=0, lane_count=0 port_clock=0, lane_count=0 max bpc: 8 max bpc: 12 user@jackson ~ %
There are differences but I don't know what this means.
6. Try i915 Module Options
user@cosmo ~ % l /etc/modprobe.d/i915.conf ls: cannot access '/etc/modprobe.d/i915.conf': No such file or directory 2 user@cosmo ~ %
So the config file does not exist on both machines. I will skip this because there doesn't seem to be any difference with respect to those options.
7. Most Revealing Test - Boot with drm.debug
I'm not sure if I was able to add the kernel line:
drm.debug=0x1e log_buf_len=16M
user@sting ~/share/user/abzulegen % grep -C5 "2560x1080\|2560" cosmo-dmesg 1 user@sting ~/share/user/abzulegen % grep -C5 "pruning\|removing\|reject" cosmo-dmesg 1 user@sting ~/share/user/abzulegen %
No match for that.
Sending Back My Notes To Opus 4.1 And Getting Answer From Opus 4.l
Excellent detective work! The smoking gun is in the i915_display_info output. On Jackson, it shows:
"2560x1080": 60 181250 2560 2608 2640 2720 1080 1083 1093 1111 0x48 0x9
But on Cosmo, this mode is completely missing from the kernel's mode list, even though the EDID data is identical!
This means the i915 driver on Cosmo is rejecting/filtering the 2560x1080 mode for some reason.
The Critical Difference Found
Looking at the i915 parameters comparison:
< -1 --- > N
This suggests there's a parameter difference. Let's investigate this more carefully:
1. Compare i915 Parameters Properly
# On both machines, get a more readable comparison: for param in /sys/module/i915/parameters/*; do echo "$(basename $param): $(cat $param)" done | sort > ~/i915-params-sorted.txt
Compare these files to see which specific parameter differs.
2. Try the Nuclear Reset for i915
Since the EDID is the same but the driver behaves differently, let's reset the i915 driver state:
# On Cosmo, completely reset i915 module parameters sudo rm -f /etc/modprobe.d/i915* sudo rm -f /etc/modprobe.d/*i915* # Check if there are any kernel command line i915 parameters cat /proc/cmdline | grep i915 # Remove any i915 state files sudo rm -rf /var/cache/*i915* sudo rm -rf /var/lib/*i915*
3. Force Mode Addition via i915 Debugfs
Since we know the exact modeline from Jackson, let's try to force it through debugfs:
# First, check current state sudo cat /sys/kernel/debug/dri/0/i915_display_info | grep -A20 "HDMI-A-1" # Try to force the mode (this is a long shot but worth trying) echo "2560x1080@60" | sudo tee /sys/class/drm/card0-HDMI-A-1/mode
4. Compare Kernel Versions and i915 Driver Versions
# On both machines uname -a modinfo i915 | head -20 dmesg | grep -i "i915.*firmware"
5. The Real Debug - Why i915 Rejects the Mode
We need better debugging. Let's try again with more specific debug flags:
# Add to /etc/default/grub on Cosmo: GRUB_CMDLINE_LINUX_DEFAULT="quiet drm.debug=0x1ff i915.verbose_state_checks=1 log_buf_len=16M" sudo update-grub sudo reboot # After reboot, immediately: sudo dmesg > /tmp/full-debug.log # Look for mode validation grep -i "mode\|2560\|1080\|valid\|reject\|prune\|filter" /tmp/full-debug.log > /tmp/mode-debug.log # Look for HDMI specific issues grep -i "hdmi\|tmds\|clock\|bandwidth" /tmp/full-debug.log > /tmp/hdmi-debug.log
6. Check for BIOS/UEFI Display Settings
Even though you mentioned BIOS settings are the same, double-check: - Look for any display-related settings like "HDMI Max Resolution" - Check for "Display Pre-allocation" or "DVMT" settings - Look for "IGD" or "Graphics" settings
7. Try Different i915 Enable Mode
Create /etc/modprobe.d/i915-test.conf
on Cosmo:
# Force enable all outputs options i915 enable_dc=-1 options i915 enable_dp_mst=1 options i915 enable_hdcp=1 options i915 force_probe=!xe
Then:
sudo update-initramfs -u sudo reboot
8. Most Important - Detailed Parameter Comparison
Since we found a difference in the parameters, let's see the actual values:
# On Cosmo echo "=== Cosmo i915 Parameters ===" > ~/cosmo-i915-detailed.txt for p in /sys/module/i915/parameters/*; do echo "$p: $(cat $p 2>/dev/null || echo 'ERROR')" >> ~/cosmo-i915-detailed.txt done # On Jackson echo "=== Jackson i915 Parameters ===" > ~/jackson-i915-detailed.txt for p in /sys/module/i915/parameters/*; do echo "$p: $(cat $p 2>/dev/null || echo 'ERROR')" >> ~/jackson-i915-detailed.txt done
The Mystery
The fact that: 1. Same EDID data 2. Same hardware 3. Different modes detected by kernel
Points to either: - A different i915 module parameter (most likely given your finding) - A different kernel/driver version - Some persistent state that survives reboots
The parameter difference you found (-1
vs N
) is the key. We need to identify which parameter this is and correct it.
Trying Opus 4.1 Suggestions Again
OK, so Opus thinks that it narrowed down the issue further. Let's go with its flow.
1. Compare i915 Parameters Properly
user@cosmo ~ % sudo bash root@cosmo:/home/user# for param in /sys/module/i915/parameters/*; do echo "$(basename $param): $(cat $param)"; done | sort > ~user/share/sting/abzulegen/cosmo-i915-parameters-sorted.log root@cosmo:/home/user#
user@jackson ~ % sudo bash [sudo] password for user: root@jackson:/home/user# for param in /sys/module/i915/parameters/*; do echo "$(basename $param): $(cat $param)"; done | sort > ~user/share/sting/abzulegen/jackson-i915-parameters-sorted.log root@jackson:/home/user#
user@sting ~/share/user/abzulegen % diff cosmo-i915-parameters-sorted.log ~/share/business/abzulegen/jackson-i915-parameters-sorted.log 6c6 < enable_dmc_wl: N --- > enable_dmc_wl: -1 1 user@sting ~/share/user/abzulegen %
So this is the different setting: on cosmo, this is "N". On jackson, this is "-1".
Could this be the source of the issue?
Sending Back My Notes To Opus 4.1 And Getting Answer From Opus 4.l
YES! This could absolutely be the source of the issue! The enable_dmc_wl
parameter controls Display Microcontroller (DMC) workarounds/features, and this difference is very significant.
The values mean:
-1
= auto/default (let the driver decide)N
= disabled/no
This parameter affects display power management and mode detection. The fact that Jackson (working) has -1
and Cosmo (broken) has N
is highly suspicious.
Fix This Immediately
Option 1: Runtime change (temporary test):
# On Cosmo, as root: echo -1 | sudo tee /sys/module/i915/parameters/enable_dmc_wl # Then unplug and replug the HDMI cable # Check if 2560x1080 appears: cat /sys/class/drm/card*-HDMI-A-1/modes | grep 2560x1080
Option 2: Make it permanent:
# Create/edit /etc/modprobe.d/i915.conf on Cosmo: echo "options i915 enable_dmc_wl=-1" | sudo tee /etc/modprobe.d/i915.conf # Rebuild initramfs sudo update-initramfs -u # Reboot sudo reboot
Why This Matters
The DMC (Display Microcontroller) in Intel graphics handles: - Display power states - Mode detection and validation - Display timing generation
When enable_dmc_wl
is set to N
(disabled), it can cause: - Missing display modes - Incorrect EDID parsing - Problems with certain resolutions
How Did This Happen?
Check where this setting comes from on Cosmo:
# Check for any configs that might set this grep -r "enable_dmc_wl" /etc/modprobe.d/ grep -r "enable_dmc_wl" /etc/default/ grep "enable_dmc_wl" /proc/cmdline
This setting might have been added by: - A previous troubleshooting attempt - A package/driver update - A system configuration tool
Verify the Fix
After changing the parameter and rebooting:
# Confirm the parameter is set correctly cat /sys/module/i915/parameters/enable_dmc_wl # Should show -1 # Check available modes cat /sys/class/drm/card*-HDMI-A-1/modes | grep 2560x1080 # Use gdctl to see if the mode is available gdctl show -m | grep 2560x1080
This is very likely the root cause. The DMC workaround being disabled on Cosmo is preventing proper mode detection for your ultrawide monitor!
Trying Opus 4.1 Suggestions Again
How can I set the property?
user@cosmo ~ % echo -1 | sudo tee /sys/module/i915/parameters/enable_dmc_wl tee: /sys/module/i915/parameters/enable_dmc_wl: Permission denied -1 1 user@cosmo ~ % sudo echo -1 > /sys/module/i915/parameters/enable_dmc_wl zsh: permission denied: /sys/module/i915/parameters/enable_dmc_wl 1 user@cosmo ~ %
OK, this seems to be read-only.
Let's do the permanent fix.
echo "options i915 enable_dmc_wl=-1" | sudo tee /etc/modprobe.d/i915.conf sudo update-initramfs -u sudo reboot
Now, the external TFT is not recognized at all! Furthermore, the GNOME panel is not shown as before. Instead, it looks like the default of the GNOME extension I've installed.
While checking the parameter, I realized that the whole sub-hierarchie is missing:
user@cosmo ~ % sudo ls -la /sys/module/i915/ ls: cannot access '/sys/module/i915/': No such file or directory 2 user@cosmo ~ %
Checking the reasons:
user@cosmo ~ % sudo grep -r "enable_dmc_wl" /etc/modprobe.d/ /etc/modprobe.d/i915.conf:options i915 enable_dmc_wl=-1 user@cosmo ~ % sudo grep -r "enable_dmc_wl" /etc/default/ 1 user@cosmo ~ % sudo grep "enable_dmc_wl" /proc/cmdline 1 user@cosmo ~ %
OK, I do the alternative version using kernel command line.
I revert the change:
user@cosmo ~ % sudo rm /etc/modprobe.d/i915.conf user@cosmo ~ % sudo update-initramfs -u
# Edit /etc/default/grub sudo nano /etc/default/grub # Add to GRUB_CMDLINE_LINUX_DEFAULT: GRUB_CMDLINE_LINUX_DEFAULT="quiet i915.enable_dmc_wl=-1" # Update grub sudo update-grub # Reboot sudo reboot
Again: the external TFT is not recognized at all. Furthermore, the GNOME panel is not shown as before. Instead, it looks like the default of the GNOME extension I've installed.
It looks as if parts of GNOME aren't startet. The keyring doesn't ask for its passphrase.
Sending Back My Notes To Opus 4.1 And Getting Answer From Opus 4.l
Oh no! The i915 module is failing to load entirely! This is a critical issue - the parameter value might be invalid or causing a conflict. Let's fix this immediately:
Emergency Fix - Get Display Working Again
# Remove the problematic kernel parameter sudo nano /etc/default/grub # Change back to just: GRUB_CMDLINE_LINUX_DEFAULT="quiet" # Update grub sudo update-grub # Ensure no modprobe config remains sudo rm -f /etc/modprobe.d/i915.conf # Rebuild initramfs sudo update-initramfs -u # Reboot sudo reboot
After Getting Display Back
Once your display is working again, let's investigate why this parameter causes the module to fail:
# Check if i915 is loaded lsmod | grep i915 # Check for driver errors sudo dmesg | grep -i "i915\|error\|fail" # Check the actual parameter syntax on Jackson cat /sys/module/i915/parameters/enable_dmc_wl
Important Discovery
The fact that setting enable_dmc_wl
-1= causes the i915 module to fail to load entirely suggests:
- This parameter might not exist in your kernel version
- The syntax might be different
- There might be a different underlying issue
Let's Check Kernel and Driver Versions
On both machines:
# Kernel version uname -r # i915 driver info modinfo i915 | grep -E "version|filename" # Check if the parameter even exists ls /sys/module/i915/parameters/ | grep dmc
Alternative Theory
The parameter difference might be a symptom, not the cause. The real issue might be:
- Different kernel versions between the systems
- Different firmware files
- A corrupted driver state on Cosmo
Check for Firmware Differences
# On both machines ls -la /lib/firmware/i915/ | grep -i dmc md5sum /lib/firmware/i915/*dmc*
Safe Test Approach
Once you have your display back, let's try a safer approach:
# First, check what parameters actually exist ls /sys/module/i915/parameters/ # Try setting a different, safer parameter echo "options i915 enable_psr=0" | sudo tee /etc/modprobe.d/i915-test.conf sudo update-initramfs -u
The fact that the i915 module completely fails to load with that parameter is very revealing - it suggests the parameter might not be valid for your kernel version, or there's something else going on. Let's get your system working first, then investigate more carefully.
Trying Opus 4.1 Suggestions Again
I already reverted the changes and got the original setup back. So no further rollback necessary.
Let's jump in to the fix:
Let's Check Kernel and Driver Versions
user@cosmo ~ % uname -r 6.12.48+deb13-amd64 user@cosmo ~ %
user@jackson ~ % uname -r 6.16.9+deb14-amd64 user@jackson ~ %
Wow, there's a different kernel! :-O
Comparing the modinfo
:
user@cosmo ~ % sudo modinfo i915 | grep -E "version|filename" filename: /lib/modules/6.12.48+deb13-amd64/kernel/drivers/gpu/drm/i915/i915.ko.xz vermagic: 6.12.48+deb13-amd64 SMP preempt mod_unload modversions parm: invert_brightness:Invert backlight brightness (-1 force normal, 0 machine defaults, 1 force inversion), please report PCI device ID, subsystem vendor and subsystem device ID to dri-devel@lists.freedesktop.org, if your machine needs it. It will then be included in an upcoming module version. (int) user@cosmo ~ %
user@jackson ~ % sudo modinfo i915 | grep -E "version|filename" filename: /lib/modules/6.16.9+deb14-amd64/kernel/drivers/gpu/drm/i915/i915.ko.xz vermagic: 6.16.9+deb14-amd64 SMP preempt mod_unload modversions parm: invert_brightness:Invert backlight brightness (-1 force normal, 0 machine defaults, 1 force inversion), please report PCI device ID, subsystem vendor and subsystem device ID to dri-devel@lists.freedesktop.org, if your machine needs it. It will then be included in an upcoming module version. (int) user@jackson ~ %
Yes, there are difference.
Comparing the parameters:
user@cosmo ~ % ls /sys/module/i915/parameters/ | grep dmc dmc_firmware_path enable_dmc_wl user@cosmo ~ %
user@jackson ~ % ls /sys/module/i915/parameters/ | grep dmc dmc_firmware_path enable_psr2_sel_fetch memtest enable_dmc_wl force_probe modeset user@jackson ~ %
Also some differences.
Weird, I set up both machines using the Debian 13 defaults without any manual package/kernel overrides. Must have been happened by mistake or via dependencies I'm not aware of.
So how to fix that?
I should have checked the kernel earlier. :-(
Getting the Newer Kernel on Cosmo
user@jackson ~ % apt policy linux-image-6.16.9+deb14-amd64 linux-image-6.16.9+deb14-amd64: Installed: 6.16.9-1 Candidate: 6.16.9-1 Version table: *** 6.16.9-1 500 500 http://deb.debian.org/debian unstable/main amd64 Packages 100 /var/lib/dpkg/status user@jackson ~ %
OK, jackson has its kernel from unstable. For whatever reason.
Jackson has no /etc/apt/apt.conf.d/99defaultrelease
file. → I needed some packages from sid/testing and this must have gone wrong somehow.
I now set the default release to "trixie" on both machines:
echo 'APT::Default-Release "trixie";' | sudo tee /etc/apt/apt.conf.d/99defaultrelease
On Cosmo, I add unstable sources:
echo "deb http://deb.debian.org/debian testing main contrib non-free-firmware" | sudo tee /etc/apt/sources.list.d/testing.list
After sudo apt update
:
[...] 41 packages can be upgraded. Run 'apt list --upgradable' to see them. user@cosmo ~ % sudo apt list --upgradable cups-bsd/testing 2.4.10-4 amd64 [upgradable from: 2.4.10-3+deb13u1] cups-client/testing 2.4.10-4 amd64 [upgradable from: 2.4.10-3+deb13u1] cups-common/testing 2.4.10-4 all [upgradable from: 2.4.10-3+deb13u1] cups-core-drivers/testing 2.4.10-4 amd64 [upgradable from: 2.4.10-3+deb13u1] cups-daemon/testing 2.4.10-4 amd64 [upgradable from: 2.4.10-3+deb13u1] cups-ipp-utils/testing 2.4.10-4 amd64 [upgradable from: 2.4.10-3+deb13u1] cups-ppdc/testing 2.4.10-4 amd64 [upgradable from: 2.4.10-3+deb13u1] cups-server-common/testing 2.4.10-4 all [upgradable from: 2.4.10-3+deb13u1] cups/testing 2.4.10-4 amd64 [upgradable from: 2.4.10-3+deb13u1] firefox-esr/testing 140.3.1esr-2 amd64 [upgradable from: 140.3.1esr-1~deb13u1] imagemagick-7-common/testing 8:7.1.2.3+dfsg1-1 all [upgradable from: 8:7.1.1.43+dfsg1-1+deb13u2] imagemagick-7.q16/testing 8:7.1.2.3+dfsg1-1 amd64 [upgradable from: 8:7.1.1.43+dfsg1-1+deb13u2] imagemagick/testing 8:7.1.2.3+dfsg1-1 amd64 [upgradable from: 8:7.1.1.43+dfsg1-1+deb13u2] libavcodec61/testing 7:7.1.2-1+b1 amd64 [upgradable from: 7:7.1.2-0+deb13u1] libavfilter10/testing 7:7.1.2-1+b1 amd64 [upgradable from: 7:7.1.2-0+deb13u1] libavformat61/testing 7:7.1.2-1+b1 amd64 [upgradable from: 7:7.1.2-0+deb13u1] libavutil59/testing 7:7.1.2-1+b1 amd64 [upgradable from: 7:7.1.2-0+deb13u1] libcups2t64/testing 2.4.10-4 amd64 [upgradable from: 2.4.10-3+deb13u1] libjson-xs-perl/testing 4.040-1 amd64 [upgradable from: 4.040-1~deb13u1] libmagickcore-7.q16-10-extra/testing 8:7.1.2.3+dfsg1-1 amd64 [upgradable from: 8:7.1.1.43+dfsg1-1+deb13u2] libmagickcore-7.q16-10/testing 8:7.1.2.3+dfsg1-1 amd64 [upgradable from: 8:7.1.1.43+dfsg1-1+deb13u2] libmagickwand-7.q16-10/testing 8:7.1.2.3+dfsg1-1 amd64 [upgradable from: 8:7.1.1.43+dfsg1-1+deb13u2] libnss-myhostname/testing 258-1 amd64 [upgradable from: 257.8-1~deb13u2] libnss-systemd/testing 258-1 amd64 [upgradable from: 257.8-1~deb13u2] libpam-systemd/testing 258-1 amd64 [upgradable from: 257.8-1~deb13u2] libpostproc58/testing 7:7.1.2-1+b1 amd64 [upgradable from: 7:7.1.2-0+deb13u1] libssl3t64/testing 3.5.4-1 amd64 [upgradable from: 3.5.1-1+deb13u1] libswresample5/testing 7:7.1.2-1+b1 amd64 [upgradable from: 7:7.1.2-0+deb13u1] libswscale8/testing 7:7.1.2-1+b1 amd64 [upgradable from: 7:7.1.2-0+deb13u1] libsystemd-shared/testing 258-1 amd64 [upgradable from: 257.8-1~deb13u2] libsystemd0/testing 258-1 amd64 [upgradable from: 257.8-1~deb13u2] libudev1/testing 258-1 amd64 [upgradable from: 257.8-1~deb13u2] libxslt1.1/testing 1.1.43-0.2 amd64 [upgradable from: 1.1.35-1.2+deb13u2] linux-image-amd64/testing 6.16.9-1 amd64 [upgradable from: 6.12.48-1] openssl-provider-legacy/testing 3.5.4-1 amd64 [upgradable from: 3.5.1-1+deb13u1] openssl/testing 3.5.4-1 amd64 [upgradable from: 3.5.1-1+deb13u1] systemd-cryptsetup/testing 258-1 amd64 [upgradable from: 257.8-1~deb13u2] systemd-sysv/testing 258-1 amd64 [upgradable from: 257.8-1~deb13u2] systemd-timesyncd/testing 258-1 amd64 [upgradable from: 257.8-1~deb13u2] systemd/testing 258-1 amd64 [upgradable from: 257.8-1~deb13u2] udev/testing 258-1 amd64 [upgradable from: 257.8-1~deb13u2] user@cosmo ~ %
This defaultrelease settings doesn't seem to have much influence.
So how to keep trixie/stable as the default for all packages except those who are installed with "-t sid" or similar?
Set APT Pinning for Extra Safety: To ensure packages don't accidentally get pulled from unstable, create /etc/apt/preferences.d/priority
(file did not exist on both hosts):
cat << 'EOF' | sudo tee /etc/apt/preferences.d/priority Package: * Pin: release a=stable Pin-Priority: 900 Package: * Pin: release a=trixie Pin-Priority: 900 Package: * Pin: release a=unstable Pin-Priority: 100 Package: linux-image-* linux-headers-* Pin: release a=unstable Pin-Priority: 500 EOF
Still got packages from unstable or testing when I do sudo apt upgrade --dry-run
→ this is a separate issue.