After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 580754 - Gnome desktop should re-use the previous screen size when needs_reprobe=FALSE
Gnome desktop should re-use the previous screen size when needs_reprobe=FALSE
Status: RESOLVED DUPLICATE of bug 578111
Product: gnome-desktop
Classification: Core
Component: libgnome-desktop
2.26.x
Other All
: Normal normal
: ---
Assigned To: Desktop Maintainers
Desktop Maintainers
Depends on:
Blocks:
 
 
Reported: 2009-04-29 14:44 UTC by Alberto Milone
Modified: 2009-04-29 22:02 UTC
See Also:
GNOME target: ---
GNOME version: 2.25/2.26


Attachments
Patch which fixes the bug (1.23 KB, patch)
2009-04-29 15:03 UTC, Alberto Milone
none Details | Review

Description Alberto Milone 2009-04-29 14:44:11 UTC
Please describe the problem:
After applying the settings (e.g. changing the screen resolution), if the number of connected outputs didn't change, then fill_out_screen_info() is called with needs_reprobe=FALSE. This is correct but info->min_width, info->min_height, info->max_width and info->max_height are not filled. As a result, they are all set to 0, which causes the Display capplet to believe that the allocated front buffer is not enough (being 0 x 0 ) and prevents the applet from applying a new screen resolution unless the applet is restarted.

Steps to reproduce:
1. Launch the Display capplet
2. Change the screen resolution to a different resolution and apply your settings
3. Repeat step 2 with a different resolution


Actual results:
An error dialog warns the user that the settings cannot be applied.

Expected results:
If the front buffer is enough, the settings should be applied.

Does this happen every time?
yes

Other information:
Solution: Gnome desktop should re-use the previous screen size when needs_reprobe=FALSE in screen_info_new()
Comment 1 Alberto Milone 2009-04-29 15:03:20 UTC
Created attachment 133568 [details] [review]
Patch which fixes the bug
Comment 2 Federico Mena Quintero 2009-04-29 22:02:58 UTC
*** This bug has been marked as a duplicate of 578111 ***