newbiz wrote on Wednesday, January 05, 2011:
Hello,
I have no problem building and running my program on most platforms. But
"sometimes", users seems to have troubles with this error occuring at
application startup:
"Failed to select a GLFWFBConfig from the alternatives"
It seems to happen mainly on Windows 7.
Is there any fix/explanations ?
elmindreda wrote on Wednesday, January 05, 2011:
That doesn’t sound good. That’s not really supposed to happen. Do you know
more about the specifications of their machines?
newbiz wrote on Thursday, January 06, 2011:
I have access to one of the machines that has this problem. In fact, a whole
cluster of them.
About half of them have gentoo installed, the other half has Windows.
There is no problem running the program on the gentoo ones. But those having
Windows 7 pro will crash with the aforementioned mentioned error (whatever
window requested will fail, even 640x480 windowed).
=====
processor : 0
vendor_id : GenuineIntel
cpu family : 6
model : 23
model name : Intel(R) Core(TM)2 Duo CPU E7400 @ 2.80GHz
stepping : 10
cpu MHz : 2792.813
cache size : 3072 KB
physical id : 0
siblings : 2
core id : 0
cpu cores : 2
apicid : 0
initial apicid : 0
fdiv_bug : no
hlt_bug : no
f00f_bug : no
coma_bug : no
fpu : yes
fpu_exception : yes
cpuid level : 13
wp : yes
flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat
pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe nx lm constant_tsc
arch_perfmon pebs bts aperfmperf pni dtes64 monitor ds_cpl est tm2 ssse3
cx16 xtpr pdcm sse4_1 xsave lahf_lm
bogomips : 5585.62
clflush size : 64
cache_alignment : 64
address sizes : 36 bits physical, 48 bits virtual
power management:
=====
Graphics card: Radeon X1300/X1550
elmindreda wrote on Thursday, January 06, 2011:
The error comes from _glfwChooseFBConfig (window.c) not finding any
acceptable GLFWFBConfig. If you trace through that function, you may be able
to find out why.
newbiz wrote on Friday, January 07, 2011:
Okay, I’ll go for a debug session next week and keep you informed
anonymous wrote on Wednesday, January 12, 2011:
I have the same problem when trying to create a window using Mesa3D (I want
to test something with a simpler OpenGL implementation than the hardware
accelerated one I have). I decided to step into the code, and the problem is
caused by the function getFBConfigs in win32_window.c.
The number of pixel formats returned is 2, but one is discarded because it
fails the test
!( pfd.dwFlags & PFD_GENERIC_ACCELERATED ) && ( pfd.dwFlags & PFD_GENERIC_FORMAT )
and the other fails the test
!( pfd.dwFlags & PFD_DRAW_TO_WINDOW ) || !( pfd.dwFlags & PFD_SUPPORT_OPENGL ) || !( pfd.dwFlags & FD_DOUBLEBUFFER )
The intentions are good, but the end result is that the OpenGL window cannot
be created under some unfortunate setups (software renderers).
What about a selection mechanism that favors hardware acceleration, but that
can fall back to software if needed?
ceniza wrote on Wednesday, January 12, 2011:
I am the one who posted the previous reply, but now I was able to recover my
account.
I can confirm that skipping those conditions works. I was able to launch my
application using Mesa3D that way.
elmindreda wrote on Wednesday, January 12, 2011:
@ceniza Thank you.
Would it be acceptable to you having to set a window hint for GLFW to
recognise software rendering pixel formats?
ceniza wrote on Wednesday, January 12, 2011:
It would be acceptable. Could you also add another hint to accept non-double-
buffered as well?
Thanks.