[PATCH v4] drm: Only create a cmdline mode if no probed modes match

On 06/01/2016 11:50 AM, Chris Wilson wrote: > Fixes regression from > > commit eaf99c749d43ae74ac7ffece5512f3c73f01dfd2 > Author: Chris Wilson > Date: Wed Aug 6 10:08:32 2014 +0200 > > drm: Perform cmdline mode parsing during connector initialisation > > that breaks HDMI output on BeagleBone

[PATCH v4] drm: Only create a cmdline mode if no probed modes match

On 06/02/2016 01:30 PM, Ville Syrjälä wrote: > IMO the patch makes total sense even if it's not needed for this > particular bug. Feel free to add I agree and additionally can confirm, that with this patch BBB still works as expected with LG 19LS4R-ZA. Thanks, Radek

BUG Beaglebone HDMI output flickers

Dear All, Beaglebone black display starts to flicker after updating our userspace to GStreamer 1.6 and decoding WMA. We analyzed the change in gstreamer and created simple program, which allow us to reproduce the issue reliably - see attached. When attached program mem-test.c is executed with

[PATCHv2] drm: fb_helper: prefer to use mode, which is not DRM_MODE_TYPE_USERDEF

Hi Chris, On 04/20/2015 11:58 AM, Chris Wilson wrote: > Hmm, so that should be before the clock comparison as well to fix your > example. Not as neat. indeed that is required. > The other idea I was considering was not adding the GTF cmdline mode if > the probed modes already contain one of a ma

[PATCHv2] drm: fb_helper: prefer to use mode, which is not DRM_MODE_TYPE_USERDEF

Hi Chris, On 04/20/2015 12:48 PM, Chris Wilson wrote: >> Unfortunately you can not do that. I already tried. At the time when >> > drm_helper_probe_add_cmdline_mode is called EDID informations are not >> > yet available. > My understanding is that it should be. fb_helper.initial_config does a > pr

[PATCHv2] drm: fb_helper: prefer to use mode, which is not DRM_MODE_TYPE_USERDEF

Hi Chris, On 04/20/2015 01:44 PM, Chris Wilson wrote: > Ah, maybe this on top of the previous try: > > diff --git a/drivers/gpu/drm/drm_probe_helper.c > b/drivers/gpu/drm/drm_probe_helper.c > index 88f5a74..5d22ca0 100644 > --- a/drivers/gpu/drm/drm_probe_helper.c > +++ b/drivers/gpu/drm/drm_pro

[PATCH v2] drm: Only create a cmdline mode if no probed modes match

On 04/20/2015 03:28 PM, Chris Wilson wrote: > The intention of using video=: is primarily to select > the user's preferred resolution at startup. Currently we always create a > new mode irrespective of whether the monitor has a native mode at the > desired resolution. This has the issue that we may

[PATCH] drm: Only create a cmdline mode if no probed modes match

Hi Chris, On 04/20/2015 02:26 PM, Chris Wilson wrote: > The intention of using video=: 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 t

[PATCHv2] drm: fb_helper: prefer to use mode, which is not DRM_MODE_TYPE_USERDEF

Hi Chris, On 04/20/2015 11:09 AM, Chris Wilson wrote: > The EDID modes should be earlier in the list, and so higher priority > than the cmdline mode. The only instance I see that breaking down is if > the mode gets created by drm_pick_cmdline_mode, i.e. indeed at the beginning the command line mo

[PATCHv2] drm: fb_helper: prefer to use mode, which is not DRM_MODE_TYPE_USERDEF

Hi Chris, On 04/20/2015 01:00 PM, Chris Wilson wrote: > Can you do a WARN_ON(list_empty(&connector->modes)) here to see at what > point we set up the invalid GTF mode? sure please see attached patch adding WARN_ON and corresponding output of dmesg. As mentioned in the original commit, the mode is