https://bugzilla.kernel.org/show_bug.cgi?id=82781 --- Comment #9 from Alex Deucher <alexdeucher@xxxxxxxxx> --- (In reply to Christian Birchinger from comment #7) > Yes, that patch would indeed fix it in my case. > > I was pretty sure i took standard VESA modes and the fact that Windows > Generic Monitor (no overrides or "hacks" there) values also using the same > timings tells > me that they re rather "normal" modes. > > i'm going to take your fix and live with it because i prefer when all my > screen > modes remain exactly the same between OS switches. > > But for curiosity reasons. Do you have a suggestion for mode sources with > higher > vblank pauses which are still considered "standard" and not totaly uniq and > custom? Or might it be possible my 85 Hz value simply has this 450 as > standard. > There's nothing wrong with the modes or non-standard about a mode with a 450 us vblank time. The issue is it takes 450 us for the mclk to change. It just so happens that when the vblank period is the same as the switch limit so there is very little margin for error. As for tweaking your modeline, you can try adjusting the htotal or vblank_end parameters. CRT multi-sync monitors are pretty flexible when it comes to timing. You can use gtf of cvt to generate vesa compatible modelines. e.g., $ gtf 1600 1200 85 # 1600x1200 @ 85.00 Hz (GTF) hsync: 107.10 kHz; pclk: 234.76 MHz Modeline "1600x1200_85.00" 234.76 1600 1720 1896 2192 1200 1201 1204 1260 -HSync +Vsync $ cvt 1600 1200 85 # 1600x1200 84.95 Hz (CVT 1.92M3) hsync: 107.21 kHz; pclk: 235.00 MHz Modeline "1600x1200_85.00" 235.00 1600 1728 1896 2192 1200 1203 1207 1262 -hsync +vsync your mode: [ 30.543] (II) RADEON(0): Modeline "1600x1200"x85.0 229.50 1600 1664 1856 2160 1200 1201 1204 1250 +hsync +vsync (106.2 kHz eP) gtf was the vesa formula used for CRTs and cvt is the newer formula designed for DFPs. I'm not sure how your modes were generated, but they don't seem to follow either gtf or cvt. Both the gtf (540 us vblank period) and cvt (558 us vblank period) modes should work fine as there is pleny of margin. -- You are receiving this mail because: You are watching the assignee of the bug. _______________________________________________ dri-devel mailing list dri-devel@xxxxxxxxxxxxxxxxxxxxx http://lists.freedesktop.org/mailman/listinfo/dri-devel
