* 4096x2160 monitor has EDID reporting 3840x2160
@ 2018-09-22 21:29 Brian Vincent
2018-09-24 6:49 ` Jani Nikula
0 siblings, 1 reply; 5+ messages in thread
From: Brian Vincent @ 2018-09-22 21:29 UTC (permalink / raw)
To: dri-devel
[-- Attachment #1.1: Type: text/plain, Size: 1505 bytes --]
I have a LG 31MU97-B monitor. My understanding is that EDID does not have
a way to report itself as a 4096x2160 monitor, so it reports itself as a
3840x2160 monitor. The mode that it actually supports for it's native
resolution that I've been using looks like this:
xrandr --newmode "4096x2160_60" 556.730 4096 4104 4136 4176 2160 2208
2216 2222 +hsync +vsync
I can use this mode with X and it works fine, but I've been unable to get
it to work with KMS and Wayland, since it uses the EDID. EDID has CEA
extensions that can support some 4096x2160 video modes, but I've tried
them, and they don't work since they're not exactly the modeline that it
needs.
I've found these DMT modes in drm_edid.c that seems like they would
probably work:
/* 0x57 - 4096x2160@60Hz RB */
{ DRM_MODE("4096x2160", DRM_MODE_TYPE_DRIVER, 556744, 4096, 4104,
4136, 4176, 0, 2160, 2208, 2216, 2222, 0,
DRM_MODE_FLAG_PHSYNC | DRM_MODE_FLAG_NVSYNC) },
/* 0x58 - 4096x2160@59.94Hz RB */
{ DRM_MODE("4096x2160", DRM_MODE_TYPE_DRIVER, 556188, 4096, 4104,
4136, 4176, 0, 2160, 2208, 2216, 2222, 0,
DRM_MODE_FLAG_PHSYNC | DRM_MODE_FLAG_NVSYNC) },
But... even if I manage to get the code to infer modes on my monitor, it'll
reject them since the horizontal resolution is 4096 which is higher than
the 3840 that my monitor's EDID reports.
If I wanted to fix this for everyone, what would the proper fix even look
like? Should this be added as a quirk for this monitor to force add the
modes?
Thanks,
Brian Vincent
[-- Attachment #1.2: Type: text/html, Size: 2187 bytes --]
[-- Attachment #2: Type: text/plain, Size: 160 bytes --]
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
^ permalink raw reply [flat|nested] 5+ messages in thread* Re: 4096x2160 monitor has EDID reporting 3840x2160
2018-09-22 21:29 4096x2160 monitor has EDID reporting 3840x2160 Brian Vincent
@ 2018-09-24 6:49 ` Jani Nikula
2018-09-24 22:32 ` Brian Vincent
0 siblings, 1 reply; 5+ messages in thread
From: Jani Nikula @ 2018-09-24 6:49 UTC (permalink / raw)
To: Brian Vincent, dri-devel
On Sat, 22 Sep 2018, Brian Vincent <brainn@gmail.com> wrote:
> I have a LG 31MU97-B monitor. My understanding is that EDID does not have
> a way to report itself as a 4096x2160 monitor, so it reports itself as a
> 3840x2160 monitor. The mode that it actually supports for it's native
> resolution that I've been using looks like this:
A dmesg with drm.debug=14 might prove useful in figuring out what's
actually going on. Without the user provided mode.
BR,
Jani.
--
Jani Nikula, Intel Open Source Graphics Center
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: 4096x2160 monitor has EDID reporting 3840x2160
2018-09-24 6:49 ` Jani Nikula
@ 2018-09-24 22:32 ` Brian Vincent
2018-09-26 11:27 ` Jani Nikula
0 siblings, 1 reply; 5+ messages in thread
From: Brian Vincent @ 2018-09-24 22:32 UTC (permalink / raw)
To: Jani Nikula; +Cc: dri-devel
[-- Attachment #1.1: Type: text/plain, Size: 8524 bytes --]
Thank you for your reply. I took your advice and tried it. None of it
really surprises me.
The problem seems pretty simple. There is simply nothing in the EDID that
mentions that it's a 4096x2160 monitor. From looking at the code, I don't
see any possible code path that would allow it to somehow discover a mode
higher than what the EDID reports. Even if I did hit the code path that
infers new modes, the function valid_inferred_mode will reject any
resolution that's higher. Is there a mechanism for discovering these
higher modes that I'm missing?
I'm willing to work on a patch that would make this monitor "just work".
What I'm interested in is what a patch for this would even look like. I
assume this would need to be added as a "quirk" since the EDID is factually
wrong.
Here's the relevant logs:
[ 52.333372] [drm:drm_detect_monitor_audio [drm]] Monitor has basic audio
support
[ 52.333382] [drm:drm_add_display_info [drm]] non_desktop set to 0
[ 52.333395] [drm:drm_add_edid_modes [drm]] ELD monitor 31MU97
[ 52.333402] [drm:drm_add_edid_modes [drm]] ELD size 32, SAD count 1
[ 52.333410] [drm:drm_add_display_info [drm]] non_desktop set to 0
[ 52.333496] [drm:drm_helper_probe_single_connector_modes
[drm_kms_helper]] [CONNECTOR:98:DP-4] probed modes :
[ 52.333506] [drm:drm_mode_debug_printmodeline [drm]] Modeline
95:"3840x2160" 60 533280 3840 3848 3992 4000 2160 2214 2219 2222 0x48 0x9
[ 52.333515] [drm:drm_mode_debug_printmodeline [drm]] Modeline
107:"3840x2160" 30 266640 3840 3848 3992 4000 2160 2214 2219 2222 0x40 0x9
[ 52.333523] [drm:drm_mode_debug_printmodeline [drm]] Modeline
114:"1920x1080" 60 148500 1920 2008 2052 2200 1080 1084 1089 1125 0x40 0x5
[ 52.333531] [drm:drm_mode_debug_printmodeline [drm]] Modeline
122:"1920x1080" 60 148500 1920 2008 2052 2200 1080 1084 1089 1125 0x40 0x5
[ 52.333539] [drm:drm_mode_debug_printmodeline [drm]] Modeline
126:"1920x1080" 60 148352 1920 2008 2052 2200 1080 1084 1089 1125 0x40 0x5
[ 52.333547] [drm:drm_mode_debug_printmodeline [drm]] Modeline
118:"1600x900" 60 108000 1600 1624 1704 1800 900 901 904 1000 0x40 0x5
[ 52.333555] [drm:drm_mode_debug_printmodeline [drm]] Modeline
116:"1280x1024" 60 108000 1280 1328 1440 1688 1024 1025 1028 1066 0x40 0x5
[ 52.333563] [drm:drm_mode_debug_printmodeline [drm]] Modeline
115:"1152x864" 60 81579 1152 1216 1336 1520 864 865 868 895 0x0 0x6
[ 52.333572] [drm:drm_mode_debug_printmodeline [drm]] Modeline
117:"1280x720" 60 74250 1280 1390 1430 1650 720 725 730 750 0x40 0x5
[ 52.333579] [drm:drm_mode_debug_printmodeline [drm]] Modeline
123:"1280x720" 60 74250 1280 1390 1430 1650 720 725 730 750 0x40 0x5
[ 52.333587] [drm:drm_mode_debug_printmodeline [drm]] Modeline
127:"1280x720" 60 74176 1280 1390 1430 1650 720 725 730 750 0x40 0x5
[ 52.333595] [drm:drm_mode_debug_printmodeline [drm]] Modeline
108:"1024x768" 60 65000 1024 1048 1184 1344 768 771 777 806 0x40 0xa
[ 52.333603] [drm:drm_mode_debug_printmodeline [drm]] Modeline
106:"800x600" 60 40000 800 840 968 1056 600 601 605 628 0x40 0x5
[ 52.333611] [drm:drm_mode_debug_printmodeline [drm]] Modeline
131:"720x480" 60 27027 720 736 798 858 480 489 495 525 0x40 0xa
[ 52.333619] [drm:drm_mode_debug_printmodeline [drm]] Modeline
124:"720x480" 60 27000 720 736 798 858 480 489 495 525 0x40 0xa
[ 52.333627] [drm:drm_mode_debug_printmodeline [drm]] Modeline
128:"640x480" 60 25200 640 656 752 800 480 490 492 525 0x40 0xa
[ 52.333635] [drm:drm_mode_debug_printmodeline [drm]] Modeline
97:"640x480" 60 25175 640 656 752 800 480 490 492 525 0x40 0xa
[ 52.333641] [drm:drm_mode_debug_printmodeline [drm]] Modeline
125:"640x480" 60 25175 640 656 752 800 480 490 492 525 0x40 0xa
Here's my parsed EDID:
header: 00 ff ff ff ff ff ff 00
vendor/product identification: 1e 6d e7 76 01 01 01 01 01 18
edid struct version/revision: 01 04
basic display parameters/features: b5 3c 22 78 9e
color characteristics: e9 d5 aa 50 34 b6 25 0e 50 54
established timings: 21 08 00
standard timing identification: 71 40 81 80 81 c0 a9 c0 d1 c0 01 01 01
01 01 01
detailed timing 0: 50 d0 00 a0 f0 70 3e 80 08 90 65 0c 6d
55 21 00 00 1a
detailed timing 1: 28 68 00 a0 f0 70 3e 80 08 90 65 0c 6d
55 21 00 00 1a
detailed timing 2: 00 00 00 fd 00 38 3d 1e 87 38 00 0a 20
20 20 20 20 20
detailed timing 3: 00 00 00 fc 00 33 31 4d 55 39 37 0a 20
20 20 20 20 20
extensions: 02
checksum: af
Monitor
Model name............... 31MU97
Manufacturer............. GSM
Product code............. 30439
Module serial number..... 16843009
Serial number............ n/a
Manufacture date......... 2014, ISO week 1
EDID revision............ 1.4
Input signal type........ Digital
VESA DFP 1.x supported... Yes
Display type............. Undefined
Screen size.............. 600 mm x 340 mm (27.2 in)
Power management......... Standby
Extension blocks......... 2
Color characteristics
Default color space...... sRGB
Display gamma............ 2.20
Red chromaticity......... Rx 0.667 - Ry 0.314
Green chromaticity....... Gx 0.205 - Gy 0.712
Blue chromaticity........ Bx 0.147 - By 0.056
White point (default).... Wx 0.313 - Wy 0.329
Timing characteristics
Horizontal scan range.... 30 - 135 kHz
Vertical scan range...... 56 - 61 Hz
Video bandwidth.......... 560 MHz
GTF standard............. Not Supported
Preferred timing......... Yes
Native/preferred timing.. 3840x2160p at 60Hz (16:9)
Modeline............... "3840x2160" 533.280 3840 3848 3992 4000 2160
2214 2219 2222 +hsync -vsync
Standard timings supported
640 x 480p @ 60Hz - IBM VGA
800 x 600p @ 60Hz - VESA
1024 x 768p @ 60Hz - VESA
1152 x 864p @ 60Hz - VESA STD
1280 x 1024p @ 60Hz - VESA STD
1280 x 720p @ 60Hz - VESA STD
1600 x 900p @ 60Hz - VESA STD
1920 x 1080p @ 60Hz - VESA STD
cea extension header: 02 03 12 71
data block collection: 45 10 04 03 01 00 23 09 07 07 83 01 00
00
detailed timing descriptor 000: 02 3a 80 18 71 38 2d 40 58 2c 45 00 b8
6f 21 00 00 1e
padding: 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
checksum: 44
CEA-861 Information
Revision number.......... 3
IT underscan............. Not supported
Basic audio.............. Supported
YCbCr 4:4:4.............. Supported
YCbCr 4:2:2.............. Supported
Native formats........... 1
Detailed timing #1....... 1920x1080p at 60Hz (16:9)
Modeline............... "1920x1080" 148.500 1920 2008 2052 2200 1080
1084 1089 1125 +hsync +vsync
CE video identifiers (VICs) - timing/formats supported
CEA Mode 16: 1920 x 1080p @ 60Hz
CEA Mode 04: 1280 x 720p @ 60Hz
CEA Mode 03: 720 x 480p @ 60Hz
CEA Mode 01: 640 x 480p @ 60Hz
CEA Mode 00: 0 x 0i @ 0Hz
CE audio data (formats supported)
LPCM 2-channel, 16/20/24 bit depths at 32/44.1/48 kHz
CEA speaker allocation data
Channel configuration.... 2.0
Front left/right......... Yes
Front LFE................ No
Front center............. No
Rear left/right.......... No
Rear center.............. No
Front left/right center.. No
Rear left/right center... No
Front left/right wide.... No
Front left/right high.... No
Top center............... No
Front center high........ No
I'm willing to write a patch, but I'm wondering what it should look like.
On Mon, Sep 24, 2018 at 1:49 AM Jani Nikula <jani.nikula@linux.intel.com>
wrote:
> On Sat, 22 Sep 2018, Brian Vincent <brainn@gmail.com> wrote:
> > I have a LG 31MU97-B monitor. My understanding is that EDID does not
> have
> > a way to report itself as a 4096x2160 monitor, so it reports itself as a
> > 3840x2160 monitor. The mode that it actually supports for it's native
> > resolution that I've been using looks like this:
>
> A dmesg with drm.debug=14 might prove useful in figuring out what's
> actually going on. Without the user provided mode.
>
> BR,
> Jani.
>
>
> --
> Jani Nikula, Intel Open Source Graphics Center
>
[-- Attachment #1.2: Type: text/html, Size: 11104 bytes --]
[-- Attachment #2: Type: text/plain, Size: 160 bytes --]
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
^ permalink raw reply [flat|nested] 5+ messages in thread* Re: 4096x2160 monitor has EDID reporting 3840x2160
2018-09-24 22:32 ` Brian Vincent
@ 2018-09-26 11:27 ` Jani Nikula
2018-09-26 12:09 ` Ville Syrjälä
0 siblings, 1 reply; 5+ messages in thread
From: Jani Nikula @ 2018-09-26 11:27 UTC (permalink / raw)
To: Brian Vincent; +Cc: dri-devel
On Mon, 24 Sep 2018, Brian Vincent <brainn@gmail.com> wrote:
> Thank you for your reply. I took your advice and tried it. None of it
> really surprises me.
>
> The problem seems pretty simple. There is simply nothing in the EDID that
> mentions that it's a 4096x2160 monitor. From looking at the code, I don't
> see any possible code path that would allow it to somehow discover a mode
> higher than what the EDID reports. Even if I did hit the code path that
> infers new modes, the function valid_inferred_mode will reject any
> resolution that's higher. Is there a mechanism for discovering these
> higher modes that I'm missing?
>
> I'm willing to work on a patch that would make this monitor "just work".
> What I'm interested in is what a patch for this would even look like. I
> assume this would need to be added as a "quirk" since the EDID is factually
> wrong.
Let's debug this a bit further first. Also, I think an EDID firmware
(i.e. providing an override EDID from userspace using drm.edid_firmware
module parameter) would be preferrable to quirking. But first things
first.
> Here's the relevant logs:
We can't see from this short snippet if some modes were pruned
earlier. A full dmesg would be preferred.
> Here's my parsed EDID:
The binary EDID would be preferrable, because the parsed EDID is always
limited by the parser.
It would be best to attach such details to a bug report rather than
pollute the list. Would you mind filing a bug over at [1], referencing
this thread, and attaching the details there?
Thanks,
Jani.
--
Jani Nikula, Intel Open Source Graphics Center
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: 4096x2160 monitor has EDID reporting 3840x2160
2018-09-26 11:27 ` Jani Nikula
@ 2018-09-26 12:09 ` Ville Syrjälä
0 siblings, 0 replies; 5+ messages in thread
From: Ville Syrjälä @ 2018-09-26 12:09 UTC (permalink / raw)
To: Jani Nikula; +Cc: Brian Vincent, dri-devel
On Wed, Sep 26, 2018 at 02:27:54PM +0300, Jani Nikula wrote:
> On Mon, 24 Sep 2018, Brian Vincent <brainn@gmail.com> wrote:
> > Thank you for your reply. I took your advice and tried it. None of it
> > really surprises me.
> >
> > The problem seems pretty simple. There is simply nothing in the EDID that
> > mentions that it's a 4096x2160 monitor. From looking at the code, I don't
> > see any possible code path that would allow it to somehow discover a mode
> > higher than what the EDID reports. Even if I did hit the code path that
> > infers new modes, the function valid_inferred_mode will reject any
> > resolution that's higher. Is there a mechanism for discovering these
> > higher modes that I'm missing?
> >
> > I'm willing to work on a patch that would make this monitor "just work".
> > What I'm interested in is what a patch for this would even look like. I
> > assume this would need to be added as a "quirk" since the EDID is factually
> > wrong.
>
> Let's debug this a bit further first. Also, I think an EDID firmware
> (i.e. providing an override EDID from userspace using drm.edid_firmware
> module parameter) would be preferrable to quirking. But first things
> first.
>
> > Here's the relevant logs:
>
> We can't see from this short snippet if some modes were pruned
> earlier. A full dmesg would be preferred.
>
> > Here's my parsed EDID:
>
> The binary EDID would be preferrable, because the parsed EDID is always
> limited by the parser.
>
> It would be best to attach such details to a bug report rather than
> pollute the list. Would you mind filing a bug over at [1], referencing
> this thread, and attaching the details there?
[1] https://bugs.freedesktop.org/enter_bug.cgi?product=DRI&component=DRM/Intel
--
Ville Syrjälä
Intel
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
^ permalink raw reply [flat|nested] 5+ messages in thread
end of thread, other threads:[~2018-09-26 12:09 UTC | newest]
Thread overview: 5+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2018-09-22 21:29 4096x2160 monitor has EDID reporting 3840x2160 Brian Vincent
2018-09-24 6:49 ` Jani Nikula
2018-09-24 22:32 ` Brian Vincent
2018-09-26 11:27 ` Jani Nikula
2018-09-26 12:09 ` Ville Syrjälä
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.