Bug 48477 - Support for non-standard modes is missing
Summary: Support for non-standard modes is missing
Status: CLOSED FIXED
Alias: None
Product: DRI
Classification: Unclassified
Component: DRM/Intel (show other bugs)
Version: XOrg git
Hardware: x86 (IA32) Linux (All)
: highest critical
Assignee: Daniel Vetter
QA Contact:
URL:
Whiteboard:
Keywords:
Depends on:
Blocks: 42991 44622
  Show dependency treegraph
 
Reported: 2012-04-09 13:04 UTC by Rodrigo Vivi
Modified: 2016-09-23 10:20 UTC (History)
5 users (show)

See Also:
i915 platform:
i915 features:


Attachments
Xrandr output (8.57 KB, text/plain)
2012-04-09 13:04 UTC, Rodrigo Vivi
no flags Details
decoded EDID (2.76 KB, application/octet-stream)
2012-04-09 13:05 UTC, Rodrigo Vivi
no flags Details
Test patch for X intel driver (8.23 KB, patch)
2012-04-10 07:52 UTC, Takashi Iwai
no flags Details | Splinter Review

Note You need to log in before you can comment on or make changes to this bug.
Description Rodrigo Vivi 2012-04-09 13:04:45 UTC
Created attachment 59694 [details]
Xrandr output

We are missing support to some standard modes like 1600x900 (aka HD+). Some customers complaining about it after using external monitor native 1600x900.

I don't have here a native 1600x900 monitor, but I do have a monitor that supports this resolution and it is well identified on Windows. Windows add many more modes than us to the same monitor:

Missing modes:

960x600
1280x768
1280x800
1360x768
1366x768
1400x1050
1440x900
1600x900
1680x1050

All modes supported/identified/added by Windows:

800x600
960x600
1024x768
1280x720
1280x768
1280x800
1280x1024
1360x768
1366x768
1400x1050
1440x900
1600x900
1600x1200
1680x1050
1920x1080
1920x1200

All modes can be saw on attached xrandr.output as well edid. I'm going to attatch the edid decoded anyway and also put further info on next comments.
Comment 1 Rodrigo Vivi 2012-04-09 13:05:30 UTC
Created attachment 59695 [details]
decoded EDID
Comment 2 Rodrigo Vivi 2012-04-09 13:09:17 UTC
I doesn't seem that we are missing support for standard modes because these modes aren't CEA modes. CVT/GTF modes are already supported as well and it seems that we aren't missing any other edid blocks... there is not enough space for all these modes.
So we need further ideas in order to add missing modes like this.
Comment 3 Chris Wilson 2012-04-09 13:22:34 UTC
The missing non-native modes is bug 37858, which traditionally requires adding the common modes to hw/xfree86/common/extramodes.

However, the primarily concern of this bug is that we fail to ascertain the native 1600x900 mode on those panels.

Rodrigo, can you grab the information pertaining to those failures?
Comment 4 Jesse Barnes 2012-04-09 13:27:41 UTC
IIRC the biggest failure is the failure to detect native 16x9 modes on both eDP and external DP, right?

If so, we need to get the EDID and VBT from the failing machines to figure out why.  If the modes are present in the EDID and/or VBT, we must be pruning them out for some reason.  If they're not in EDID or VBT, we need to handle that case properly.

And beyond all that, it sounds like we need to add an "extramodes" pass to the DRM EDID parser as well, to add non-CEA, non-established timings to the mode list just to fill things out.
Comment 5 Rodrigo Vivi 2012-04-10 07:37:33 UTC
Yes, that is right: the biggest failure is in detecting native to detect native 16x9 modes on DP, eDP, HDMI.

I don't have vbt or edid info about the biggest failure here with me, but I've already requested it and will add as soon as possible.

Meanwhile the real question is how to add this extramodes?
Comment 6 Takashi Iwai 2012-04-10 07:51:27 UTC
Well, as far as I understand from the original bug report from HP, it's not about the detection of the native resolution of HD+ panel.  It isn't only about 1600x900, and neither about eDP / DP.  The problem is seen even with the normal HD panel, 1366x768, and LVDS.

There are two issues behind this scene:

1. Not all monitors are nice to provide the laptop-friendly resolutions in EDID.
  Many monitors don't give resolutions like popular 1366x768 or 1600x900, but only the TV standards like 1280x720.  But Intel driver allows only the modes given in EDID.

  When you look at the xrandr output in the attachment, you see that 1366x768 is missing for HDMI.  Thus, you can't clone the native laptop resolution on this HDMI monitor.  That leads to a cloned 1024x768 mode at start up.

2. Intel driver doesn't give the defacto standard modes like 1280x720.
  This also prohibits the proper clone with the external monitor's native resolution.

