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.
Created attachment 59695 [details] decoded EDID
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.
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?
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.
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?
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.
Created attachment 59733 [details] [review] Test patch for X intel driver
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.
(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.
(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.
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?
ajax's series fix the main problem reported on this bug, so it is being closed as fixed.
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.