<div dir="ltr"><div><div><div>I've tried commenting out these five lines in ./drivers/gpu/drm/i915/intel_dp.c, which perform the BIOS-induced clamping:<br><br><span style="font-family:monospace,monospace"> if (dev_priv->vbt.edp_bpp && dev_priv->vbt.edp_bpp < bpp) {<br> DRM_DEBUG_KMS("clamping bpp for eDP panel to BIOS-provided %i\n",<br> dev_priv->vbt.edp_bpp);<br> bpp = dev_priv->vbt.edp_bpp;<br> }</span><br><br></div>The drivers now report using 24bpp (kern.log is attached), but the flickering is still there.<br><br></div><div>I am at a loss as to what to try next.<br></div><div><br></div><div>Should I (blindly) try quirks which have helped with other Samsung panels, such as EDID_QUIRK_DETAILED_SYNC_PP or EDID_QUIRK_PREFER_LARGE_60?<br></div><div><br></div>Thanks,<br><br></div>Jordi.<br><br></div><div class="gmail_extra"><br><div class="gmail_quote">2015-11-16 0:46 GMT+01:00 Jordi Salvat i Alabart <span dir="ltr"><<a href="mailto:jordi.salvat.i.alabart@gmail.com" target="_blank">jordi.salvat.i.alabart@gmail.com</a>></span>:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div><div><div><div>Hi Albert,<br><br></div>thanks a lot for your help. Unfortunately the patches didn't help (I tried the 8bit, I was still getting the flickering, so I ignored your 2nd piece of advice and tried the 12bit just in case). They all show exactly the same flickering :'-(<br><br></div>I'm attaching kern.log for a boot with the 8bit version.<br><br></div>I have a hard time reading the logs (I've been using Linux since 1994, but never messed with display stuff), but if I grep for lines mentioning "bpp", I see that the where Ubuntu kernel logged this:<br><br><span style="font-family:monospace,monospace">[drm:connected_sink_compute_bpp] clamping display bpp (was 36) to EDID reported max of 18</span><br><br></div>The same kernel with your 8bit fix logs this:<br><br><span style="font-family:monospace,monospace">[drm:connected_sink_compute_bpp] clamping display bpp (was 36) to EDID reported max of 24<br>[drm:intel_dp_compute_config] clamping bpp for eDP panel to BIOS-provided 18</span><br><br><div><div><div><div>So it looks like your patch took effect, but was overridden by some BIOS setting? Any idea on how to stop this from happening?<br><br></div><div>Thanks,<br></div><div><br></div><div>Jordi.<br><br></div></div></div></div></div><div class="HOEnZb"><div class="h5"><div class="gmail_extra"><br><div class="gmail_quote">2015-11-11 10:25 GMT+01:00 Albert Freeman <span dir="ltr"><<a href="mailto:albertwdfreeman@gmail.com" target="_blank">albertwdfreeman@gmail.com</a>></span>:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">On 11 November 2015 at 07:21, Jordi Salvat i Alabart<br> <div><div><<a href="mailto:jordi.salvat.i.alabart@gmail.com" target="_blank">jordi.salvat.i.alabart@gmail.com</a>> wrote:<br> > Thanks! I'll try this as soon as I can (probably over the weekend) and<br> > report back.<br> ><br> > Regards,<br> ><br> > Jordi<br> ><br> > El dia 10/11/2015 2:27 p. m., "Albert Freeman" <<a href="mailto:albertwdfreeman@gmail.com" target="_blank">albertwdfreeman@gmail.com</a>><br> > va escriure:<br> ><br> >> On 10 November 2015 at 13:10, Albert Freeman <<a href="mailto:albertwdfreeman@gmail.com" target="_blank">albertwdfreeman@gmail.com</a>><br> >> wrote:<br> >> > On 8 November 2015 at 19:05, Jordi Salvat i Alabart<br> >> > <<a href="mailto:jordi.salvat.i.alabart@gmail.com" target="_blank">jordi.salvat.i.alabart@gmail.com</a>> wrote:<br> >> >> Noone? Not even a hint on where I could ask for help?<br> >> >><br> >> >> :'-(<br> >> >><br> >> >><br> >> >><br> >> >> 2015-10-26 0:18 GMT+01:00 Jordi Salvat i Alabart<br> >> >> <<a href="mailto:jordi.salvat.i.alabart@gmail.com" target="_blank">jordi.salvat.i.alabart@gmail.com</a>>:<br> >> >>><br> >> >>> Hi,<br> >> >>><br> >> >>> My new MSI PE60 2QE laptop mounts an Intel i7-5700HQ, which carries<br> >> >>> the<br> >> >>> Integrated Graphics Chipset 5600, and a Samsung 156HL01-102 panel.<br> >> >>><br> >> >>> The display works perfectly when I boot with the "nomodeset" parameter<br> >> >>> in<br> >> >>> the kernel command line -- but then I'm forced to use the framebuffer<br> >> >>> driver, which doesn't allow multiple monitors.<br> >> >>><br> >> >>> With KMS enabled (by removing the "nomodeset" parameter), X starts<br> >> >>> correctly with the "intel" driver and I can use multiple monitors, but<br> >> >>> the<br> >> >>> laptop's panel shows an irregular flicker, ranging from occasional<br> >> >>> flickering horizontal black lines (which are really annoying) to a<br> >> >>> constant<br> >> >>> flashing & flickering making the display all but unusable.<br> >> >>><br> >> >>> The flickering and flashing is less noticeable, but still there, in<br> >> >>> the<br> >> >>> text-mode VTs, even if I never start X. So the problem has to be in<br> >> >>> the<br> >> >>> kernel or modules, not in the X drivers.<br> >> >>><br> >> >>> External monitors connected to the DP or HDMI ports don't show any<br> >> >>> flickering.<br> >> >>><br> >> >>> Things I have tried (among many others I've discovered were<br> >> >>> irrelevant):<br> >> >>><br> >> >>> Setting a number different video modes using xrandr<br> >> >>> Booting with Kernel 3.19.0.25 with i915.enable_IPS=0 as suggested<br> >> >>> here:<br> >> >>> Screen flickering on Ubuntu Gnome 14.04 - 4K resolution<br> >> >>> Booting with i915.powersave=0<br> >> >>> Booting with acpi_osi=Linux<br> >> >>> Upgrading to Ubuntu Vivid Vervet (kernel 3.19.0 with a backported i915<br> >> >>> module)<br> >> >>> Upgrading to Ubuntu Willy Werewolf (kernel 4.2.0)<br> >> >>><br> >> >>> None of these have helped.<br> >> >>><br> >> >>> I'm attaching kern.log for a full boot sequence with drm.debug=0xf.<br> >> >>><br> >> >>> What steps can you recommend to try to diagnose and solve this<br> >> >>> problem?<br> >> >>><br> >> >>> Thanks a lot for your help,<br> >> >>><br> >> >>> Jordi<br> >> >>><br> >> >><br> >> >><br> >> >> _______________________________________________<br> >> >> mesa-users mailing list<br> >> >> <a href="mailto:mesa-users@lists.freedesktop.org" target="_blank">mesa-users@lists.freedesktop.org</a><br> >> >> <a href="http://lists.freedesktop.org/mailman/listinfo/mesa-users" rel="noreferrer" target="_blank">http://lists.freedesktop.org/mailman/listinfo/mesa-users</a><br> >> >><br> >> > Does this solve the issue (it solves a issue with your monitor) (it is<br> >> > applied ontop of the latest linus kernel tree at time of writing):<br> >> > diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c<br> >> > index 05bb731..44c9422 100644<br> >> > --- a/drivers/gpu/drm/drm_edid.c<br> >> > +++ b/drivers/gpu/drm/drm_edid.c<br> >> > @@ -139,6 +139,9 @@ static struct edid_quirk {<br> >> ><br> >> > /* Panel in Samsung NP700G7A-S01PL notebook reports 6bpc */<br> >> > { "SEC", 0xd033, EDID_QUIRK_FORCE_8BPC },<br> >> > +<br> >> > + /* Panel in Samsung 156HL01-102 display (for notebook) reports<br> >> > 6bpc instead of 8bpc */<br> >> > + { "SDC", 0x324c, EDID_QUIRK_FORCE_8BPC },<br> >> > };<br> >> ><br> >> > /*<br> >> ><br> >> ><br> >> ><br> >> > !!!OR!!! Since the DRM is trying to force part of your monitor into 36<br> >> > bit mode, maybe this:<br> >> ><br> >> ><br> >> ><br> >> > diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c<br> >> > index 05bb731..44c9422 100644<br> >> > --- a/drivers/gpu/drm/drm_edid.c<br> >> > +++ b/drivers/gpu/drm/drm_edid.c<br> >> > @@ -139,6 +139,9 @@ static struct edid_quirk {<br> >> ><br> >> > /* Panel in Samsung NP700G7A-S01PL notebook reports 6bpc */<br> >> > { "SEC", 0xd033, EDID_QUIRK_FORCE_8BPC },<br> >> > +<br> >> > + /* Panel in Samsung 156HL01-102 display (for notebook) reports<br> >> > 6bpc instead of 12bpc */<br> >> > + { "SDC", 0x324c, EDID_QUIRK_FORCE_12BPC },<br> >> > };<br> >> ><br> >> > /*<br> >> Sorry those patches don't apply properly, here are ones that do<br> </div></div>After looking at intel drm driver code more carefully, don't use the<br> 12 bpc one (12 * 3 == 36). The intel drm driver seems to first<br> generate certain values based on your gpu model. It then reduces it<br> based on display stuff (i.e. when I made the 12bpc version of the<br> patch I was looking at the intial value based on gpu model). I don't<br> think your display is capable of 36 bit color (12bpc) as the internet<br> says it only has 95% sRGB (e.g. high end consumer monitor, but not<br> perfect). 36bit is only for photographers and people producing<br> movies/game textures/game environments and other special high end<br> environments. Movies and games and practically every picture on the<br> internet is sRGB which is fully supported by 8 bit stuff. So cd to the<br> kernel source directory and execute git apply 8bit (with the 8bit<br> "patch in the same folder)<br> </blockquote></div><br></div> </div></div></blockquote></div><br></div>