- Saved searches
- Use saved searches to filter your results more quickly
- [error] Glfw Error 65543: GLX: Failed to create context: GLXBadFBConfig #260
- [error] Glfw Error 65543: GLX: Failed to create context: GLXBadFBConfig #260
- Comments
- Footer
- Saved searches
- Use saved searches to filter your results more quickly
- [glfw error 65543]: GLX: Failed to create context: GLXBadFBConfig #1104
- [glfw error 65543]: GLX: Failed to create context: GLXBadFBConfig #1104
- Comments
Saved searches
Use saved searches to filter your results more quickly
You signed in with another tab or window. Reload to refresh your session. You signed out in another tab or window. Reload to refresh your session. You switched accounts on another tab or window. Reload to refresh your session.
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
[error] Glfw Error 65543: GLX: Failed to create context: GLXBadFBConfig #260
[error] Glfw Error 65543: GLX: Failed to create context: GLXBadFBConfig #260
Comments
I installed Pop OS on an old Dell workstation computer with old integrated graphics. The OS works ok but I haven’t been able to update it yet since the System76 PPA servers have been offline for the last day. When I try to launch SDR++, it gives this error:
[error] Glfw Error 65543: GLX: Failed to create context: GLXBadFBConfig . I’ve seen that a graphics driver update could resolve this issue, and it may work once the server is back online. But I’ve installed it on two different computers from the same era with different gpus and they both threw the error. Any ideas on a solution? The error does not show up on my modern PC running the same OS.
The text was updated successfully, but these errors were encountered:
Oh dear.. That’s probably what it is. That sucks.
gonna work on supporting older GLs
Alright! Well I will check in occasionally and try new versions to see if they work. Thanks btw for this awesome program, It’s really really good.
Sometimes there is only one way and that is forward.
Just found out that the Windows laptop also only has OpenGL 2.1, Intel driver already the latest.
What does that mean for Linux? I think it works on windows even on the old machines at this time
Define «old» 😉 and «it» and «that»
As far as I understand it: specific hardware needs a driver for the OS you want to use.
My laptops have Intel HD Graphics. Intel decided to not make newer Linux drivers for this hardware. Since many years ago.
Also specific software tricks in newer graphics software might need newer or faster hardware or hardware with a different architecture.
OpenGL in its latest versions uses all the new tricks developed lately. Not all tricks used by software developers integrating OpenGL will work with older versions of OpenGL and mutatis mutandis not with older drivers or older hardware.
Example: if your software or driver would only work with a dedicated floating point co-processor (FPU) it would not work with older cpu’s not having that kind of extra.
And Linux is not different from OSX or Windows in regard to the above.
Gonna need full startup logs on a non working system.
Trying to add a work around for this.
You want the output of terminal when I run “sdrpp”? Is there another log somewhere I should send you?
As far as old goes, we’re trying to run sdr++ on two computers from 2008-2014 era. Not sure exactly what year either were made but I can get you a full specs list later.
“It” is SDR++
”That” was referring to the previous comment before I said that.
yeah, just run it in a terminal (adding the -s parameter if you’re on windows) and send the full logs until the crash.
I wanna know exactly at which part of loading OpenGL is unhappy.
Terminal output: $ sdrpp
[2021-08-16 17:32:32.112] [info] SDR++ v1.0.3
[2021-08-16 17:32:32.112] [info] Loading config
[2021-08-16 17:32:32.157] [error] Glfw Error 65543: GLX: Failed to create context: GLXBadFBConfig
I know that’s not super helpful but that’s what it puts out.
The SDR++ window never appears.
it’s enough for me to know where it happens.
Seems to be where I thought it was: when asking glfw for a specific opengl version.
I’ll see what I can do about it.
Thank you so much for being responsive and looking into it!
gonna work on supporting older GLs
I’ve (hopefully) added support for OpenGL 2.1 as well as OpenGL ES, could you try the latest commit and see if it runs properly?
(If you wait a few minutes from now, the automated build will be done so you can try that if you prefer)
Can you please advise from where to download latest automated build? I only find the releases which is same as before. Thank you.
I compiled from the source and this is what I get
sdrpp
[2021-08-21 17:07:59.989] [info] SDR++ v1.0.4
[2021-08-21 17:08:00.023] [info] Loading config
[2021-08-21 17:08:03.843] [error] Glfw Error 65543: GLX: Failed to create context: GLXBadFBConfig
[2021-08-21 17:08:03.916] [info] OpenGL 3.0 was not supported
[2021-08-21 17:08:04.038] [error] Glfw Error 65543: GLX: Failed to create context: GLXBadFBConfig
[2021-08-21 17:08:04.087] [info] OpenGL 3.1 ES was not supported
[2021-08-21 17:08:04.087] [error] Glfw Error 65540: Invalid OpenGL ES version 2.1
[2021-08-21 17:08:04.087] [info] OpenGL 2.1 was not supported
sdrpp: /build/glfw3-KLyziG/glfw3-3.3.2/src/window.c:1040: glfwSetWindowMaximizeCallback: Assertion window != NULL failed.
Aborted (core dumped)
I compiled from the source and this is what I get
My bad, looks like I forgot a line. I pushed a fix just now, try the latest commit
Can you please advise from where to download latest automated build? I only find the releases which is same as before. Thank you.
Each commit is built and available through the «Actions» tab
At the time of writing this, the latest commit still has an orange sign next to it meaning it’s compiling.
When it becomes a green checkmark, click on it and scroll down to the «Artifacts» section. You can then click on the file you want to download it
sdrpp
[2021-08-21 18:03:28.272] [info] SDR++ v1.0.4
[2021-08-21 18:03:28.273] [info] Loading config
[2021-08-21 18:03:32.636] [error] Glfw Error 65543: GLX: Failed to create context: GLXBadFBConfig
[2021-08-21 18:03:32.736] [info] OpenGL 3.0 was not supported
[2021-08-21 18:03:32.782] [error] Glfw Error 65543: GLX: Failed to create context: GLXBadFBConfig
[2021-08-21 18:03:32.793] [info] OpenGL 3.1 ES was not supported
[2021-08-21 18:03:32.839] [error] Glfw Error 65543: GLX: Failed to create context: GLXBadFBConfig
[2021-08-21 18:03:32.840] [info] OpenGL 2.1 was not supported
sdrpp: /build/glfw3-KLyziG/glfw3-3.3.2/src/window.c:1040: glfwSetWindowMaximizeCallback: Assertion `window != NULL’ failed.
Aborted (core dumped)
This means your computer just doesn’t support OpenGL, I’m afraid SDR++ won’t work well for you in that case.
You can try software rendering with Mesa3D but expect very poor performance.
Edit: try running glxinfo | grep opengl
I ran glxinfo | grep opengl but it didn’t print anything and just returned the line. Was it supposed to say something as the output?
then you really don’t have any OpenGL support at the moment.
Are you sure your graphics drivers are properly installed?
Could you give me info on your hardware
There’s the hardware probe. Maybe it is just too old. :/ bummer
looks like it only supports opengl 1.4
Can’t support that sorry, looks like it’s too old.
Adding basically any GPU made in the last 10 years would fix this issue
On Sat, Aug 21, 2021 at 6:41 PM AlexandreRouma ***@***.***> wrote: looks like it only supports opengl 1.4 Can’t support that sorry, looks like it’s too old. Adding basically any GPU made in the last 10 years would fix this issue — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub , or unsubscribe . Triage notifications on the go with GitHub Mobile for iOS or Android .
And works with my HP EliteBook 2540p Intel HD Graphics supporting OpenGL 2.1
Well done Sir and thank you! Only ran a short FM test with Pluto+.
Starting sdrpp -s first checks for OpenGL 3.0 then OpenGL 3.1 ES and then finds OpenGL 2.1
With cmake-gui I had to switch off airspyhf and airspyhf_source modules. A first for me to get so deep into the build system.
I’m closing this issue since this issue seems to be fixed by supporting slightly older OpenGL version.
Footer
You can’t perform that action at this time.
Saved searches
Use saved searches to filter your results more quickly
You signed in with another tab or window. Reload to refresh your session. You signed out in another tab or window. Reload to refresh your session. You switched accounts on another tab or window. Reload to refresh your session.
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
[glfw error 65543]: GLX: Failed to create context: GLXBadFBConfig #1104
[glfw error 65543]: GLX: Failed to create context: GLXBadFBConfig #1104
Comments
I’m unable to open kitty or alacritty in a fresh installation.
First of all I get this output when I run kitty from terminal.
kitty libGL error: failed to create dri screen libGL error: failed to load driver: swrast [121 12:27:11.848966] [glfw error 65543]: GLX: Failed to create context: GLXBadFBConfig [121 12:27:11.849101] Failed to create GLFW temp window! This usually happens because of old/broken OpenGL drivers. kitty requires working OpenGL 3.3 drivers.
So I run the next command:
LIBGL_ALWAYS_SOFTWARE=true GALLIUM_DRIVER=llvmpipe kitty
and then kitty finally opens. The problem is that when I close the window I need to rerun the same command to be able to open it again.
I have set the environmental variables in /etc/environment:
LIBGL_ALWAYS_SOFTWARE=true GALLIUM_DRIVER=llvmpipe
But nothing changes. I don’t know hot to stabilise those values so every time I boot I can launch kitty.
I also tried
export LIBGL_ALWAYS_SOFTWARE=true
and it works but when I reboot I’m facing the same issue again.
I don’t know what else I can do. Maybe I’m setting wrong the environmental variables.
The text was updated successfully, but these errors were encountered:
lspci | grep -i "vga" 00:02.0 VGA compatible controller: VMware SVGA II Adapter
Did you select all the open source graphics drivers, specifically you’ll need https://archlinux.org/packages/?name=xf86-video-vmware and mesa i believe. long time since i ran VMWare
I checked and I have this two installed:
extra/xf86-video-vesa 2.5.0-2 (xorg-drivers xorg) [installed] X.org vesa video driver extra/xf86-video-vmware 13.3.0-3 (xorg-drivers) [installed] X.org vmware video driver
I noticed, but the VMWare driver or open source driver tend to work well there too. but most importantly is the mesa package. on the phone atm so apoligies for short answers.
Now do pacman -Q mesa , im almost certain you’ll have that too tho
Then i’m not sure what is causing the issue. Appers as if kitty is having issues activating the GL context at least, i’ll investigate and see what could cause this.
@thank you. I’ve been trying to solve this for two days now and it’s turning me crazy. Hope you find something.
I don’t know what happened but when I booted up this morning everything worked fine. Weird. This kind of things makes me curious. I don’t know if the problem would start again later but for the moment it seems solved.
If it does, drop a post on the Arch forums or better yet the Kitty forums, as they probably know by heart what could cause this 🙂 Glad it works tho!
Sorry for ressucitating the «dead» issue, but I thought this would complement it nicely :
I ended up here having similar errors on an old computer (I think bought around 2010) I just reinstalled with Arch. I can’t speak for the VMWare guest driver (don’t have the required setup at hand), but the one I currently use seems to be limited to OpenGL 2.1. And to be able to run anything that requires a more recent OpenGL version than the one your graphics driver advertises will at least require the LIBGL_ALWAYS_SOFTWARE=true defined.
@SatouKuzuma1 if you ever run into such an issue again, to prevent having to export it at the beginning of each new session, you can place your export LIBGL_ALWAYS_SOFTWARE=true either :
- in your user’s ~/.profile (for a single user);
- in a file of your choosing in /etc/profile.d (for a multi-user setup, shouldn’ t be relevant for a VM).
Note that any such configuration should result in a way higher load on the CPU, rendering moot some of the key features.
Finally, regarding the problem itself, if ixni -Ga (or any other tool giving you details on your GL current running version) returns a value of OpenGL inferior to 3.3, such as what I have :
Graphics: Device-1: Intel Core Processor Integrated Graphics driver: i915 v: kernel Display: server: X.org v: 1.21.1.6 driver: X: loaded: modesetting unloaded: fbdev dri: crocus gpu: i915 resolution: 1440x900~50Hz API: OpenGL v: 2.1 Mesa 22.3.2 renderer: Mesa Intel HD Graphics (ILK)
at least kitty won’t be able to init properly (for anything else, it will depend on what API they actually require).