OpenGL Deprecation

[chriskris...@icloud.com]

I don’t know the roadmap for linux here.

Apple officially deprecated OpenGL in 2018 with the release of MacOS Mojave. The fact that it is still present in the MacOS SDK eight years later is a testament to how deeply entrenched legacy cross-platform tools (like Qt, Blender, and thousands of industrial/scientific apps) truly are. Back in 2018 they froze it in time at version 3.3 (profile core) and version 2.1 (compatibility). It receives zero performance updates, zero driver tuning, and is completely unaccelerated by Apple silicon's hardware layout engines. It relies entirely on a software translation layer to map OpenGL commands down onto the native Metal API. However, the clock is ticking, and here is how the timeline and the landscape look right now to me:

While Apple hasn't scrubbed OpenGL from the SDK entirely, and it still exists in the MacOS 27 betas, the inside rumor is that it will be removed from MacOS 27 in a point release. Which means any current builds of JS8Call will no longer run on MacOS 27. Windows uses DirectX for its Qt backend. Both linux and Mac use OpenGL. Apple’s native graphics rendering engine is /System/Library/Frameworks/Metal.framework/Versions/A/Metal

• - Metal eliminates the massive software driver overhead inherent to OpenGL
• - Metal is engineered from the ground up to take advantage of Apple silicon
• - OpenGL is famously single-threaded, meaning only one CPU core can effectively send commands to the GPU
• - Metal allows graphics workloads to be split seamlessly across multiple cores simultaneously

Since new OS version rollout happens quite rapidly in the Apple world, this needs to be dealt with immediately. I have a local build running here that uses the Apple Metal framework and does not link with OpenGL anymore. We can’t support all the legacy JS8Call builds. We have two options:

1. Put out a version release 3.1.1 that targets MacOS27
2. Simply rebuild the current 3.0.3 release for Mac and replace that download. But this requires that it is built on Qt 6.12 - Qt 6.9.3 will not work since 6.12 is the minimum for MacOS 27. I don’t think this is a good option since JS8Call will simply refuse to run and putting out a new 3.0.3 build for it that will run is confusing.

Apple puts out the mandate. Developers are expected to fix it. JS8Call 4 is not even close yet. Our software update notifier does not target OS version, it targets everybody. So it’s not practical to create a new release just for Mac. I created a release/3.0.4 branch on my local repo sometime back that had a critical bug fix in it over 3.0.3.

Since with our versioning system anything suffixed with a .0 is a release candidate, my vote is to create a new 3.1.1 branch from my drafted 3.0.4

- build for Windows and Linux on Qt 6.9.3

- build new Mac binary that is linked with the Apple Metal framework on Qt 6.12

- Note in the release notes that this build is primarily for MacOS 27, but does contain one crictical bug fix for all platforms.

I tested that older code to see if will build on MacOS 27 with Qt 6.12 without OpenGL and it won’t. I’ll have to patch the code here locally to create that Mac 3.1.1 build.

That should get us through until whenever JS8Call 4 is ready. I just created that branch to see where it sits. It’s currently 102 commits behind master, which is heading in this direction, but is not going to make it before MacOS 27 hits the streets.

As far as I know there is no plans to deprecate OpenGL on linux. It is a very old library invented by Silicon Graphics back in 1992. It has not been developed since 2017 but all linux desktops depend ENTIRELY on OpenGL thru their Mesa library. I think there has been some push to switch to Vulkan but linux will not run on most modern hardware anyway. It will not run bare metal on a Apple M3 or M4. Microsoft's original 2011 "Third-Party UEFI Certificate” expired in June 2026 and they control the PC world. So linux’s primary desktop hardware is Raspberry Pi on low-end arm64 chips, and legacy PC stuff where OpenGL will continue to function fine.

Chris AC9KH

[wmiler1]

On Monday, September 7, 2026 at 5:36:02 PM UTC-4 chriskris...@icloud.com wrote:

I don’t know the roadmap for linux here.

The roadmap is for Linux to move to Vulkan at some point, not sure when that is.

