It is important for us to be able to run our minis at 1600x1200 on linux. This bug is going to track the creation of a xorg.conf file that does this as well as a puppet manifest patch that could deploy this change.
I think I have found the issue that caused this not to work before. There was another area in the config file that had to be set. I have a xorg.conf file here that has convinced the mac mini to run at 1600x1200 with the proper gnome-panel and window manager sizing (see bug 593874 comment 22 for background). I still need to verify that these changes stick on reboot. xorg.conf soon to be attached.
Created attachment 511234 [details] new 1600x1200 xorg.conf this is a xorg.conf that will properly set the resolution to 1600x1200. tested to keep resolution after reboot, not tested on 64bit, not tested with staging runs.
Created attachment 511243 [details] [diff] [review] changes to the puppet-manifests to deploy a new xorg.conf file I still need to test this change and will test the 64bit change at the same time (should be identical xorg.conf file for both) that I test the puppet changes.
Good thing we run through staging. I forgot that the 64bit files will need to have slightly different paths Section "Files" ModulePath "/usr/lib/xorg/modules/extensions/nvidia" ModulePath "/usr/lib/xorg/modules" EndSection needs to be /usr/lib64 for 64bit versions. Also, this will only take affect after the second reboot. The first reboot will install the xorg.conf file, but the old xorg.conf file will be used for that boot. The second reboot will start up X with the newly deployed xorg.conf
(In reply to comment #5) > needs to be /usr/lib64 for 64bit versions. I have verified that this fixed the 64bit machines and they are now starting with an X11 server running at 1600x1200 with gnome-panel and metacity using proper placement.
Created attachment 511435 [details] new 1600x1200 xorg.conf for x86_64 this file is needed for 64bit versions of fedora because they use a different directory for the native libraries (/usr/lib64 instead of /usr/lib)
(In reply to comment #5) > Also, this will only take affect after the second reboot. The first reboot will > install the xorg.conf file, but the old xorg.conf file will be used for that > boot. The second reboot will start up X with the newly deployed xorg.conf > I had the same circumstance with the darwin machines. I removed the DO_NOT_START file after the second reboot. BTW it might help you to run this on the staging master that does not receive sendchanges and run a manual sendchange. This way is easier to compare any oranges that show up with a given changeset on tbpl. Another note, check that you don't add more slaves into the pool without checking that it really points to staging puppet. It bit me hard last time. This is fantastic progress. I am glad it was this easy after all. Please let me know when you feel confident about getting this in. I would deploy it for you on a short downtime any of the EST mornings next week.
jhford will be buildonduty next week. I will drive this to completion and will deploy this with the next downtime.
Created attachment 512555 [details] [diff] [review] [puppet] manage xorg.conf through puppet module
easy way to check that it is the right resolution over ssh is to run DISPLAY=:0 xrandr | grep current
Comment on attachment 512555 [details] [diff] [review] [puppet] manage xorg.conf through puppet module http://hg.mozilla.org/build/puppet-manifests/rev/6bfd8419ce06
I have updated the ref machines and documented the changes: https://wiki.mozilla.org/ReferencePlatforms Nothing left to be done.