Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

revision 7361 breaks refresh rate information for SDL_GetClosestDisplayMode() #952

Closed
SDLBugzilla opened this issue Feb 10, 2021 · 0 comments

Comments

@SDLBugzilla
Copy link
Collaborator

This bug report was migrated from our old Bugzilla tracker.

These attachments are available in the static archive:

Reported in version: HG 2.0
Reported for operating system, platform: FreeBSD, x86_64

Comments on the original bug report:

On 2013-07-11 02:21:14 +0000, Marcus von Appen wrote:

Created attachment 1218
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?

On 2013-07-12 01:08:36 +0000, Sam Lantinga wrote:

Hey David, can you look into this?

Thanks!

On 2013-07-12 22:15:24 +0000, Ryan C. Gordon wrote:

(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.

On 2013-07-12 23:14:51 +0000, David Gow wrote:

Created attachment 1222
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

On 2013-07-13 02:29:20 +0000, Marcus von Appen wrote:

The patch works for me. Thanks!

On 2013-07-13 02:52:53 +0000, Sam Lantinga wrote:

Great work, thanks guys!
http://hg.libsdl.org/SDL/rev/0fc94f315dac

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant