From: Alan Swanson
Subject: Re: [SDL] New XFree 4.3 Video Mode Patch
I have a wee amendment that moves the qsort in set_best_resolution
to only occur after failing to find an exact match only. This would
make absolutely sure we get a user set mode.
While I've never had any problems for my normal resolutions (1280x1024,
1024x768, 800x600 & 640,480) while closely examining the output from
qsort I've noticed it doesn't seem to sort the modes fully. These is
one definite wrong at 1152x768 and a few that just look wrong to me.
From a program (attached) I made to examine this more easily. X has
sorted its mode list using the same method as ours (plus frequency),
and our user modes get inserted without any other movement.
On the patch I've made I've also changed cmpmodes to sort on vertical
resolution and then horizontal. Ie vertical is now most significant
bit.
--HG--
extra : convert_revision : svn%3Ac70aab31-4412-0410-b14c-859654838e24/trunk%40642
From: Alan Swanson
Subject: [SDL] New XFree 4.3 Video Mode Patch
The current patch to fix the issues with XFree 4.3 it is a bit of
overkill to a simple problem. Default screen settings should be set in
X, not selected by SDL with environment variables. Any program or user
using non-standard or unset display modes get what they deserve :-)
If you look at the unsorted list of modes returned by X, here's mine;
1280 x 1024 @ 85.0 >
1024 x 768 @ 100.3 > USER
800 x 600 @ 125.5 > SET
640 x 480 @ 124.9 >
1280 x 1024 @ 75.0 ]
1280 x 1024 @ 60.0 ]
1280 x 960 @ 85.0 ] X11
1280 x 960 @ 60.0 ] AUTO
1152 x 864 @ 75.0 ]
1152 x 768 @ 54.8 ]
960 x 720 @ 120.0 ]
...
640 x 400 @ 85.1 ] 256k
576 x 432 @ 150.0 ] 249k PIXEL
640 x 350 @ 85.1 ] 224k COUNT
576 x 384 @ 109.6 ] 221k
...
The user set modes come first followed by X set modes which are ordered
by decreasing number of pixels and refresh.
The reason why every other library or program not using SDL was working
is due to SDL scanning the modes in reverse getting X11 provided modes
modes with the lowest refresh.
The solution is to scan forward for the first user set mode or highest X
mode. The qsort still keeps user set modes above higher refresh modes
added by X.
For the best match we still reverse search for the nearest larger size
and then try to find a higher version of it.
--HG--
extra : convert_revision : svn%3Ac70aab31-4412-0410-b14c-859654838e24/trunk%40638
From: Stephen Anthony <stephena@roadrunner.nf.net>
Subject: [SDL] First patch concerning 4.3 and refresh rates
OK, here's my first draft of the patch for the above subject.
A short explanation:
X 4.3 introduces many more modelines than older versions. This would be
fine, except it introduces many modes with the *same* resolution but
different refresh rates. And SDL won't necessarily pick the one with the
highest refresh rate.
So this patch restores SDL to X 4.2 functionality. That is, there is only
ever one refresh rate *per* resolution, and it is the highest possible.
This functionality can be totally disabled by using the environment
variable 'SDL_VIDEO_X11_USE_ALL_MODES' set equal to 1.
--HG--
extra : convert_revision : svn%3Ac70aab31-4412-0410-b14c-859654838e24/trunk%40615
From: Wilbern Cobb
Subject: OpenBSD/sparc64 video init fix
This patch fixes remote X sessions on OpenBSD/sparc64.
--HG--
extra : convert_revision : svn%3Ac70aab31-4412-0410-b14c-859654838e24/trunk%40608
From: Ragnvald "Despair" Maartmann-Moe IV
Subject: SDL x11 video mode selection bug
Hi, I've found an oddity with video mode selection. I recently added a bunch of
oddball video modes to my XF86Config, to support weird resolutions xine &
mplayer need if I don't want to beat my cpu up with video scaling.
Since adding them, SDL started picking the biggest video mode it could find
that matched the height constraint. Getting a narrow vertical strip of
QuakeForge (I code for the project, so needless to say it's my favorite test)
in the middle of an 800x480 screen, instead of the 640x480 I asked for
annoys me tremendously.
So here's a patch that tries a bit harder to get an exact match. I didn't
touch the XiG section, since I can't test that, but I'd bet a similar patch
would prevent similar problems there.
--Ragnvald "Despair" Maartmann-Moe IV
--HG--
extra : convert_revision : svn%3Ac70aab31-4412-0410-b14c-859654838e24/trunk%40605
Subject: SDL CVS patches
below you will find some small patches against the
current SDL CVS.
It adresses these things:
1) Use "&" instead of "%" in some cases. For negative
signed integers (x % 8) is not always (x & 7),
and the compiler can produce slightly faster
code when using "&" here.
2) Some const issues.
--HG--
extra : convert_revision : svn%3Ac70aab31-4412-0410-b14c-859654838e24/trunk%4092
