Apparently the TargetRefresh option for xorg.conf has been removed, making it impossible to precisely select an initial mode. For example, my TV set correctly reports over HDMI that it can do 1280x720 at both 50 and 60 Hz. Using the PreferredMode option I can select this mode: Option "PreferredMode" "1280x720" but the server implicitly select the 60Hz version. Workaround #1: Use xrandr to select the correct mode once X is up. Downside: briefly, a wrong mode is chosen causing a mode input switching lag on the monitor. Workaround #2: Limit the monitor's vertical refresh capabilities to only handle up to 50 Hz. Downside is that you loose the ability to use 60Hz modes entirely. Workaround #3: Define a special modeline with a more telling name, eg. 1280x780_50. Downside: if you use video=1280x720@50 on the kernel command line, the correct EDID reported mode is selected at first, during early boot. When X then activates the manually defined mode, it is a different mode and the monitor will respond with a (device dependent, ~4sec on my TV) input switching lag. Either the TargetRefresh option should be revived, or the PreferredMode option should be allowing to specify a refresh rate.
TargetRefresh was removed by: http://cgit.freedesktop.org/xorg/xserver/commit/?id=1a8c89683ff40cdd1d33da89ab47e7bd240b9bb7
(In reply to comment #1) > TargetRefresh was removed by: > http://cgit.freedesktop.org/xorg/xserver/commit/?id=1a8c89683ff40cdd1d33da89ab47e7bd240b9bb7 Thanks for this link. The commit message states: > Without this option, the default is to prefer modes with higher refresh rates. This sounds to me like a regression. What could be an acceptable way to allow for a static setting in xorg.conf to choose a certain refresh rate? To give more some context and justification: I encountered this regression with a home theater system, where you really want to accurately control refresh rates. I live a PAL country, so TV content comes at 25fps so its crucial to use a multiple of this for the screen refresh rate. As I said above, fixing things up with xrandr is sub-optimal because of the annoyingly visible mode change.
*bump* I'd really appreciate to get some insider opinion on this issue? Is there a work-around I'm missing? Does anyone have a plan to fix this? Thanks!
(In reply to comment #3) > I'd really appreciate to get some insider opinion on this issue? Is there a > work-around I'm missing? Does anyone have a plan to fix this? Mailing the xorg-devel mailing list would be the best way to get developer opinion - we really don't do design discussions in bugzilla.
You can specify the complete modeline via your xorg.conf. e.g., Modeline "1280x720_50.00" 60.50 1280 1328 1456 1632 720 723 728 744 -hsync +vsync Option "PreferredMode" "1280x720_50.00"
(In reply to comment #5) > You can specify the complete modeline via your xorg.conf. e.g., > > Modeline "1280x720_50.00" 60.50 1280 1328 1456 1632 720 723 728 744 -hsync > +vsync > Option "PreferredMode" "1280x720_50.00" I know this and I mentioned it in the initial report as work-around #3. But a mode line defined like this is in some internal ways different from the console mode video=1280x720@50 (*) and thus will cause the TV set to resync. No good user experience. Thanks anyway for trying to help. (*) Well if video=1280x720@50 would even work, see https://bugs.freedesktop.org/show_bug.cgi?id=30325 Perhaps you begin to understand my frustration, all this used to work and now the pieces are falling apart again... sigh!
The TargetRefresh option isn't coming back, at least not unless someone writes a patch. The method given for specifying a complete modeline is correct; if the driver doesn't work, that's the driver's issue.
Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.