When I look at the xrandr output of AMD fglrx driver, it seems adding the extra modes blindly.  And, I guess most of monitors do work actually with any such modes.  Windows seems doing similarly, too.

In anyway, I did a quick hack and made a patch to X intel driver, as attached below.  It adds the fixed panel mode of LVDS to the external monitor (if the aspect ratio matches), and also adds some modes to LVDS, too.
Comment 7 Takashi Iwai 2012-04-10 07:52:45 UTC
Created attachment 59733 [details] [review]
Test patch for X intel driver
Comment 8 Rodrigo Vivi 2012-04-10 09:35:21 UTC
Actually there is more modes being added than explicit EDID ones. 
There is also CEA, CVT and GTF modes that are added when it makes sense to add them... not blindly.
When EDID is compatible and CVT or GTF bits are enabled GTF or CVT algorithms are used to calculate the correct timings and modes are added. This was my second suspicious, but I checked the drm_edid code and all modes are there.
My first suspicious were about the CEA modes, that are already being added and in the end I noticed that 1600x900 is not a CEA mode anyway.
My third suspicious were the CVT 3 byte code that allows extra modes, but the code is already there on drm_edid as well.
Daniel suspected about missing EDID blocks, but he noticed that there isn't enough available space for this amount of missing modes anyway.

Note that also 1366x768 are part of the missing mode list. What we need to figure out how to add... I don't believe windows or amd are adding it blindly.
Maybe a bug on CVT/GTF compatibility? 

In our code they are exclusive... so I thought that maybe that was the problem, but in the end I found out that CVT has priority over GTF on EDID specification.

But for LVDS in all cases, the native mode should be on VBT.
Comment 9 Takashi Iwai 2012-04-10 23:44:55 UTC
(In reply to comment #8)
> Actually there is more modes being added than explicit EDID ones. 
> There is also CEA, CVT and GTF modes that are added when it makes sense to add
> them... not blindly.

Right, CVT and GTF might be good to look at than blindly adding some fixed timings.  I still think that the resolution list is fixed in some level, though.

> When EDID is compatible and CVT or GTF bits are enabled GTF or CVT algorithms
> are used to calculate the correct timings and modes are added. This was my
> second suspicious, but I checked the drm_edid code and all modes are there.
> My first suspicious were about the CEA modes, that are already being added and
> in the end I noticed that 1600x900 is not a CEA mode anyway.
> My third suspicious were the CVT 3 byte code that allows extra modes, but the
> code is already there on drm_edid as well.

Yes.  I double-checked and there are no explicit listing, so if any, there must be some convention.

> Daniel suspected about missing EDID blocks, but he noticed that there isn't
> enough available space for this amount of missing modes anyway.
> 
> Note that also 1366x768 are part of the missing mode list. What we need to
> figure out how to add... I don't believe windows or amd are adding it blindly.
> Maybe a bug on CVT/GTF compatibility? 

At least, AMD might add it forcibly.  The all non-EDID modes appearing xrandr have the same values except for hdisplay & vdisplay.  Or, maybe it only evaluates hdisplay & vdisplay from the modeline setting and the rest is calculated internally.  Who knows...

> In our code they are exclusive... so I thought that maybe that was the problem,
> but in the end I found out that CVT has priority over GTF on EDID
> specification.
> 
> But for LVDS in all cases, the native mode should be on VBT.

Hm, do we need to limit the modes for LVDS at all?
I thought the panel fitter is more flexible than the listed modes in VBT.
Comment 10 Jesse Barnes 2012-04-11 09:27:32 UTC
(In reply to comment #9)
> Right, CVT and GTF might be good to look at than blindly adding some fixed
> timings.  I still think that the resolution list is fixed in some level,
> though.

I think we can use the CVT and GTF flags to figure out if it's ok to add a fixed set of "extramodes".

> > But for LVDS in all cases, the native mode should be on VBT.
> 
> Hm, do we need to limit the modes for LVDS at all?
> I thought the panel fitter is more flexible than the listed modes in VBT.

No as long as we have the fitter available, we can assume the panel supports GTF as far as exposed modes go.
Comment 11 Chris Wilson 2012-04-24 06:31:57 UTC
Rodrigo, you mentioned the situation improved upon applying Adam's patches in airlied/drm-next, so what is the current status of this bug? How many missing modes remain?
Comment 12 Rodrigo Vivi 2012-05-03 13:34:38 UTC
ajax's series fix the main problem reported on this bug, so it is being closed as fixed.
Comment 13 Jari Tahvanainen 2016-09-23 10:20:02 UTC
Like said by Rodrigo "..., so it is being closed as fixed."


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.