| Summary: | revision 7361 breaks refresh rate information for SDL_GetClosestDisplayMode() | ||
|---|---|---|---|
| Product: | SDL | Reporter: | Marcus von Appen <mva> |
| Component: | video | Assignee: | David Gow <david> |
| Status: | RESOLVED FIXED | QA Contact: | Sam Lantinga <slouken> |
| Severity: | normal | ||
| Priority: | P2 | Keywords: | target-2.0.0 |
| Version: | HG 2.0 | ||
| Hardware: | x86_64 | ||
| OS: | FreeBSD | ||
| Attachments: |
Test program
Only use Xinerama desktop modes when no XRandR available. |
||
Hey David, can you look into this? Thanks! (Sorry if you get a lot of copies of this email, we're touching dozens of bug reports right now.) Tagging a bunch of bugs as target-2.0.0, Priority 2. This means we're in the final stretch for an official SDL 2.0.0 release! These are the bugs we really want to fix before shipping if humanly possible. That being said, we don't promise to fix them because of this tag, we just want to make sure we don't forget to deal with them before we bless a final 2.0.0 release, and generally be organized about what we're aiming to ship. Hopefully you'll hear more about this bug soon. If you have more information (including "this got fixed at some point, nevermind"), we would love to have you come add more information to the bug report when you have a moment. Thanks! --ryan. Created attachment 1222 [details]
Only use Xinerama desktop modes when no XRandR available.
Oops!
Revision 7391 uses Xinerama to add the current modes for each screen, but Xinerama also doesn't provide any refresh rate info.
If we only use Xinerama when we don't have XRandR support, then we'll get the modes, refresh rates intact, from XRandR.
This patch does that, and fixes it for me. It won't add the desktop modes to the list if they're not in XRandR, but if someone's X config is screwed up that much there are probably bigger problems.
-- David
The patch works for me. Thanks! Great work, thanks guys! http://hg.libsdl.org/SDL/rev/0fc94f315dac |
Created attachment 1218 [details] Test program Up until revision 7361 getting the closest display mode for a certain display also set the correct refresh rate, when the returned value was compared to the currently set display mode. Revision 7361 causes a breakage, leaving the refresh rate empty. A test program is attached, which shows the following output for me: Modes differ for display 0: Display mode: { 370546692, 1920, 1080, 0 } Closest mode: { 370546692, 1920, 1080, 60 } Is the difference in behaviour wanted or unintended?