<br><div class="gmail_quote">On Mon, Jun 23, 2008 at 9:57 AM, Alex Deucher <<a href="mailto:alexdeucher@gmail.com">alexdeucher@gmail.com</a>> wrote:<br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<div><div></div><div class="Wj3C7c">On Mon, Jun 23, 2008 at 11:14 AM, Don Waugaman <<a href="mailto:dpw@cs.arizona.edu">dpw@cs.arizona.edu</a>> wrote:<br>
> Greetings,<br>
><br>
> I have an asymmetric dualhead setup - 1920x1200 LCD on the left,<br>
> 1600x1200 CRT on the right - and I'm trying to get a static xorg.conf<br>
> setup working without resorting to xrandr every time I log in. (Getting<br>
> the screen resolution to native on the LCD monitor under GDM would be a<br>
> plus.)<br>
><br>
> I'm using Fedora 9 with xorg-x11-drv-ati-6.8.0-14 on an ATI 9550-based<br>
> card, by the way.<br>
><br>
> Upon X startup, the LCD sets itself to 1600x1200:<br>
><br>
> Screen 0: minimum 320 x 200, current 3520 x 1200, maximum 3520 x 1200<br>
> VGA-0 connected 1600x1200+1600+0 (normal left inverted right x axis y<br>
> axis) 0mm x 0mm<br>
> 1600x1200@75Hz 75.0*+<br>
> 1360x768 59.8<br>
> 1152x864 60.0<br>
> 1024x768 60.0<br>
> 800x600 60.3<br>
> 640x480 59.9<br>
> DVI-0 connected 1600x1200+0+0 (normal left inverted right x axis y axis)<br>
> 518mm x 324mm<br>
> 1920x1200 60.0 + 60.0<br>
> 1600x1200 60.0* 60.0<br>
> 1680x1050 60.0<br>
> 1600x1024 60.2<br>
> 1400x1050 74.8 70.0 60.0<br>
> 1280x1024 75.0 60.0 60.0<br>
> 1440x900 59.9<br>
> 1280x960 60.0 60.0<br>
> 1360x768 59.8<br>
> 1152x864 75.0 75.0 75.0 70.0 60.0<br>
> 1024x768 75.1 75.0 70.1 60.0<br>
> 832x624 74.6<br>
> 800x600 72.2 75.0 60.3 56.2<br>
> 640x480 75.0 72.8 72.8 75.0 66.7 60.0<br>
> 59.9<br>
> 720x400 70.1<br>
> S-video disconnected (normal left inverted right x axis y axis)<br>
><br>
> I can change it to use 1920x1200, and also rebase the VGA to the<br>
> screen's right to eliminate the overlap, but I'd prefer to not have to<br>
> do this every time I log in.<br>
><br>
> I noticed the following lines in my Xorg.0.log:<br>
><br>
> (II) RADEON(0): Using user preference for initial modes<br>
> (II) RADEON(0): Output VGA-0 using initial mode 1600x1200@75Hz<br>
> (II) RADEON(0): Output DVI-0 using initial mode 1600x1200<br>
><br>
> which seems odd since my preference in the file is for the 1920x1200<br>
> mode. Is there a bug in the X server preventing this from being<br>
> selected somehow? Is it selecting a mode to match the CRT head?<br>
><br>
> Also, periodically the X server's CPU utilization goes through the roof,<br>
> and interactivity pauses briefly. After about 3-5 seconds, it picks<br>
> back up again. These pauses are annoying, and they really interfere<br>
> with the work cycle - is there a way to figure out why this is happening<br>
> and what can be done about it?<br>
><br>
> If there is a better forum for asking these kinds of questions, feel<br>
> free to direct me to it.<br>
><br>
> I'm attaching my current xorg.conf, I can send the server log as well if<br>
> it would help, but it's rather larger and I'd hate to take up so much<br>
> bandwidth.<br>
<br>
</div></div>Wht xserver are you using. I think this has been fixed in git master<br>
and the 1.5rc releases.<br>
<font color="#888888"><br>
Alex<br>
</font></blockquote></div><br>It's the current Fedora xserver package, so it's a little hard to say. :-)<br><br>The rpm version string is 1.4.99, and the source file in the srpm is xorg-xserver-20080612.tar.bz2. It looks like that was generated by checking out commit #53a84d75c65f75c629c6610a2ec4093507cea3f7 from git://<a href="http://git.freedesktop.org/git/xorg/xserver">git.freedesktop.org/git/xorg/xserver</a>, assuming that my rpm-fu is strong enough to understand the setup.<br>
<br>It appears, though, that this didn't come from the server-1.5-branch, since that's in the other arm of the script used to make the git snapshot. So it looks like I'll have to wait for a 1.5-based server to make this work.<br>
<br>Out of curiousity, is there a way to look for the commit that fixed this? I could try turning it into a patch and rebuilding the rpm to see if it fixed the problem.<br><br>Thanks,<br><br>Don<br><br>