Bug#229850: xserver-xfree86: Nokia 446Xpro properly detected but sync incorrect
With this patch to xserver-xfree86.config
--- /var/lib/dpkg/info/xserver-xfree86.config 2004-03-17 23:33:04.000000000 -0500
+++ /tmp/xserver-xfree86.config.mod 2004-04-24 18:49:01.000000000 -0400
@@ -1681,8 +1681,8 @@
esac
;;
Advanced)
- auto_answer validate_monitor_frequency_db_input "$(priority_ceil $PRIORITY)" xserver-xfree86/config/monitor/horiz-sync "28-50"
- auto_answer validate_monitor_frequency_db_input "$(priority_ceil $PRIORITY)" xserver-xfree86/config/monitor/vert-refresh "43-75"
+ auto_answer validate_monitor_frequency_db_input "$(priority_ceil $PRIORITY)" xserver-xfree86/config/monitor/horiz-sync $DEFAULT_HORIZ_SYNC
+ auto_answer validate_monitor_frequency_db_input "$(priority_ceil $PRIORITY)" xserver-xfree86/config/monitor/vert-refresh $DEFAULT_VERT_REFRESH
;;
esac
the detected horizontal sync and vertical refresh show up as the
defaults when the advanced monitor selection method is used. With
this patch, the correct horizontal sync and vertical refresh rates
show up in my XF86Config-4 file.
As for my earlier comment about the video modes, I see that there is
no attempt to compute possible video modes. I think the X
configuration software should offer the highest video modes
supported. I'm pretty sure this can be computed from the available
information. After all, the X server is able to determine whether a
video mode is too high, and other distributions' X configuration
programs have been able to give me 1152x864 on this hardware for some
time without my having to override anything.
With respect to the above patch, the code in xserver-xfree86.config
definitely seems to be written with this intention. Prior to this
patch, the variables DEFAULT_HORIZ_SYNC and DEFAULT_VERT_REFRESH are
not used after being set to the results found by get-edid. (Search
for "get-edid reports", then search for "DEFAULT_HORIZ_SYNC".) The
names of the variables certainly suggest that they should be used for
this purpose. They are also unconditionally set to the previous
values (28-50, 43-75) so that in the case where get-edid does not
report something, this patch doesn't change the behavior. In other
words, this patch seems very safe. I hope you will consider including
it.
--
Jay Berkenbilt <ejb@ql.org>
http://www.ql.org/q/
Reply to: