Bug 426011

Created attachment 289794 [details]
/var/log/Xorg.0.log

Created attachment 289796 [details]
glxinfo output

Incidentally, I just requested bzflag-2.0.10-1.fc8 to be pushed to
updates-testing. It hasn't got there yet, but you can grab it from:

http://koji.fedoraproject.org/koji/buildinfo?buildID=28319

Please check whether the problem still exists with this version.

(In reply to comment #3)
The same problem still exists, no changes.

I suspect that bzflag tries to set a resolution for which your X server isn't
configured. Please create a new attachment with your /etc/X11/xorg.conf (don't
paste it into a comment) and if you have a bzflag configuration file
~/.bzf/2.0/config.cfg, then run the following command and paste its output:

awk '/^[^#].*resolution/ { print; }' ~/.bzf/2.0/config.cfg

Just noticed you've already pasted your xorg.conf. Please _attach_ your
/var/log/Xorg.0.log instead. Thanks.

(In reply to comment #6)
> Just noticed you've already pasted your xorg.conf. Please _attach_ your
> /var/log/Xorg.0.log instead. Thanks.
It's also already attached :-). Please see attachment #289794 [details].

(In reply to comment #5)
> ... "if you have a bzflag configuration file ~/.bzf/2.0/config.cfg"
Just for information, I don't have user specific bzflag configuration file.

(In reply to comment #5)
> I suspect that bzflag tries to set a resolution for which your X server isn't
> configured.
It's strange, because a year or two ago, on the same hardware (fedora rawhide -
before the fedora 6 or 7 was released) bzflag run perfectly.

I'm rebuilding the current version of bzflag without SDL to work around SDL
breakage in this area.

It seems that it was bzflag-induced SDL breakage (bzflag asked SDL to do
something it couldn't, it didn't correctly look for the resolution to set). A
hopefully fixed version builds at the moment.

Created attachment 311460 [details]
patch which fixes finding resolutions at startup

bzflag-2.0.12-3.fc8 has been pushed to the Fedora 8 testing repository.  If problems still persist, please make note of it in this bug report.
 If you want to test the update, you can install it with 
 su -c 'yum --enablerepo=updates-testing update bzflag'.  You can provide feedback for this update here: http://admin.fedoraproject.org/updates/F8/FEDORA-2008-6182

Now I'm using the FC9, thus I've tried to test it using the update version from
rawhide: bzflag-2.0.12-3.fc10.i386 and it gives me the same output:

X Error of failed request:  BadValue (integer parameter out of range for operation)
  Major opcode of failed request:  134 (XFree86-VidModeExtension)
  Minor opcode of failed request:  10 (XF86VidModeSwitchToMode)
  Value in failed request:  0xa7
  Serial number of failed request:  149
  Current serial number in output stream:  151

(In reply to comment #12)
> Now I'm using the FC9, thus I've tried to test it using the update version
> from rawhide: bzflag-2.0.12-3.fc10.i386

You really should be testing bzflag-2.0.12-3.fc9 which is available at the same
places. Rawhide packages aren't guaranteed to work on older/stable releases.

> and it gives me the same output:
> 
> X Error of failed request:  BadValue (integer parameter out of range for
operation)
>   Major opcode of failed request:  134 (XFree86-VidModeExtension)
>   Minor opcode of failed request:  10 (XF86VidModeSwitchToMode)
>   Value in failed request:  0xa7
>   Serial number of failed request:  149
>   Current serial number in output stream:  151
> 

Hmm, this works for me now. Please check whether you can reproduce the problem
with a clean test user account (i.e. whether it's a problem in your local
configuration). Please attach a tarball/zip of your ~/.bzf directory (of the
user where you have the problem).

(In reply to comment #13)
> (In reply to comment #12)
> You really should be testing bzflag-2.0.12-3.fc9 which is available at the 
I used the rawhide version only because yesterday, the "yum
--enablerepo=updates-testing update bzflag" command didn't return updated
version of the bzflag for the fc9. Nevertheless, today the fc9 version of bzflag
gives exactly the same version.

> Please attach a tarball/zip of your ~/.bzf directory (of the
> user where you have the problem).
As aforementioned in the comment #7, I don't have any user specific
configuration. In other words, I removed the ~/.bzf directory before I run the
bzflag.

I could reproduce the problem by removing the .bzf directory as well.

I've found that SDL_ListModes() lists video modes not valid for my display (e.g.
1600x1200 while my max resolution is 1400x1050) which would explain why setting
them doesn't work.

I'll attach a small test program which exhibits the same problem:

nils@wombat:~/test/sdl> ./sdl_listmodes 
mode: 1600 x 1200
mode: 1400 x 1050
mode: 1280 x 1024
mode: 1280 x 960
mode: 1152 x 864
mode: 1024 x 768
mode: 832 x 624
mode: 800 x 600
mode: 720 x 400
mode: 640 x 480
mode: 640 x 400
mode: 640 x 350

Thomas, would you please check why it finds these illegal resolutions? Thanks.

Created attachment 312030 [details]
Program which calls SDL_ListModes() and lists the modes found

build with:

make CFLAGS="`sdl-config --cflags`" LDFLAGS="`sdl-config --libs`" sdl_listmodes

NB: this is SDL-1.2.13-3.fc9.x86_64

Created attachment 312048 [details]
Test program for XF86VidModeGetAllModeLines.

Build with: gcc -O -g -Wall -o x11_modelines x11_modelines.c -lX11 -lXxf86vm

Are there illegal resolutions in the output for you?

It seems to be the case (1600x1200 again):

nils@wombat:~/test/sdl> ./x11_modelines 
selected mode: 1400x1050

mode 0: 1400x1050
mode 1: 1600x1200
mode 2: 1600x1200
mode 3: 1600x1200
mode 4: 1600x1200
mode 5: 1600x1200
mode 6: 1600x1200
mode 7: 1600x1200
mode 8: 1600x1200
mode 9: 1600x1200
mode 10: 1400x1050
mode 11: 1280x1024
mode 12: 1280x1024
mode 13: 1280x1024
mode 14: 1280x960
mode 15: 1280x960
mode 16: 1152x864
mode 17: 1024x768
mode 18: 1024x768
mode 19: 1024x768
mode 20: 1024x768
mode 21: 1024x768
mode 22: 832x624
mode 23: 800x600
mode 24: 800x600
mode 25: 800x600
mode 26: 800x600
mode 27: 800x600
mode 28: 640x480
mode 29: 640x480
mode 30: 640x480
mode 31: 640x480
mode 32: 640x480
mode 33: 640x480
mode 34: 640x480
mode 35: 640x480
mode 36: 720x400
mode 37: 640x400
mode 38: 640x350

If it could help somehow, the output from x11_modelines 
on my machine is as follows:

selected mode: 1600x1200

mode 0: 1600x1200
mode 1: 2048x1536
mode 2: 1920x1440
mode 3: 1920x1440
mode 4: 1920x1440
mode 5: 1856x1392
mode 6: 1856x1392
mode 7: 1792x1344
mode 8: 1792x1344
mode 9: 1600x1200
mode 10: 1600x1200
mode 11: 1600x1200
mode 12: 1600x1200
mode 13: 1600x1200
mode 14: 1600x1200
mode 15: 1600x1200
mode 16: 1400x1050
mode 17: 1400x1050
mode 18: 1280x1024
mode 19: 1280x1024
mode 20: 1280x1024
mode 21: 1280x1024
mode 22: 1280x1024
mode 23: 1280x960
mode 24: 1280x960
mode 25: 1152x864
mode 26: 1024x768
mode 27: 1024x768
mode 28: 1024x768
mode 29: 1024x768
mode 30: 1024x768
mode 31: 1024x768
mode 32: 832x624
mode 33: 800x600
mode 34: 800x600
mode 35: 800x600
mode 36: 800x600
mode 37: 800x600
mode 38: 800x600
mode 39: 640x480
mode 40: 640x480
mode 41: 640x480
mode 42: 640x480
mode 43: 640x480
mode 44: 640x480
mode 45: 640x480
mode 46: 640x480
mode 47: 720x400
mode 48: 720x400
mode 49: 720x400
mode 50: 640x400
mode 51: 640x350

Damian, what X11 driver do you use? And do you have custom set modes in
/etc/X11/xorg.conf (e.g. 'Modes    "1400x1050" "1360x768" "1280x1024" "1280x960"
"1280x800" "1280x720" "1152x864" "1152x768" "1024x768" "800x600" "640x480"' in
the Screen/Display section)?

(In reply to comment #21)
> Damian, what X11 driver do you use?
intel
> And do you have custom set modes.
No, I don't have any. Please find the dump of my xorg.conf configuration file in
the beginning of this issue. 

bzflag-2.0.12-3.fc8 has been pushed to the Fedora 8 stable repository.  If problems still persist, please make note of it in this bug report.

Argh, this shouldn't have been closed by the bzflag update.

bzflag-2.0.12-3.fc9 has been pushed to the Fedora 9 stable repository.  If problems still persist, please make note of it in this bug report.

This is not a SDL problem, reassigning to xorg-x11.

This message is a reminder that Fedora 9 is nearing its end of life.
Approximately 30 (thirty) days from now Fedora will stop maintaining
and issuing updates for Fedora 9.  It is Fedora's policy to close all
bug reports from releases that are no longer maintained.  At that time
this bug will be closed as WONTFIX if it remains open with a Fedora 
'version' of '9'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version' 
to a later Fedora version prior to Fedora 9's end of life.

Bug Reporter: Thank you for reporting this issue and we are sorry that 
we may not be able to fix it before Fedora 9 is end of life.  If you 
would still like to see this bug fixed and are able to reproduce it 
against a later version of Fedora please change the 'version' of this 
bug to the applicable version.  If you are unable to change the version, 
please add a comment here and someone will do it for you.

Although we aim to fix as many bugs as possible during every release's 
lifetime, sometimes those efforts are overtaken by events.  Often a 
more recent Fedora release includes newer upstream software that fixes 
bugs or makes them obsolete.

The process we are following is described here: 
http://fedoraproject.org/wiki/BugZappers/HouseKeeping

(In reply to comment #28)

> If you would still like to see this bug fixed and are able to reproduce it 
> against a later version of Fedora please change the 'version' of this 
> bug to the applicable version.

The same problem still happens on FC10 (bzflag.i386 0:2.0.12-3.fc10):

$ bzflag
X Error of failed request:  BadValue (integer parameter out of range for operation)
  Major opcode of failed request:  134 (XFree86-VidModeExtension)
  Minor opcode of failed request:  10 (XF86VidModeSwitchToMode)
  Value in failed request:  0x9d
  Serial number of failed request:  149
  Current serial number in output stream:  151

This message is a reminder that Fedora 10 is nearing its end of life.
Approximately 30 (thirty) days from now Fedora will stop maintaining
and issuing updates for Fedora 10.  It is Fedora's policy to close all
bug reports from releases that are no longer maintained.  At that time
this bug will be closed as WONTFIX if it remains open with a Fedora 
'version' of '10'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version' 
to a later Fedora version prior to Fedora 10's end of life.

Bug Reporter: Thank you for reporting this issue and we are sorry that 
we may not be able to fix it before Fedora 10 is end of life.  If you 
would still like to see this bug fixed and are able to reproduce it 
against a later version of Fedora please change the 'version' of this 
bug to the applicable version.  If you are unable to change the version, 
please add a comment here and someone will do it for you.

Although we aim to fix as many bugs as possible during every release's 
lifetime, sometimes those efforts are overtaken by events.  Often a 
more recent Fedora release includes newer upstream software that fixes 
bugs or makes them obsolete.

The process we are following is described here: 
http://fedoraproject.org/wiki/BugZappers/HouseKeeping

Fedora 10 changed to end-of-life (EOL) status on 2009-12-17. Fedora 10 is 
no longer maintained, which means that it will not receive any further 
security or bug fix updates. As a result we are closing this bug.

If you can reproduce this bug against a currently maintained version of 
Fedora please feel free to reopen this bug against that version.

Thank you for reporting this bug and we are sorry it could not be fixed.