filing here per request a laptop with a weird EDID can only show 1920x1080 resolution, but other modes work fine on Win10, apparently. Extracted contents: header: 00 ff ff ff ff ff ff 00 serial number: 06 af 2d 21 00 00 00 00 01 1d version: 01 04 basic params: 95 1d 11 78 03 chroma info: 30 e5 a5 56 53 9d 27 0c 50 54 established: 00 00 00 standard: 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 descriptor 1: 14 37 80 b8 70 38 24 40 10 10 3e 00 25 a5 10 00 00 1a descriptor 2: 10 2c 80 b8 70 38 24 40 10 10 3e 00 25 a5 10 00 00 1a descriptor 3: 00 00 00 fe 00 48 48 59 43 59 80 42 31 33 33 48 41 4b descriptor 4: 00 00 00 00 00 01 41 21 9e 00 10 00 00 0a 01 0a 20 20 extensions: 00 checksum: f2 EDID version: 1.4 Manufacturer: AUO Model 212d Serial Number 0 Made in week 1 of 2019 Digital display 6 bits per primary color channel DisplayPort interface Maximum image size: 29 cm x 17 cm Gamma: 2.20 Supported color formats: RGB 4:4:4 First detailed timing includes the native pixel format and preferred refresh rate Display is continuous frequency Display x,y Chromaticity: Red: 0.6445, 0.3388 Green: 0.3242, 0.6132 Blue: 0.1552, 0.0488 White: 0.3134, 0.3291 Established timings supported: Standard timings supported: Detailed mode: Clock 141.000 MHz, 293 mm x 165 mm 1920 1936 1952 2104 hborder 0 1080 1083 1097 1116 vborder 0 +hsync -vsync VertFreq: 60 Hz, HorFreq: 67015 Hz Detailed mode: Clock 112.800 MHz, 293 mm x 165 mm 1920 1936 1952 2104 hborder 0 1080 1083 1097 1116 vborder 0 +hsync -vsync VertFreq: 48 Hz, HorFreq: 53612 Hz ASCII string: HHYCY Manufacturer-specified data, tag 0 Checksum: 0xf2 (valid) Unknown extension block EDID block does NOT conform to EDID 1.4! Missing name descriptor Missing monitor ranges Detailed block string not properly terminated EDID block does not conform at all! Has 101 nonconformant extension block(s) Invalid ASCII string
Any possibility of getting dmesg logs from the user?
How old is the kernel? Did you get any chance to verify the issue with drmtip? In any case, dmesg from boot with kernel parameters drm.debug=0x1e log_buf_len=4M would be helpful for investigation.
Please attach the binary EDID from /sys/class/drm/card0-eDP-1/edid (adjust card0-eDP-1 as needed). Need to check if the EDID is bogus or if our parsing of it is bogus. In any case if it's the eDP panel, we'll only use the native resolution and use scaling to support the other modes. Shouldn't matter from userspace perspective.
Created attachment 144541 [details] edid
This is a laptop panel? We don't use anything but the preferred mode anyway. All the other modes are pulled out of thin air by userspace (at least intel/modesetting ddx do this). Are you using some other userspace?
Yes, this is laptop eDP panel and panel vendor enabled 18h=0x03 with preferred timing mode and continuous timing with display range limits. In drm_mode_std function, it return NULL in bad_std_timing with standard_timing_level=LEVEL_CVT since hsize=1 & vfreq_aspect=1.
Wild idea, is it a fancy new display? Maybe it's Multi-SST. Please ensure CONFIG_DRM_DP_AUX_CHARDEV=y and /sys/class/drm/card0-eDP-1 actually has drm_dp_aux0, adjust the dev name accordingly, and run: # dd if=/dev/drm_dp_aux0 skip=1956 bs=1 count=1 2>/dev/null | hexdump -C Is the result non-zero? Most likely it's zero, but this should rule out one potential source of issues.
Is the result non-zero? Yes, it's zero! u@u-Vostro-5391:~$ dd if=/dev/drm_dp_aux0 skip=1956 bs=1 count=1 2>/dev/null | hexdump -C u@u-Vostro-5391:~$
(In reply to Cooper Chiou from comment #8) > Is the result non-zero? > > Yes, it's zero! > > u@u-Vostro-5391:~$ dd if=/dev/drm_dp_aux0 skip=1956 bs=1 count=1 2>/dev/null > | hexdump -C > u@u-Vostro-5391:~$ Where's the output?
Cooper, can you attach the output?
(In reply to Lakshmi from comment #10) > Cooper, can you attach the output? Priority and severity will be set to default until the issue is confirmed.
(In reply to Lakshmi from comment #10) > Cooper, can you attach the output? (In reply to Lakshmi from comment #11) > (In reply to Lakshmi from comment #10) > > Cooper, can you attach the output? > > Priority and severity will be set to default until the issue is confirmed. No response for about 2 months. Can you please attach the output of # dd if=/dev/drm_dp_aux0 skip=1956 bs=1 count=1 2>/dev/null | hexdump -C Unless we have the information, it's hard to proceed with this bug. Can you please attach the output?
(In reply to Lakshmi from comment #12) > (In reply to Lakshmi from comment #10) > > Cooper, can you attach the output? > > (In reply to Lakshmi from comment #11) > > (In reply to Lakshmi from comment #10) > > > Cooper, can you attach the output? > > > > Priority and severity will be set to default until the issue is confirmed. > > No response for about 2 months. Can you please attach the output of > # dd if=/dev/drm_dp_aux0 skip=1956 bs=1 count=1 2>/dev/null | hexdump -C > > Unless we have the information, it's hard to proceed with this bug. Can you > please attach the output? sorry to be late. The result is: 0000000 \0 0000001
-- GitLab Migration Automatic Message -- This bug has been migrated to freedesktop.org's GitLab instance and has been closed from further activity. You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.freedesktop.org/drm/intel/issues/313.
Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.