Closed Bug 1029614 Opened 10 years ago Closed 10 years ago

Make screenresolution configurable for specific resolutions

Categories

(Infrastructure & Operations :: RelOps: Puppet, task)

All
macOS
task
Not set
normal

Tracking

(Not tracked)

RESOLVED FIXED

People

(Reporter: whimboo, Assigned: whimboo)

References

Details

Attachments

(1 file, 1 obsolete file)

When I run puppet agent on one of our OS X slave hosts for QA, I get the following errors from screenresolution:

Notice: /Stage[main]/Disableservices::Common/Exec[disable-panic-reporting]/returns: executed successfully
Notice: /Stage[main]/Screenresolution/Exec[set-resolution]/returns: 2014-06-24 09:27:39.272 screenresolution[4181:707] starting screenresolution argv=/usr/local/bin/screenresolution set 1600x1200x32@60 
Notice: /Stage[main]/Screenresolution/Exec[set-resolution]/returns: 2014-06-24 09:27:39.277 screenresolution[4181:707] Error: mode 1600x1200x32@60.000000 not available on display 0
Error: /usr/local/bin/screenresolution set 1600x1200x32@60 returned 1 instead of one of [0]
Error: /Stage[main]/Screenresolution/Exec[set-resolution]/returns: change from notrun to 0 failed: /usr/local/bin/screenresolution set 1600x1200x32@60 returned 1 instead of one of [0]

Dustin said, that we need an EDID to use that resolution. But we don't really need that. So maybe we should better parametrize the screenresolution module.
Summary: puppet steps for screenresolution error out → puppet steps for screenresolution error out with resolution not available
Without having changed anything it worked now:

Notice: /Stage[main]/Disableservices::Common/Exec[disable-panic-reporting]/returns: executed successfully
Notice: /Stage[main]/Screenresolution/Exec[set-resolution]/returns: executed successfully
Notice: Finished catalog run in 19.46 seconds
Ok, as it looks like this problem only exists when when a client is connected via VNC/screensharing to this host, and the builder user is logged in. Given that we run puppet only during startup, this should be an issue.

But I would still like to reduce the screensize. 1600x1200x32@60 is way too much for us, and also slows down VNC/screensharing.
Summary: puppet steps for screenresolution error out with resolution not available → Make screenresolution configurable for specific resolutions
Actually the reason why it was working is that I accidentally tried to run puppet with my environment, which had 1024x768 set as screen resolution.

Further investigation has shown that on our boxes we cannot set 1600x1200 given that we don't have such EDID boxes attached. Dustin, mind giving me details what this is? Maybe we should also attach those?

At least on OS X 10.9 I can see that 1024x768 can not be chosen. It may be that no display is attached. Even pressing the option-key + clicking the scaled radiobutton doesn't show me any available list of resolutions. So may be we will be limited to 1200x1024 on OS X for now.

I will test on Ubuntu and if all works, a patch will be ready soon.
EDID is the protocol that screens use to communicate their available resolutions back to the OS.  When no screen is attached, macs continue to list a few resolutions as available, but make GPU operations a no-op since there's no output attached.

For Talos, we need to get accurate timings from the GPU, so we have to fool the system into thinking there's a screen attached.  We do this with EDID's that look something like
  http://www.extron.com/product/product.aspx?id=edid101v
(I don't remember the exact model).  They're programmed against a real monitor, and then connected, one to each mac.  So we have lots of racks of EDIDs interspersed with racks of macs.

The older solution, for the r3 minis, was custom-built "dongles" which fit into the VGA adapter, with a few carefully selected resistors tied across certain pins.  This didn't seem to fool r4 and later minis, though, so we went with the more expensive EDID option.  Even so, the EDIDs fail periodically (causing failed puppet runs) and must be fixed by dcops.
The expected screensize get correctly set for xvfb on Ubuntu. Sadly I cannot test it for gpu_on and virtual given that in this case we don't have the xorg.conf present at the moment. See bug 1027345.
Depends on: 1027345
Attached patch screenresolution v1 (obsolete) — Splinter Review
Attachment #8445881 - Flags: review?(dustin)
Comment on attachment 8445881 [details] [diff] [review]
screenresolution v1

Review of attachment 8445881 [details] [diff] [review]:
-----------------------------------------------------------------

Looks good aside from two typos.

::: modules/toplevel/manifests/slave/releng/test/gpu.pp
@@ +8,5 @@
> +            on_gpu => true,
> +            screen_width => 1600,
> +            screen_height => 1200,
> +            screen_depth => 32,
> +            refresh = 60>;

Extra '>' (same below)
Attachment #8445881 - Flags: review?(dustin) → review+
Comment on attachment 8445881 [details] [diff] [review]
screenresolution v1

Review of attachment 8445881 [details] [diff] [review]:
-----------------------------------------------------------------

::: modules/toplevel/manifests/slave/releng/test/gpu.pp
@@ +8,5 @@
> +            on_gpu => true,
> +            screen_width => 1600,
> +            screen_height => 1200,
> +            screen_depth => 32,
> +            refresh = 60>;

Actually the extra '>' is missing after the equal sign. Not sure why it ended up at the end of the line. Thanks for spotting this. I will fix it in the next version of the patch.
Fixed the two typos as mentioned by Dustin.
Attachment #8445881 - Attachment is obsolete: true
Attachment #8446014 - Flags: review+
http://hg.mozilla.org/qa/puppet/rev/56c14fd88255
Status: ASSIGNED → RESOLVED
Closed: 10 years ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: