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