Comment # 29
on bug 77009
from Garrett
(In reply to comment #28) > Depending on the details of their electrical implementation all PLLs behave > more or less like this. The trick is to know how to find the right numbers > without violating the contrains. yup.. This is a fun one to deal with in the embedded environment (love that scope.). I consider this bug fixed. I am not sure if I am supposed to mark it ok or something. Else I will leave it. I thought about the pll thing. I don't know the HDMI message layer at all. I am not sure it is public knowledge anyhow. To get higher divs, I was thinking a potential algo could go (MUCH easier said than done, I know): 1) Run a setup program each time a hardware change is detected. (EDID or GPU) 2) Test LCD/Panel at various popular refresh rates. a) crank up the pll with your new algo. >> *test* if tv accepted it. (requires a knowledge of protocol to check display state, or have user answer ok with a timeout in case it is not readable) >> save the new div setting (maybe the 10% lower ones to be safe) to a config with a table for that hardware/refresh. 3) on reboot load new optimized saved PLL dividers from the table. And on each refresh rate change use the table. But that said. It does not really matter for me to make it closer. Your new algo with your "arbitrary" 100 limit works well on my hardware. I tested 368 and it looked great, too. 368 vs 100 on 24P made vary little difference too me.
You are receiving this mail because:
- You are the assignee for the bug.
_______________________________________________ dri-devel mailing list dri-devel@xxxxxxxxxxxxxxxxxxxxx http://lists.freedesktop.org/mailman/listinfo/dri-devel