Since new OS version rollout happens quite rapidly in the Apple world, this needs to be dealt with immediately. I have a local build running here that uses the Apple Metal framework and does not link with OpenGL anymore. We can’t support all the legacy JS8Call builds. We have two options:

1. Put out a version release 3.1.1 that targets MacOS27
2. Simply rebuild the current 3.0.3 release for Mac and replace that download. But this requires that it is built on Qt 6.12 - Qt 6.9.3 will not work since 6.12 is the minimum for MacOS 27. I don’t think this is a good option since JS8Call will simply refuse to run and putting out a new 3.0.3 build for it that will run is confusing.

 

I vote for option 3: Put out a 3.0.4 that has the bug fix for everybody, no QT change. Mark that this is the final release for all OSes for QT 6.9.3. Note that JS8Call 3.1.x will require QT 6.12, and will not run on versions before MacOS 27. That way we have a clear demark. 

Apple puts out the mandate. Developers are expected to fix it. JS8Call 4 is not even close yet. Our software update notifier does not target OS version, it targets everybody. So it’s not practical to create a new release just for Mac. I created a release/3.0.4 branch on my local repo sometime back that had a critical bug fix in it over 3.0.3.

Since with our versioning system anything suffixed with a .0 is a release candidate, my vote is to create a new 3.1.1 branch from my drafted 3.0.4

- build for Windows and Linux on Qt 6.9.3

- build new Mac binary that is linked with the Apple Metal framework on Qt 6.12

- Note in the release notes that this build is primarily for MacOS 27, but does contain one crictical bug fix for all platforms.

I tested that older code to see if will build on MacOS 27 with Qt 6.12 without OpenGL and it won’t. I’ll have to patch the code here locally to create that Mac 3.1.1 build.

That should get us through until whenever JS8Call 4 is ready. I just created that branch to see where it sits. It’s currently 102 commits behind master, which is heading in this direction, but is not going to make it before MacOS 27 hits the streets.

As far as I know there is no plans to deprecate OpenGL on linux. It is a very old library invented by Silicon Graphics back in 1992. It has not been developed since 2017 but all linux desktops depend ENTIRELY on OpenGL thru their Mesa library.

Mesa has Vulkan drivers.

 

I think there has been some push to switch to Vulkan but linux will not run on most modern hardware anyway. It will not run bare metal on a Apple M3 or M4. Microsoft's original 2011 "Third-Party UEFI Certificate” expired in June 2026 and they control the PC world. So linux’s primary desktop hardware is Raspberry Pi on low-end arm64 chips, and legacy PC stuff where OpenGL will continue to function fine.

Whatever you are drinking, you should prolly stop.

Chris AC9KH

[chriskris...@icloud.com]

On Sep 7, 2026, at 17:42, wmiler1 <wmi...@gmail.com> wrote:

I vote for option 3: Put out a 3.0.4 that has the bug fix for everybody, no QT change. Mark that this is the final release for all OSes for QT 6.9.3. Note that JS8Call 3.1.x will require QT 6.12, and will not run on versions before MacOS 27. That way we have a clear demark. 

Let me go over this again.

JS8Call will not run on MacOS 27 beta 8. It crashes on start complaining that OpenGL cannot be found. Why? Because the JS8Call binary is linked with OpenGL. And you can’t just “install” OpenGL - it’s part of the operating system.

I have not been successful in building JS8Call without OpenGL on Qt 6.9.3. It requires SDK 27 and SDK 27 requires Qt 6.12, which is the Qt Group’s next LTS release. I’ve been gearing up master for literally weeks preparing for this because I knew it was coming. I spent the better part of a day determining that I CAN fix it and build JS8Call without OpenGL.

The big question is, how does the project want to fix it? My fix does not require anything on the JS8Call project side - it has to be done totally here in order to support MacOS 27. Whether the project wants to call it 3.0.4 or 3.1.1 makes no difference. Either way the Mac build will NOT be done on Qt 6.9.3 because it won’t build, and that is more than just a patch release. It is a major framework change going from OpenGL to the native Metal API.

The rest will be done on Qt 6.9.3 like they have been, coming direct from the workflows in that branch. They will basically get carried along in this with an explanation in the release notes that the release is primarily for Mac to support Apple’s latest OS version.

MacOS 27 hits the streets in two weeks. Software developers that don’t support a new OS version on day one have not been paying attention. That is not the case here. I came up with a fix for it. Now I need to implement it. I can do it two ways: either create a new release with the bug fix for the other two and the API fix for Mac. Or I can build Mac 3.1.1 here with the new API and just replace the current download in the 3.0.3 release with it. When Mac users find out JS8Call will no longer run on 27 Golden Gate they’ll come looking to see if there’s a fix.

The proper way is to push the fix ahead of time.

Whatever you are drinking, you should prolly stop.

Well, linux absolutely cannot run on a Apple M3 or newer processor. It can only run in a virtual machine where it actually runs quite well emulating a ARMv8 chip. They’ve been trying to hack it, but really haven’t gotten anywhere in three years:

https://www.phoronix.com/news/Apple-M4-DT-Linux

While I’ve never owned a PC, I did look at several new HP and Dell laptops with the idea of dual-booting linux and Windows 11 on them for testing. Doing research before I bought any of these, I find out that if it’s not proprietary drivers that are missing for motherboard chips, graphics, wifi, fingerprint readers or audio, some of them don’t support turning off the Secure Boot to even install linux on it, or certificates don’t match. The ones with Qualcomm Snapdragon chips have the firmware locked and will not boot linux at all. Although some have gotten it to boot, but none of the hardware works. And the bootloader they call a “Shim” does not work with the newest generation of x86_64 laptops:

https://www.helpnetsecurity.com/2026/07/14/eset-uefi-secure-boot-bypass/

In the end I decided it wasn’t worth it. I’m not going to fight that battle to install linux on hardware that is not designed for it. Your mileage may vary.

As far as what I’m drinking? Usually donut shop blend - black, no creme or sugar.

Chris AC9KH

[chriskris...@icloud.com]

On Sep 7, 2026, at 17:42, wmiler1 <wmi...@gmail.com> wrote:

Mesa has Vulkan drivers.

According to the Mesa project documentation:

The primary API is OpenGL but there’s also support for OpenGL ES, Vulkan, EGL, OpenCL and VA-API.

Hardware drivers include:

• Intel GMA, HD Graphics, Iris. See Intel’s Website

• AMD Radeon series. See RadeonFeature

• NVIDIA GPUs (Maxwell and later). See NVK

• Qualcomm Adreno 2xx-8xx. See Freedreno

• Broadcom VideoCore 4 and 5. See VC4 and V3D

• ARM Mali Utgard. See Lima

• ARM Mali Midgard, Bifrost. See Panfrost

• Vivante GCxxx. See Etnaviv Wiki

• Older NVIDIA GPUs (GeForce 5 / FX and later). See Nouveau Wiki

• NVIDIA Tegra (K1 and later).

[chriskris...@icloud.com]

> On Sep 7, 2026, at 5:42 PM, wmiler1 <wmi...@gmail.com> wrote:
>
> The roadmap is for Linux to move to Vulkan at some point, not sure when that is.

The technical issue from the project standpoint is that when you configure a project with find_package(Qt6 COMPONENTS Multimedia ... Widgets), CMake pulls in a cascading web of internal dependency targets. In a default Qt build ecosystem, Qt6::Widgets or Qt6::Multimedia internally link against Qt6::Gui, which holds the foundational system pipeline hooks. Because the underlying JS8Call codebase relies heavily on core Qt classes, the binary maps those assets to the desktop window via Qt6::Gui. The linker configuration will implicitly append -framework OpenGL to the final compilation build string.

This has not been a problem to-date as long as OpenGL exists on the system in some useable form. There was a report sometime back about the AppImage failing to run on Ubuntu 26. The problem was solved by installing libopengl0.The Qt plugin for linuxdeploy can’t package GL drivers as that would break the system. The linker linked libopengl0 to the binary simply because it existed on the build system.

Otherwise, as I experimented and found out with MacOS where OpenGL no longer exists, if you build on a system that does not have OpenGL (SDK 27 on Mac) you can force Qt to use its RHI backend.

This forces the issue at compile-time rather than runtime, stripping the legacy code paths entirely. By utilizing SDK 27 on Mac without the legacy framework, we are essentially forcing Qt’s build system to acknowledge that OpenGL is physically missing. Because Qt 6 is built around the modern RHI (Rendering Hardware Interface) abstraction layer, it gracefully cascades down to its native fallback backend, which on Apple systems is the Metal API, and on Windows is DirectX. I’m not sure what it is on linux, and that may change from one distro to the next because obviously Ubuntu 26 didn’t have it in that one case, but the build system obviously did.

For whatever reason I have not figured out, I cannot get this to work on Qt 6.9.3. It works (so far) on Qt 6.11 and Qt 6.12. But Qt 6.11 won’t compile with SDK 27. To build that experiment I had to use SDK 26 with a -no-opengl configure flag to build Qt itself.

There was a definite advantage to using the native Metal API on Mac vs legacy OpenGL. It reduces the memory footprint by ~55MB and the waterfall/spectrum scope renders much cleaner without all the “white noise”.

The linux developers will have to experiment with this going forward. I’m not sure if it works the same way on linux that it does on Mac/Windows.

Chris AC9KH

[Kelly-Shane Fuller]

I've been building mine without -framework OpenGL for quite a while now. Works totally fine for what it's worth. 

--
You received this message because you are subscribed to the Google Groups "JS8Call-improved" group.
To unsubscribe from this group and stop receiving emails from it, send an email to js8call-improv...@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/js8call-improved/A6043867-7954-4AA5-96DE-A0291B18786A%40icloud.com.

[chriskris...@icloud.com]

On Sep 8, 2026, at 11:51, Kelly-Shane Fuller <punk...@gmail.com> wrote:

I've been building mine without -framework OpenGL for quite a while now. Works totally fine for what it's worth. 

I used the -no-opengl configure flag but it doesn’t actually work with Qt 6.9.3. On 6.9.3, according to the Qt documentation, the platform plugin (libqcocoa.dylib) still contains a considerable amount of legacy code. Even if you explicitly pass -no-opengl, CMake evaluates the core code blocks inside the cocoa platform module that bridge AppKit and OpenGL surface views. Because that source code is unconditionally present in the 6.9 baseline, the build script adds a linker directive for Apple's system OpenGL.framework to guarantee that code path resolves.

This has been cleaned up in Qt 6.11 and later. Right now I’ve been testing with Qt 6.12.0-beta4, the rc just came out today, stable Qt 6.12.0 is being released on Sept 22.

Chris AC9KH

[chriskris...@icloud.com]

On Sep 8, 2026, at 11:51 AM, Kelly-Shane Fuller <punk...@gmail.com> wrote:

I've been building mine without -framework OpenGL for quite a while now. Works totally fine for what it's worth. 

Kelly,

I had to look up what this flag does and I can see where the confusion arises. That flag is a configure-time flag for apps that require OpenGL. Leaving it off for JS8Call doesn’t make any difference - the binary is linked with OpenGL anyway.

This issue has to be fixed on the library side, building Qt itself, and what SDK it is built with. Qt has to be compiled to tell it to explicitly use the Metal API for a Mac build. If you get your Qt library from the online installer you won’t get that. It has to be custom-built from source. If you use the beta SDK 27, you will get a proper Qt build for MacOS 27. If you use SDK 26 you will NOT get a proper build for MacOS 27.

The minimum version of Qt that will compile on SDK 27 is Qt 6.12. The minimum version of Qt that will compile on SDK 26 is 6.9.1. Apple and the Qt Group selected 6.12 since it is the next LTS release for commercial developers.

SDK 26 is not forward compatible with SDK 27. SDK27 is backwards compatible with down to MacOS version 26.1 for Apple silicon only. With MacOS 27 the traditional two-versions back support no longer applies since Apple wants x86_64 to disappear. 

Chris AC9KH