[JP2026] OpenGLES/WebGL issue

Bug Reports
1

REPRODUCIBILITY: Always
OS VERSION: 5.2.0.17
HARDWARE: Jolla Phone (2026) (jp2601 / jp2601)
UI LANGUAGE: EN
REGRESSION: Yes, it does work in 5.0.1.11@X10II

DESCRIPTION:

An app that uses OpenGL (qutenav) does not work.
The error is:

[W] unknown:0 - QOpenGLShader::link: " The number of vertex shader storage blocks (2) is greater than the maximum number allowed (0).\n"
[F] unknown:0 - Failed to link the program:  The number of vertex shader storage blocks (2) is greater than the maximum number allowed (0)

During testing I have found that webgl samples does not work as well in web browser as well.
It looks like as similar issue as webview mediadecoderstatemachine ns error dom media fatal error
and I believe that is port issue as well.

PRECONDITIONS:

JP2026 with 5.2.0.17

STEPS TO REPRODUCE:

  1. Run the app
  2. or open https://webglsamples.org in web browser and play a sample

EXPECTED RESULT:

It does work

ACTUAL RESULT:

MODIFICATIONS:

No modifications

ADDITIONAL INFORMATION:

https://openrepos.net/content/kan/qutenav

[W] unknown:0 - QOpenGLShader::link: " The number of vertex shader storage blocks (2) is greater than the maximum number allowed (0).\n"
[F] unknown:0 - Failed to link the program:  The number of vertex shader storage blocks (2) is greater than the maximum number allowed (0).
1 Like
2

It looks like SSBO for vertex shaders is missing. Is it GLES drivers issue?

3

I tested the samples using the (gecko) port 140 & 153 version and it worked just fine, so it might be just issue with the current 115 version

4

No, it does not work fine. FPS=1 means that there is no hardware acceleration. At all.

5

Yeah, I noticed that. Version 153 has that regression, but unlike version 115 which doesn’t run at all, but at least version 140 hits around 30–32 FPS… so it works well.

6

WebGL will be fixed with [browser] Rebase on 115.40. JB#64961 by abranson · Pull Request #193 · sailfishos/gecko-dev · GitHub. In addition to update to the latest ESR115 release that PR includes backport of WebGL fixes from the sailfishos-esr153 branch. With the changes all https://webglsamples.org tests work in browser with reasonable FPS values of 30 or more, of course depending on the test and test settings.

The issue with OpenGLES app is different and might suggest that the SSBO for vertex shader is not supported by the device, but that needs verification.

3 Likes
7

Hi! I seem to have encountered a very similar OpenGL ES issue on the Jolla Phone 2026, this time in an Android game running through Android AppSupport.

Environment

  • Device: Jolla Phone 2026 (JP2601)

  • Sailfish OS: 5.2.0.20

  • Application: Crying Suns (Android)

  • Package: com.altshift.cryingsuns

  • Game version: 3.0.3

  • Unity version: 2018.4.36f1 (IL2CPP, ARM64, Release)

  • Installation: Aurora Store, using the Google account that owns the game

  • microG: Installed, with signature spoofing enabled and passing the relevant self-checks

Problem

Crying Suns launches but becomes permanently stuck on the Humble Games splash screen. The issue is reproducible on every launch.

The same game works correctly on a regular Android device.

Relevant logcat error

After launching the game, Unity reports:

10-21 13:49:10.529 E/Unity (3304): -------- GLSL link error: The number of vertex shader storage blocks (1) is greater than the maximum number allowed (0).

This looks remarkably similar to the shader error reported earlier in this thread, except that my case occurs inside Android AppSupport rather than a native Sailfish application.

I haven’t established whether this shader error is the actual cause of the splash-screen hang, but the similarity seems worth investigating.

Troubleshooting already performed

1. Verified game resources

The game requires an OBB file. I confirmed that it exists:

/storage/emulated/0/Android/obb/com.altshift.cryingsuns/main.122.com.altshift.cryingsuns.obb

  • Size: approximately 352 MB.

  • Visible from within Android AppSupport using appsupport-attach.

  • File ownership appears correct (u0_a63, matching the game’s Android UID).

2. Checked microG

Initially, signature spoofing was not configured correctly. I enabled it and confirmed that the relevant microG self-checks pass.

This did not change the game’s behavior.

3. Examined logcat

Unity initializes successfully and reports the following information:

  • Unity 2018.4.36f1

  • ARM64 / IL2CPP

  • OpenGL ES extensions including ARM/Mali-specific extensions

  • GLSL shader linking failure involving vertex shader storage blocks

There was also an Android storage error (ServiceSpecificException, code -30) referencing another storage volume, but the OBB file is accessible from the primary emulated storage. I don’t know whether the storage warning is relevant.

4. Attempted alternative graphics APIs

I experimented with passing Unity graphics API flags through Android intent extras.

  • Attempting Vulkan produced “Unable to initialize the Unity engine Gfx API”.

  • Attempting GLES 3.0 did not change the splash-screen hang.

However, I cannot confirm that Unity actually honors these flags when passed through Android intent extras, so I would consider these experiments inconclusive.

Questions

Given the similarity to the original report:

  1. Could this be another manifestation of the same vertex shader SSBO limitation?

  2. Is the reported maximum of zero vertex shader storage blocks an expected hardware/driver limitation on JP2601, or potentially a graphics driver issue?

  3. Are there any additional diagnostics I could collect from Android AppSupport to help distinguish a Unity shader compatibility problem from a graphics driver issue?

I can provide a more complete logcat capture, graphics capabilities, or perform additional tests if useful.

Thanks!

8

there is already a general bug report for some games not working on JP26; Some major Android games not working Jolla is aware of the issue and there has been some progress in fixing them

9

Similarly, there is also an issue with Vulkan being reported incorrectly on the JP2026.

10

I get around 20-30 fps in the native browser (esr115), but about 3-4x more in Firefox android (version 155).

11

153ESR based version is coming with 5.3 update, hopefully it will be close to the android version performance. Beta release of 5.3 was targeted for October, so hopefully we will find out soon