Re: [BUG] HDMI 12bpc causing occasional flickering and blanking

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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




[Index of Archives]     [Linux USB Devel]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]
  Powered by Linux