On Mon, Apr 20, 2015 at 03:06:30PM +0200, Radek Dostál wrote:
Hi Chris,
On 04/20/2015 02:26 PM, Chris Wilson wrote:
The intention of using video=<connector>:<mode: is primarily to select the user's preferred resolution at startup. Currently we always create a GTF mode irrespective of whether the monitor has a native mode at the desired resolution. This has the issue that we may then select the fake GTF mode rather the native mode during fb_helper->inital_config() and so on a non-GTF monitor we then end up with a loss of signal. Oops. This invalid fake mode would also be exported to userspace, who potentially may make the same mistake.
To avoid this issue, we filter out the added command line mode if we detect the desired resolution (and clock if specified) amongst the probed modes. This fixes the immediate problem of adding a duplicate mode, but perhaps more generically we should avoid adding a GTF mode if the monitor has an EDID that is not GTF-compatible...
A second issue sneaked into this patch is to add the cmdline mode mode ahead of the absolute fallback 1024x768 mode. That is if the user has specified a mode that we create as a fallback, we do not need to add a second unused fallback mode.
Fixes regression from
commit eaf99c749d43ae74ac7ffece5512f3c73f01dfd2 Author: Chris Wilson chris@chris-wilson.co.uk Date: Wed Aug 6 10:08:32 2014 +0200
drm: Perform cmdline mode parsing during connector initialisationthat breaks HDMI output on BeagleBone Black with LG TV (model 19LS4R-ZA).
Reported-by: Radek Dostál rd@radekdostal.com Signed-off-by: Chris Wilson chris@chris-wilson.co.uk Cc: Radek Dostál rd@radekdostal.com Cc: Jesse Barnes jbarnes@virtuousgeek.org Cc: Ville Syrjälä ville.syrjala@linux.intel.com Cc: Daniel Vetter daniel.vetter@ffwll.ch Cc: dri-devel@lists.freedesktop.org Cc: Julia Lemire jlemire@matrox.com Cc: Dave Airlie airlied@redhat.com Cc: stable@vger.kernel.org
NAKed-by: Radek Dostál rd@radekdostal.com
sorry to let you know, but this patch does NOT work :( Attached is the original.patch which you provided previously and it did work, but one of the last minute changes had to break it :(
The original patch relied on the MODE_UNVERIFIED being retained by the unwanted cmdline mode. This patch relies on overwriting the existing unwanted mode->status with MODE_BAD by drm_mode_connector_list_update(). I made that change because the first version would have deleted all user modes and not just our fake cmdline mode.
Alternatively we could do a loop over the old modes, remove the fake then loops over probed modes and only add if it we don't match. Let's try that... -Chris