On Fri, Feb 19, 2016 at 08:55:02PM +0100, Tore Anderson wrote: > * Tore Anderson > > > * Ville Syrjälä > > > > > Could you test the following hack while using a 1920x1080 mode with > > > 148.5 MHz dotclock, and see if there's any improvement? > > > > I think it might be an improvement, that is, the blanking/flickers > > seems to occur less often than it did with 8ed1804, but it is not > > completely fixed. > > Hi again Ville, > > I spoke too soon. I've been doing some more testing with current Git > master (e7d04bf). I'm now certain that your patch makes no difference > whatsoever, the flickering/blanking is just as bad as before. > > The intensity/frequency of the problems vary significantly, so when I > tested your patch previously I must have hit one of the better periods. > As I write this, however, the computer is essentially rendered > unusable. (I have no idea what causes this variance, unfortunately.) > > Do you (or anyone else for that matter) have any other ideas? "The monitor is connected with a DP+-to-HDMI cable" This and some reading of the DP dual mode spec gave me another idea; The DP->HDMI adaptor may simply be degrading the signal quality too much. According to the DP dual mode spec we're supposed to limit the TMDS clock based on the type of adapter used, but currently we have no code to do that. I've cooked up a few patches that should do what we want: git://github.com/vsyrjala/linux.git dp_dual_mode I've quickly tested it locally, and it seemed to do the right thing with a few different types of adaptors. > > By the way: Is it possible to disable HDMI 12bpc in a way that doesn't > require me to patch and rebuild the kernel drivers, such as a kernel > module parameter or sysfs setting? (I prefer to simply use the upstream > Fedora kernel RPMs, but this issue is currently making that impossible.) We don't have any knob to control this. There is at least one way to do it though, but it's quite involved. What you would need to do is dump the EDID, modify it to indicate that 12bpc isn't supported (and fix up the CRC), and then use the firmware EDID mechanism to override the EDID with the hacked up version. -- Ville Syrjälä Intel OTC _______________________________________________ Intel-gfx mailing list Intel-gfx@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/intel-gfx