<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
</head>
<body text="#000000" bgcolor="#FFFFFF">
<div class="moz-cite-prefix">On 08/22/2017 02:28 PM, Adam Jackson
wrote:<br>
</div>
<blockquote type="cite" cite="mid:1503430091.5666.45.camel@nwnk.net">
<pre wrap="">On Tue, 2017-08-22 at 13:20 -0500, Michael Cronenworth wrote:
</pre>
<blockquote type="cite" style="color: #000000;">
<pre wrap="">Related: <a class="moz-txt-link-freetext" href="https://bugzilla.redhat.com/show_bug.cgi?id=1339930" moz-do-not-send="true">https://bugzilla.redhat.com/show_bug.cgi?id=1339930</a>
</pre>
</blockquote>
<pre wrap="">Nak, at least in this form. If these are really common modes then the
DMT spec or similar should define real timings for them, and we should
use those timings rather than pretend GTF can handle it. For example:
</pre>
<blockquote type="cite" style="color: #000000;">
<pre wrap="">+ { 15360, 8640 },
</pre>
</blockquote>
<pre wrap="">hyoscyamine:~% gtf 15360 8640 60
# 15360x8640 @ 60.00 Hz (GTF) hsync: 536.16 kHz; pclk: 11675.42 MHz
Modeline "15360x8640_60.00" 11675.42 15360 16824 18568 21776 8640 8641 8644 8936 -HSync +Vsync
An 11GHz dotclock is slightly unrealistic.
Ideally xf86DefaultModes would be replaced by DMTModes (and the latter
synced with a newer version of that list, eg from drm), because then
you wouldn't have needed to change the ms driver at all.</pre>
</blockquote>
<br>
Thanks for the review. It was adopted from the Intel driver.<br>
<br>
Today, the ms driver and xf86GetDefaultModes() grabs 4:3 modes only
and appends the current display mode on the end, which happens to be
a 16:9 mode on the system I'm using. Using a 2560x1440 mode to play
any 3D application on an Intel IGP does not net a lot of frames per
second. Downscaling to a 4:3 mode to end up with black bars on the
monitor is not ideal either.<br>
<br>
What direction do you want this patch to take? Update the DMT list
(if it needs it) and switch xf86GetDefaultModes() to use DMT?<br>
<br>
<br>
</body>
</html>