DisplayID checksum validation blocking hardware capabilities - CSO T3 panel

DisplayID checksum validation blocking hardware capabilities - CSO T3 panel

[Tiago Martins Araújo]

[-- Attachment #1: Type: text/plain, Size: 9027 bytes --]

Hello DRM maintainers and community,

I'm reporting a hardware compatibility issue where DisplayID checksum
validation failures prevent access to a panel's full capabilities. I'm
seeking guidance on the appropriate approach to handle this type of issue.

Problem Summary
===============

A CSO T3 eDP display panel (Model: MNE007ZA1-5) with 2880x1800 resolution
cannot access its 120Hz refresh rate capability due to DisplayID checksum
validation failures in the kernel. The validation code treats checksum
mismatches as fatal errors, completely blocking DisplayID functionality.

Steps to Reproduce
==================

1. Boot system with CSO T3 eDP panel (MNE007ZA1-5)
2. Observe kernel logs during amdgpu initialization
3. Check available display modes via standard tools
4. Attempt to access 120Hz mode

Expected vs Actual Behavior
===========================

Expected: Panel should provide access to its full capabilities including
120Hz mode
Actual: Only basic display modes available, 120Hz blocked by validation
failures

System Information
==================

Hardware Configuration:
- Panel: CSO T3 (MNE007ZA1-5), 2880x1800 eDP
- Graphics: AMD Ryzen 7 7840HS with Radeon 780M [1002:15bf]
- System: Lenovo laptop with integrated display

Software Configuration:
- Kernel: Linux 6.17.0-rc5
- Distribution: Fedora Linux 42 (Workstation Edition)
- Display Server: Wayland with GNOME Shell 48.4
- Graphics Driver: amdgpu (built-in)

Problem Evidence - Kernel Logs
===============================

During system boot, repeated DisplayID checksum validation failures occur:

    [    4.741506] [drm] DisplayID checksum invalid, remainder is 248
    [    4.741512] [drm] DisplayID checksum invalid, remainder is 248
    [    4.741514] [drm] DisplayID checksum invalid, remainder is 248
    [    4.741515] [drm] DisplayID checksum invalid, remainder is 248
    [    4.741517] [drm] DisplayID checksum invalid, remainder is 248
    [... pattern repeats 40+ times during amdgpu initialization ...]

Failure Characteristics:
- Frequency: 40+ occurrences per boot
- Timing: During amdgpu driver initialization (~4.74s timeframe)
- Consistency: Always "remainder is 248"
- Impact: Each failure blocks DisplayID processing
- Result: Higher refresh rates unavailable

Hardware Analysis
=================

Complete EDID Data:

00000000  00 ff ff ff ff ff ff 00  36 74 5a 09 00 00 00 00
 |........6tZ.....|
00000010  00 21 01 04 b5 22 16 78  03 ee 95 a3 54 4c 99 26
 |.!...".x....TL.&|
00000020  0f 50 54 00 00 00 01 01  01 01 01 01 01 01 01 01
 |.PT.............|
00000030  01 01 01 01 01 01 40 e7  00 6a a0 a0 67 50 08 98
 |......@..j..gP..|
00000040  08 00 58 d7 10 00 00 18  00 00 00 fd 00 30 78 87
 |..X..........0x.|
00000050  87 3c 01 0a 20 20 20 20  20 20 00 00 00 fe 00 43  |.<..
 .....C|
00000060  53 4f 54 33 0a 20 20 20  20 20 20 20 00 00 00 fe  |SOT3.
....|
00000070  00 4d 4e 45 30 30 37 5a  41 31 2d 35 0a 20 01 98  |.MNE007ZA1-5.
..|
00000080  70 13 79 00 00 03 01 14  9a 0f 01 05 3f 0b 9f 00
 |p.y.........?...|
00000090  2f 00 1f 00 07 07 69 00  02 00 05 00 00 00 00 00
 |/.....i.........|
00000100  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00
 |................|
00000110  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00
 |................|
00000120  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00
 |................|
00000130  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00
 |................|
00000140  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00
 |................|
00000150  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00
 |................|
00000160  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00
 |................|
00000170  00 00 00 00 00 00 00 00  00 00 00 00 00 00 f0 98
 |................|

EDID Structure Analysis:

Base EDID Block (0x00-0x7F): Standard monitor information
  - Manufacturer: CSO (China Star Optoelectronics) - ID: 0x3674
  - Product Code: 0x095A (MNE007ZA1-5)
  - Panel Size: 34cm x 22cm (15.6" diagonal, 2880x1800)
  - Refresh Rate: 120Hz capability indicated

DisplayID Extension Block (0x80-0xFF): Extended capabilities
  - Extension Tag: 0x70 (DisplayID)
  - DisplayID Version: 1.3 (byte 0x81 = 0x13)
  - Checksum Issue: Last byte 0xF0 at offset 0xFF causes validation failure
  - Expected Checksum: Should be 0x08 for valid checksum (remainder = 0)
  - Actual Remainder: 248 (0xF8) causing kernel validation to fail

Key Hardware Identifiers:
- Manufacturer: CSO (China Star Optoelectronics)
- Model: T3 / MNE007ZA1-5
- Panel Technology: eDP (Embedded DisplayPort)
- Native Resolution: 2880x1800
- Supported Refresh Rates: 60Hz (accessible), 120Hz (blocked by validation)

Current Display Capabilities (Limited)
======================================

Available modes (stock kernel):
    2880x1800@60Hz, 1920x1200@60Hz, 1920x1080@60Hz, 1680x1050@60Hz,
    1600x1200@60Hz, 1440x900@60Hz, 1280x1024@60Hz, 1280x800@60Hz,
    1280x720@60Hz, 1024x768@60Hz, 800x600@60Hz, 640x480@60Hz

Missing: 120Hz modes that hardware supports

Impact Assessment
=================

User Impact:
- Cannot access advertised hardware capability (120Hz)
- Forced to use lower refresh rates despite hardware support
- Reduced user experience on high-end display hardware
- Must modify kernel source to access full functionality

Affected Code Path:
File: drivers/gpu/drm/drm_displayid.c
Function: validate_displayid() lines 27-45

The validation function calculates checksums and returns -EINVAL on
mismatch, completely blocking DisplayID processing.

Workaround Discovery
====================

As an experiment to understand the failure, I commented out the checksum
validation code. Results with validation bypassed:

- All DisplayID errors disappear from logs
- 120Hz mode becomes available: 2880x1800@120.000+vrr
- Variable refresh rate functionality works
- System stability maintained over extended usage
- No display artifacts or performance issues observed

Working configuration:
    Monitor [ eDP-1 ] ON
      2880x1800@120 [id: '2880x1800@120.000+vrr'] CURRENT
      2880x1800@60.001 [id: '2880x1800@60.001+vrr'] PREFERRED
      Variable Refresh Rate: Active
      All display modes: Functional

This demonstrates the hardware is fully capable when validation doesn't
block it.

Additional Context
==================

Manufacturing Variation: The panel appears to have a minor checksum error
in its DisplayID extension, but otherwise functions perfectly. This suggests
a manufacturing variation rather than a fundamental hardware defect.

Current Validation Behavior: The kernel code treats any DisplayID checksum
mismatch as fatal:
- Logs error message with remainder value
- Returns error code (-EINVAL)
- Blocks all DisplayID functionality
- No tolerance for minor variations

Hardware Vendor: China Star Optoelectronics (CSO) - major display panel
manufacturer

Questions for Community
=======================

This issue raises several questions about DisplayID validation approach:

1. Is this strict validation intentional for all hardware? What are the
   security or stability reasons for treating checksum errors as fatal?

2. Are minor checksum variations expected in real-world panels? Is this
   type of manufacturing variation common?

3. How should the kernel handle hardware with minor EDID/DisplayID issues?
   Are there existing mechanisms for such compatibility cases?

4. What would be the preferred approach for handling this type of
   compatibility issue? Are there existing precedents or guidelines?

5. Are other users experiencing similar DisplayID validation failures?
   Is this an isolated case or part of a broader pattern?

Request for Guidance
====================

I'm seeking community input on the appropriate handling of this
compatibility issue. The hardware demonstrably works when validation is
relaxed, but current code blocks access to legitimate capabilities due to
minor checksum mismatch.

This feels like a case where strict validation is preventing access to
legitimate hardware capabilities. The panel clearly supports 120Hz (as
evidenced by it working perfectly when validation is bypassed), but the
current code path blocks this due to what appears to be a minor
manufacturing variation.

I'm happy to:
- Provide more detailed technical information if helpful
- Test any proposed solutions or patches
- Help gather data about similar issues if others are seeing them
- Share my complete system configuration and EDID data

What do you think? Is this something worth addressing, and if so, what
would be the best approach?

Thanks for your time and for maintaining this subsystem!

Best regards,
Tiago Araújo

---
System: Fedora Linux 42, Linux 6.17.0-rc5
Hardware: AMD Ryzen 7 7840HS with CSO T3 eDP panel
Current workaround: DisplayID validation bypassed, 120Hz working perfectly

[-- Attachment #2: Type: text/html, Size: 9694 bytes --]

Re: DisplayID checksum validation blocking hardware capabilities - CSO T3 panel

[Dave Airlie]

> Questions for Community
> =======================
>
> This issue raises several questions about DisplayID validation approach:
>
> 1. Is this strict validation intentional for all hardware? What are the
>    security or stability reasons for treating checksum errors as fatal?
>
> 2. Are minor checksum variations expected in real-world panels? Is this
>    type of manufacturing variation common?
>
> 3. How should the kernel handle hardware with minor EDID/DisplayID issues?
>    Are there existing mechanisms for such compatibility cases?
>
> 4. What would be the preferred approach for handling this type of
>    compatibility issue? Are there existing precedents or guidelines?
>
> 5. Are other users experiencing similar DisplayID validation failures?
>    Is this an isolated case or part of a broader pattern?

There is code already to ignore EDID checksum for CEA extension
blocks, look for EDID_BLOCK_CHECKSUM, it probably could be extended to
cover displayid blocks,

Otherwise I do wonder how common this is, and whether it should be
quirk per panel or just always do it.

Dave.

Re: DisplayID checksum validation blocking hardware capabilities - CSO T3 panel

[Jani Nikula]

On Sun, 14 Sep 2025, Tiago Martins Araújo <tiago.martins.araujo@gmail.com> wrote:
> Complete EDID Data:
>
> 00000000  00 ff ff ff ff ff ff 00  36 74 5a 09 00 00 00 00
>  |........6tZ.....|
> 00000010  00 21 01 04 b5 22 16 78  03 ee 95 a3 54 4c 99 26
>  |.!...".x....TL.&|
> 00000020  0f 50 54 00 00 00 01 01  01 01 01 01 01 01 01 01
>  |.PT.............|
> 00000030  01 01 01 01 01 01 40 e7  00 6a a0 a0 67 50 08 98
>  |......@..j..gP..|
> 00000040  08 00 58 d7 10 00 00 18  00 00 00 fd 00 30 78 87
>  |..X..........0x.|
> 00000050  87 3c 01 0a 20 20 20 20  20 20 00 00 00 fe 00 43  |.<..
>  .....C|
> 00000060  53 4f 54 33 0a 20 20 20  20 20 20 20 00 00 00 fe  |SOT3.
> ....|
> 00000070  00 4d 4e 45 30 30 37 5a  41 31 2d 35 0a 20 01 98  |.MNE007ZA1-5.
> ..|
> 00000080  70 13 79 00 00 03 01 14  9a 0f 01 05 3f 0b 9f 00
>  |p.y.........?...|
> 00000090  2f 00 1f 00 07 07 69 00  02 00 05 00 00 00 00 00
>  |/.....i.........|
> 00000100  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00
>  |................|
> 00000110  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00
>  |................|
> 00000120  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00
>  |................|
> 00000130  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00
>  |................|
> 00000140  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00
>  |................|
> 00000150  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00
>  |................|
> 00000160  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00
>  |................|
> 00000170  00 00 00 00 00 00 00 00  00 00 00 00 00 00 f0 98
>  |................|

That's not the complete EDID data, though. It's missing 6*16 bytes. If
you go by the hex offsets, 0x100 does not follow 0x090.

> As an experiment to understand the failure, I commented out the checksum
> validation code. Results with validation bypassed:

Running that, please grab the EDID from sysfs. edid-decode does a good
job of decoding, but also includes the hex in case we want to run it on
a newer or modified edid-decode.

BR,
Jani.

-- 
Jani Nikula, Intel

Re: DisplayID checksum validation blocking hardware capabilities - CSO T3 panel

[Jani Nikula]

On Mon, 15 Sep 2025, Jani Nikula <jani.nikula@linux.intel.com> wrote:
> That's not the complete EDID data, though. It's missing 6*16 bytes. If
> you go by the hex offsets, 0x100 does not follow 0x090.

Alternatively, there's extra garbage at the end. I'm not really sure
what happens because we have no logs, and we discard extension blocks
that fail the checksum. (This is something I've been meaning to change
no matter what; we shouldn't modify the EDID.)


-- 
Jani Nikula, Intel

Re: DisplayID checksum validation blocking hardware capabilities - CSO T3 panel

[Jani Nikula]

On Mon, 15 Sep 2025, Dave Airlie <airlied@gmail.com> wrote:
>> Questions for Community
>> =======================
>>
>> This issue raises several questions about DisplayID validation approach:
>>
>> 1. Is this strict validation intentional for all hardware? What are the
>>    security or stability reasons for treating checksum errors as fatal?
>>
>> 2. Are minor checksum variations expected in real-world panels? Is this
>>    type of manufacturing variation common?
>>
>> 3. How should the kernel handle hardware with minor EDID/DisplayID issues?
>>    Are there existing mechanisms for such compatibility cases?
>>
>> 4. What would be the preferred approach for handling this type of
>>    compatibility issue? Are there existing precedents or guidelines?
>>
>> 5. Are other users experiencing similar DisplayID validation failures?
>>    Is this an isolated case or part of a broader pattern?
>
> There is code already to ignore EDID checksum for CEA extension
> blocks, look for EDID_BLOCK_CHECKSUM, it probably could be extended to
> cover displayid blocks,

IIRC we ignore CEA extension checksum errors because hubs that
incorrectly modified the display's EDID on the fly were so common.

Anyway, this is not just about EDID extension block checksums, it's also
about DisplayID structure checksum.

I'm not sure if the attached EDID is complete, but it's looking like
just about all the checksums in it are garbage.

> Otherwise I do wonder how common this is, and whether it should be
> quirk per panel or just always do it.

I think Jon Postel was wrong, and we should never have been liberal in
accepting garbage and pretending it was valid data. But with EDIDs, that
ship has sailed, and here we are.

Considering that a valid checksum isn't exactly a guarantee of valid
EDID data inside, I'm starting to lean towards just debug logging EDID
and DisplayID checksum errors, and using whatever data we can find
inside.


BR,
Jani.

-- 
Jani Nikula, Intel

Re: DisplayID checksum validation blocking hardware capabilities - CSO T3 panel

[Tiago Martins Araújo]

[-- Attachment #1: Type: text/plain, Size: 3496 bytes --]

> That's not the complete EDID data, though. It's missing 6*16 bytes. If
> you go by the hex offsets, 0x100 does not follow 0x090.

>  please grab the EDID from sysfs.

Fresh from my terminal:
➜  ~ cat /sys/class/drm/card1-eDP-1/edid | edid-decode
edid-decode (hex):

00 ff ff ff ff ff ff 00 0e 6f 16 14 00 00 00 00
00 20 01 04 b5 1e 13 78 03 21 15 a8 53 49 9c 25
0f 50 54 00 00 00 01 01 01 01 01 01 01 01 01 01
01 01 01 01 01 01 ce 87 40 a0 b0 08 6a 70 30 20
36 00 2d bc 10 00 00 18 00 00 00 fd 00 28 78 e5
e5 46 01 0a 20 20 20 20 20 20 00 00 00 fe 00 43
53 4f 54 20 54 33 0a 20 20 20 20 20 00 00 00 fe
00 4d 4e 45 30 30 37 5a 41 31 2d 35 0a 20 01 af

70 13 79 00 00 03 01 14 9a 0f 01 05 3f 0b 9f 00
2f 00 1f 00 07 07 69 00 02 00 05 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 f0 98

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

Block 0, Base EDID:
  EDID Structure Version & Revision: 1.4
  Vendor & Product Identification:
    Manufacturer: CSO
    Model: 5142
    Made in: 2022
  Basic Display Parameters & Features:
    Digital display
    Bits per primary color channel: 10
    DisplayPort interface
    Maximum image size: 30 cm x 19 cm
    Gamma: 2.20
    Supported color formats: RGB 4:4:4
    First detailed timing includes the native pixel format and preferred
refresh rate
    Display supports continuous frequencies
  Color Characteristics:
    Red  : 0.6562, 0.3261
    Green: 0.2851, 0.6103
    Blue : 0.1445, 0.0595
    White: 0.3134, 0.3291
  Established Timings I & II: none
  Standard Timings: none
  Detailed Timing Descriptors:
    DTD 1:  2880x1800   60.000966 Hz  16:10   114.362 kHz    347.660000 MHz
(301 mm x 188 mm)
                 Hfront   48 Hsync  32 Hback   80 Hpol N
                 Vfront    3 Vsync   6 Vback   97 Vpol N
    Display Range Limits:
      Monitor ranges (Range Limits Only): 40-120 Hz V, 229-229 kHz H, max
dotclock 700 MHz
    Alphanumeric Data String: 'CSOT T3'
    Alphanumeric Data String: 'MNE007ZA1-5'
  Extension blocks: 1
Checksum: 0xaf

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

Block 1, DisplayID Extension Block:
  Version: 1.3
  Extension Count: 0
  Display Product Type: Extension Section
  Video Timing Modes Type 1 - Detailed Timings Data Block:
    DTD:  2880x1800  120.000207 Hz  16:10   228.720 kHz    695.310000 MHz
(aspect 16:10, no 3D stereo)
               Hfront   48 Hsync  32 Hback   80 Hpol N
               Vfront    3 Vsync   6 Vback   97 Vpol N
  Checksum: 0xf0 (should be 0xf8)
Checksum: 0x98

Let me know if you need something else from my side.

> There is code already to ignore EDID checksum for CEA extension
> blocks, look for EDID_BLOCK_CHECKSUM, it probably could be extended to
> cover displayid blocks,
Are you recommending me to make use of this to suggest a fix/bypass, or is
that just a suggestion for the other maintainers?

> Otherwise I do wonder how common this is, and whether it should be
> quirk per panel or just always do it.
This is the machine model, from Lenovo's website:
https://pcsupport.lenovo.com/de/en/products/laptops-and-netbooks/5-series/ideapad-pro-5-14aph8/83am/83amcto1ww
There probably plenty of other models that make use of the same panel.

Thanks for looking into this,
Tiago

[-- Attachment #2: Type: text/html, Size: 4221 bytes --]

Re: DisplayID checksum validation blocking hardware capabilities - CSO T3 panel

[Jani Nikula]

On Mon, 15 Sep 2025, Tiago Martins Araújo <tiago.martins.araujo@gmail.com> wrote:
>> That's not the complete EDID data, though. It's missing 6*16 bytes. If
>> you go by the hex offsets, 0x100 does not follow 0x090.
>
>>  please grab the EDID from sysfs.
>
> Fresh from my terminal:
> ➜  ~ cat /sys/class/drm/card1-eDP-1/edid | edid-decode
> edid-decode (hex):
>
> 00 ff ff ff ff ff ff 00 0e 6f 16 14 00 00 00 00
> 00 20 01 04 b5 1e 13 78 03 21 15 a8 53 49 9c 25
> 0f 50 54 00 00 00 01 01 01 01 01 01 01 01 01 01
> 01 01 01 01 01 01 ce 87 40 a0 b0 08 6a 70 30 20
> 36 00 2d bc 10 00 00 18 00 00 00 fd 00 28 78 e5
> e5 46 01 0a 20 20 20 20 20 20 00 00 00 fe 00 43
> 53 4f 54 20 54 33 0a 20 20 20 20 20 00 00 00 fe
> 00 4d 4e 45 30 30 37 5a 41 31 2d 35 0a 20 01 af
>
> 70 13 79 00 00 03 01 14 9a 0f 01 05 3f 0b 9f 00
> 2f 00 1f 00 07 07 69 00 02 00 05 00 00 00 00 00
> 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> 00 00 00 00 00 00 00 00 00 00 00 00 00 00 f0 98
>
> ----------------
>
> Block 0, Base EDID:
>   EDID Structure Version & Revision: 1.4
>   Vendor & Product Identification:
>     Manufacturer: CSO
>     Model: 5142
>     Made in: 2022
>   Basic Display Parameters & Features:
>     Digital display
>     Bits per primary color channel: 10
>     DisplayPort interface
>     Maximum image size: 30 cm x 19 cm
>     Gamma: 2.20
>     Supported color formats: RGB 4:4:4
>     First detailed timing includes the native pixel format and preferred
> refresh rate
>     Display supports continuous frequencies
>   Color Characteristics:
>     Red  : 0.6562, 0.3261
>     Green: 0.2851, 0.6103
>     Blue : 0.1445, 0.0595
>     White: 0.3134, 0.3291
>   Established Timings I & II: none
>   Standard Timings: none
>   Detailed Timing Descriptors:
>     DTD 1:  2880x1800   60.000966 Hz  16:10   114.362 kHz    347.660000 MHz
> (301 mm x 188 mm)
>                  Hfront   48 Hsync  32 Hback   80 Hpol N
>                  Vfront    3 Vsync   6 Vback   97 Vpol N
>     Display Range Limits:
>       Monitor ranges (Range Limits Only): 40-120 Hz V, 229-229 kHz H, max
> dotclock 700 MHz
>     Alphanumeric Data String: 'CSOT T3'
>     Alphanumeric Data String: 'MNE007ZA1-5'
>   Extension blocks: 1
> Checksum: 0xaf
>
> ----------------
>
> Block 1, DisplayID Extension Block:
>   Version: 1.3
>   Extension Count: 0
>   Display Product Type: Extension Section
>   Video Timing Modes Type 1 - Detailed Timings Data Block:
>     DTD:  2880x1800  120.000207 Hz  16:10   228.720 kHz    695.310000 MHz
> (aspect 16:10, no 3D stereo)
>                Hfront   48 Hsync  32 Hback   80 Hpol N
>                Vfront    3 Vsync   6 Vback   97 Vpol N
>   Checksum: 0xf0 (should be 0xf8)
> Checksum: 0x98

There's an i915 bug report [1] on what is likely a similar Lenovo model
to yours, with the same display, but with an Intel GPU.

I looked at adding an EDID quirk for this, but actually passing the
information all the way down to the DisplayID checksum validation is
going to be annoying. :(


BR,
Jani.

[1] https://gitlab.freedesktop.org/drm/i915/kernel/-/issues/14703


-- 
Jani Nikula, Intel

Re: DisplayID checksum validation blocking hardware capabilities - CSO T3 panel

[Tiago Martins Araújo]

[-- Attachment #1: Type: text/plain, Size: 3868 bytes --]

I'm glad to see there are more reports about this problem. Let me know if
need my getting info about this monitor, or testing anything.

Thanks for looking into this.

Tiago Martins Araújo

On Tue, Oct 28, 2025, 20:08 Jani Nikula <jani.nikula@linux.intel.com> wrote:

> On Mon, 15 Sep 2025, Tiago Martins Araújo <tiago.martins.araujo@gmail.com>
> wrote:
> >> That's not the complete EDID data, though. It's missing 6*16 bytes. If
> >> you go by the hex offsets, 0x100 does not follow 0x090.
> >
> >>  please grab the EDID from sysfs.
> >
> > Fresh from my terminal:
> > ➜  ~ cat /sys/class/drm/card1-eDP-1/edid | edid-decode
> > edid-decode (hex):
> >
> > 00 ff ff ff ff ff ff 00 0e 6f 16 14 00 00 00 00
> > 00 20 01 04 b5 1e 13 78 03 21 15 a8 53 49 9c 25
> > 0f 50 54 00 00 00 01 01 01 01 01 01 01 01 01 01
> > 01 01 01 01 01 01 ce 87 40 a0 b0 08 6a 70 30 20
> > 36 00 2d bc 10 00 00 18 00 00 00 fd 00 28 78 e5
> > e5 46 01 0a 20 20 20 20 20 20 00 00 00 fe 00 43
> > 53 4f 54 20 54 33 0a 20 20 20 20 20 00 00 00 fe
> > 00 4d 4e 45 30 30 37 5a 41 31 2d 35 0a 20 01 af
> >
> > 70 13 79 00 00 03 01 14 9a 0f 01 05 3f 0b 9f 00
> > 2f 00 1f 00 07 07 69 00 02 00 05 00 00 00 00 00
> > 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> > 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> > 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> > 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> > 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> > 00 00 00 00 00 00 00 00 00 00 00 00 00 00 f0 98
> >
> > ----------------
> >
> > Block 0, Base EDID:
> >   EDID Structure Version & Revision: 1.4
> >   Vendor & Product Identification:
> >     Manufacturer: CSO
> >     Model: 5142
> >     Made in: 2022
> >   Basic Display Parameters & Features:
> >     Digital display
> >     Bits per primary color channel: 10
> >     DisplayPort interface
> >     Maximum image size: 30 cm x 19 cm
> >     Gamma: 2.20
> >     Supported color formats: RGB 4:4:4
> >     First detailed timing includes the native pixel format and preferred
> > refresh rate
> >     Display supports continuous frequencies
> >   Color Characteristics:
> >     Red  : 0.6562, 0.3261
> >     Green: 0.2851, 0.6103
> >     Blue : 0.1445, 0.0595
> >     White: 0.3134, 0.3291
> >   Established Timings I & II: none
> >   Standard Timings: none
> >   Detailed Timing Descriptors:
> >     DTD 1:  2880x1800   60.000966 Hz  16:10   114.362 kHz    347.660000
> MHz
> > (301 mm x 188 mm)
> >                  Hfront   48 Hsync  32 Hback   80 Hpol N
> >                  Vfront    3 Vsync   6 Vback   97 Vpol N
> >     Display Range Limits:
> >       Monitor ranges (Range Limits Only): 40-120 Hz V, 229-229 kHz H, max
> > dotclock 700 MHz
> >     Alphanumeric Data String: 'CSOT T3'
> >     Alphanumeric Data String: 'MNE007ZA1-5'
> >   Extension blocks: 1
> > Checksum: 0xaf
> >
> > ----------------
> >
> > Block 1, DisplayID Extension Block:
> >   Version: 1.3
> >   Extension Count: 0
> >   Display Product Type: Extension Section
> >   Video Timing Modes Type 1 - Detailed Timings Data Block:
> >     DTD:  2880x1800  120.000207 Hz  16:10   228.720 kHz    695.310000 MHz
> > (aspect 16:10, no 3D stereo)
> >                Hfront   48 Hsync  32 Hback   80 Hpol N
> >                Vfront    3 Vsync   6 Vback   97 Vpol N
> >   Checksum: 0xf0 (should be 0xf8)
> > Checksum: 0x98
>
> There's an i915 bug report [1] on what is likely a similar Lenovo model
> to yours, with the same display, but with an Intel GPU.
>
> I looked at adding an EDID quirk for this, but actually passing the
> information all the way down to the DisplayID checksum validation is
> going to be annoying. :(
>
>
> BR,
> Jani.
>
> [1] https://gitlab.freedesktop.org/drm/i915/kernel/-/issues/14703
>
>
> --
> Jani Nikula, Intel
>

[-- Attachment #2: Type: text/html, Size: 5125 bytes --]

Re: DisplayID checksum validation blocking hardware capabilities - CSO T3 panel

[Jani Nikula]

On Tue, 28 Oct 2025, Tiago Martins Araújo <tiago.martins.araujo@gmail.com> wrote:
> I'm glad to see there are more reports about this problem. Let me know if
> need my getting info about this monitor, or testing anything.

I just sent a patch series [1] that might help. Please try. It's
untested, I hope I didn't botch up anything... I was also getting too
tired to double check the quirk against your EDID in patch 3. Fingers
crossed.

BR,
Jani.

[1] https://lore.kernel.org/r/cover.1761681968.git.jani.nikula@intel.com

-- 
Jani Nikula, Intel

Re: DisplayID checksum validation blocking hardware capabilities - CSO T3 panel

[Tiago Martins Araújo]

[-- Attachment #1: Type: text/plain, Size: 1866 bytes --]

On Tue, Oct 28, 2025 at 9:10 PM Jani Nikula <jani.nikula@linux.intel.com>
wrote:
> I just sent a patch series [1] that might help. Please try. It's
> untested, I hope I didn't botch up anything... I was also getting too
> tired to double check the quirk against your EDID in patch 3. Fingers
> crossed.

Hi Jani,

I've tested your DisplayID quirk patch series [1] and can confirm it works
perfectly!

Test Results:
- DisplayID checksum errors now properly ignored (kernel logs show
"ignoring")
- 120Hz mode working: 2880x1800@120.000+vrr
- System stable, no display artifacts
- No issues after reboot and testing

Some log from my terminal:

➜  ~ sudo dmesg | grep -i displayid
[    4.673483] [drm] DisplayID checksum invalid, remainder is 248 (ignoring)
[    4.673489] [drm] DisplayID checksum invalid, remainder is 248 (ignoring)
[    4.673492] [drm] DisplayID checksum invalid, remainder is 248 (ignoring)
[    4.673494] [drm] DisplayID checksum invalid, remainder is 248 (ignoring)
[    4.673496] [drm] DisplayID checksum invalid, remainder is 248 (ignoring)
[    4.673503] [drm] DisplayID checksum invalid, remainder is 248 (ignoring)
[    4.674242] [drm] DisplayID checksum invalid, remainder is 248 (ignoring)
[    4.674245] [drm] DisplayID checksum invalid, remainder is 248 (ignoring)
...

➜  ~ gnome-monitor-config list 2>/dev/null || gsettings get
org.gnome.desktop.interface scaling-factor
Monitor [ eDP-1 ] ON
  display-name: Built-in display
  2880x1800@120 [id: '2880x1800@120.000+vrr'] [preferred scale = 1.74757 (1
1.25 1.5 1.74757 2 2.25 2.5 2.74809 3 3.24324 3.49515)] CURRENT
...

Perhaps I should just buy a Thinkpad next time :)
Jokes aside, thanks for your work on this patch!

Regards,
Tiago

[1] https://gitlab.freedesktop.org/drm/i915/kernel/-/issues/14703

-- 
Tiago Martins Araújo

[-- Attachment #2: Type: text/html, Size: 2399 bytes --]

Re: DisplayID checksum validation blocking hardware capabilities - CSO T3 panel

[Jani Nikula]

On Tue, 28 Oct 2025, Tiago Martins Araújo <tiago.martins.araujo@gmail.com> wrote:
> I've tested your DisplayID quirk patch series [1] and can confirm it works
> perfectly!

Awesome, thanks for testing!

Cc: Harry, Alex, Leo, since this issue is present on both Intel and AMD
based machines, could you find someone to review [1] please?

> Perhaps I should just buy a Thinkpad next time :)

Well, I think the listing at [2] is a more reliable indication for Linux
support from Lenovo than just "ThinkPad".

BR,
Jani.


[1] https://lore.kernel.org/r/cover.1761681968.git.jani.nikula@intel.com

[2] https://support.lenovo.com/us/en/solutions/pd031426-linux-for-personal-systems


-- 
Jani Nikula, Intel

Re: DisplayID checksum validation blocking hardware capabilities - CSO T3 panel

[Jani Nikula]

On Tue, 28 Oct 2025, Tiago Martins Araújo <tiago.martins.araujo@gmail.com> wrote:
> I've tested your DisplayID quirk patch series [1] and can confirm it works
> perfectly!

May I add your

Tested-by: Tiago Martins Araújo <tiago.martins.araujo@gmail.com>

to the commits?

BR,
Jani.


-- 
Jani Nikula, Intel

Re: DisplayID checksum validation blocking hardware capabilities - CSO T3 panel

[Tiago Martins Araújo]

[-- Attachment #1: Type: text/plain, Size: 246 bytes --]

On Fri, Oct 31, 2025 at 11:13 AM Jani Nikula <jani.nikula@linux.intel.com>
wrote:
> May I add your
> Tested-by: Tiago Martins Araújo <tiago.martins.araujo@gmail.com>
> to the commits?

Yes, please. Thanks!

-- 
Tiago Martins Araújo

[-- Attachment #2: Type: text/html, Size: 757 bytes --]