I’ve been experimenting with the above, and I’ve found the cause of the
problem. I activated DEBUG mode in SDL, and when I run a sample SDL app,
this is printed to the screen:
X11 video mode list:
1280x1024
1280x1024
1280x960
1152x864
1024x768
1024x768
1024x768
832x624
800x600
800x600
800x600
800x600
800x600
700x525
640x512
640x512
640x480
640x480
640x480
640x480
720x400
640x400
576x432
640x350
512x384
512x384
512x384
416x312
400x300
400x300
400x300
320x240
320x240
320x240
320x200
320x175
When I test on an older Linux using X 4.2.x, the following is the output:
X11 video mode list:
1280x1024
1024x768
800x600
640x480
The second one reflects the modes I have defined in the XF86Config file.
So the problem lies in the fact that X 4.3 finds many more modes, and is
probably using the information provided by the monitor itself (versus
that provided in the XF86Config file). I assume that the duplicates are
for different refresh rates for the same resolution.
The solution is a bit more problematic. What’s the best way to proceed?
We could take the advice that someone mentioned on the list, and create
an environment variable thats holds the desired refresh rate. Then, when
building the modelist, delete all those entries that don’t match that
entry. Or better yet, we could define a variable that represents “use
optimal rate”. This could mean that given duplicate resolutions, only
use the one that has the highest refresh rate.
One problem with this whole solution is that we need a way to calculate
the refresh rate. It’s not given specifically in the modelist, but some
other variables are. I assume there is some formula to use that will
calculate the refresh rate from that.
Any info is appreciated,
Steve
Stephen Anthony wrote:
The solution is a bit more problematic. What’s the best way to
proceed?
We could take the advice that someone mentioned on the list, and create
an environment variable thats holds the desired refresh rate. Then,
when
building the modelist, delete all those entries that don’t match that
entry. Or better yet, we could define a variable that represents “use
optimal rate”. This could mean that given duplicate resolutions, only
use the one that has the highest refresh rate.
One thing we should continue to allow is user-defined modes. For
example, I use my own modeline to get a 200 Hz refresh rate at 640x480.
(Hopefully this capability hasn’t been removed from XFree 4.3 – I
haven’t been keeping up.) That mode is within the supported horizontal
and vertical bandwidth of my monitor, but it’s not typical! As far as
I understand it, multisync monitors should be able to lock onto any
video signal within their bandwidth capabilities, not just a few
standardized modes.
One problem with this whole solution is that we need a way to calculate
the refresh rate. It’s not given specifically in the modelist, but
some
other variables are. I assume there is some formula to use that will
calculate the refresh rate from that.
Any info is appreciated,
Steve
Check this out:
http://www.tldp.org/HOWTO/XFree86-Video-Timings-HOWTO/
Cheers!
Andrew
Stephen Anthony wrote:
The solution is a bit more problematic. What’s the best way to
proceed?
We could take the advice that someone mentioned on the list, and
create an environment variable thats holds the desired refresh rate.
Then, when
building the modelist, delete all those entries that don’t match that
entry. Or better yet, we could define a variable that represents
"use optimal rate". This could mean that given duplicate
resolutions, only use the one that has the highest refresh rate.
One thing we should continue to allow is user-defined modes. For
example, I use my own modeline to get a 200 Hz refresh rate at 640x480.
(Hopefully this capability hasn’t been removed from XFree 4.3 – I
haven’t been keeping up.) That mode is within the supported horizontal
and vertical bandwidth of my monitor, but it’s not typical! As far as
I understand it, multisync monitors should be able to lock onto any
video signal within their bandwidth capabilities, not just a few
standardized modes.
If X allows it, it will be in the SDL modelist. But that raises an
interesting point. How can we know that optimal means the highest? Or
do we just assume that? Optimal can mean different things to different
people. I’m hesitant to create what in effect will be a policy. Do we
always go with the highest? What about when one wants to use a specific
refresh rate? I really think we need a few variables here, like in
Windows. One to represent a specific, user-defined refresh rate, and
another to indicate use the ‘optimal’ refresh rate (whatever optimal may
mean).
One problem with this whole solution is that we need a way to
calculate the refresh rate. It’s not given specifically in the
modelist, but some
other variables are. I assume there is some formula to use that will
calculate the refresh rate from that.
Any info is appreciated,
Steve
Check this out:
http://www.tldp.org/HOWTO/XFree86-Video-Timings-HOWTO/
OK, I’ll check this out.
SteveOn April 7, 2003 11:23 pm, Andrew Straw wrote:
Stephen Anthony wrote:
So the problem lies in the fact that X 4.3 finds many more modes,
and is probably using the information provided by the monitor itself
(versus that provided in the XF86Config file). I assume that the
duplicates are for different refresh rates for the same resolution.
They are. You can verify this by hand by querying the modes yourself
via the XF86VidMode calls (simple test program attached).
Actually, for XFree86 4.3 and above, the XRandR extension is almost
certainly a better choice. The VidMode extension only changes the
screen size. RandR resizes the whole framebuffer, freeing lots of
high-resolution-desktop memory that won’t be used by your game. I
don’t know it as well, but you can play with the “xrandr” command line
client if you like.
One problem with this whole solution is that we need a way to
calculate the refresh rate. It’s not given specifically in the
modelist, but some other variables are. I assume there is some
formula to use that will calculate the refresh rate from that.
Check the sample code. Just divide the dot clock by the line width
(in clocks) times the number of scan lines.
Andy
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed…
Name: xmodes.c
URL: http://lists.libsdl.org/pipermail/sdl-libsdl.org/attachments/20030408/0f9fc009/attachment.asc