Support Software Rendering for X11 by allowing to disable GLX

[jbcpollak]

Checklist

• I have searched the issue tracker for open issues that relate to the same problem, before opening a new one.
• This issue only relates to a single bug. I will open new issues for any other problems.

Describe the bug

I am trying to develop a Fyne application in a devcontainer on Mac OS. The challenge with this is that with the new M1/M2/M3 Macs there is no GPU acceleration in Docker, so their is only the software renderer in MESA available.

When I run my application I get a crash like this:

libGL error: No matching fbConfigs or visuals found
libGL error: failed to load driver: swrast
2024/04/11 16:07:51 Fyne error:  window creation error
2024/04/11 16:07:51   Cause: APIUnavailable: GLX: OpenGL ES requested but GLX_EXT_create_context_es2_profile is unavailable
2024/04/11 16:07:51   At: /go/pkg/mod/fyne.io/fyne/v2@v2.4.4/internal/driver/glfw/driver_notwindows.go:9

with a bit of searching I found that you can give GLFW the window hint GLFW_EGL_CONTEXT_API to disable using GLX API calls, which I think would fix my problem, but I don't see a way to do that within Fyne.

My usecase is sort of esoteric but there are probably other uses of using Fyne with software rendering.

How to reproduce

Here is my Dockerfile:

FROM mcr.microsoft.com/devcontainers/go:1-1.22-bookworm

RUN apt-get update && export DEBIAN_FRONTEND=noninteractive \
    && apt-get -y install --no-install-recommends \
        # Install additional packages
        libgl1-mesa-dev \
        xorg-dev \
        libasound2-dev \
        x11-apps \
        dbus dbus-x11 \
        mesa-utils \
    && apt-get autoremove -y && apt-get clean -y && rm -rf /var/lib/apt/lists/*

within that docker container, run a minimal Fyne application and the GUI will not appear.

Screenshots

No response

Example code

func main() {
	app := app.New()
	win := app.NewWindow("MyApp")
	win.ShowAndRun()
}

Fyne version

2.4.4

Go compiler version

1.22

Operating system and version

MacOS host, Debian 11 dev container

Additional Information

No response

[Bluebugs]

The problem seems to be that on ARM we are picking GLES, while we should pick GL for Mac M* hardware when inside a docker container.

[andydotxyz]

I don't know if this is a daft question but why are you running a GUI app in a docker container? All our tooling is designed to build native apps for each platform.

P.s. If you want to build a GUI for docker won't it need to be a Linux app not a macOS app?

[Jacalz]

Does it help to build with -tags egl? Most apps have switched to EGL from GLX by now on Linux but go-gl (or maybe it is upstream GLFW) still uses GLX by default.

[Jacalz]

This might also be an effect related to the fact that you might not have all the necessary graphics drivers installed in the Docker container. I do most of my development in a Fedora Toolbox container on Fedora Silverblue and that requires some extra driver packages to be installed for things to work as expected (see containers/toolbox#1023 (comment))

[jbcpollak]

@andydotxyz:

I don't know if this is a daft question but why are you running a GUI app in a docker container?

Not a daft question, and for the record the project compiles flawlessly on MacOS with just XCode and Go installed. However I'm trying to make a coding screen for interviewees and wanted to make then environment as simple and non-invasive for them to use as possible, so I was hoping to provide a devcontainer they could just checkout and use without having to install a bunch of dependencies on their computers they may not need to use.

In the past I've done this with apps that either don't have GUIs or use the web, but we are a Go shop and I thought this would be a good platform.

As an aside, I tried to use the web target as another work around and downgraded go to 1.19 to use gopherjs's 1.19 beta, but one of the dependencies my project has uses generics. I tried export GOPHERJS_EXPERIMENT=generics then building, but it still gave me problems - maybe the environment variables aren't passed from fyne into gopherjs?

@Jacalz:

Does it help to build with -tags egl?

I get the same result with or without the -tags egl, assuming I'm doing this right:

$ fyne build -tags egl
libGL error: No matching fbConfigs or visuals found
libGL error: failed to load driver: swrast
2024/04/12 15:11:48 Fyne error:  window creation error
2024/04/12 15:11:48   Cause: APIUnavailable: GLX: OpenGL ES requested but GLX_EXT_create_context_es2_profile is unavailable
2024/04/12 15:11:48   At: /go/pkg/mod/fyne.io/fyne/v2@v2.4.4/internal/driver/glfw/driver_notwindows.go:9

I installed libgl1-mesa-glx and mesa-vulkan-drivers in addition to all the other mesa packages I had but that didn't change the output.

[andydotxyz]

I was hoping to provide a devcontainer they could just checkout and use without having to install a bunch of dependencies on their computers they may not need to use.

A fyne app has no runtime dependencies, so hopefully this is not a build issue.
If you need to bundle other tools for your interview setup then I guess I can see why you took this path - but a virtual machine would more commonly be used for this sort of setup - and VirtualBox is able to provide the proper graphics context for the runtime.

As an aside, I tried to use the web target as another work around and downgraded go to 1.19 to use gopherjs's 1.19 beta, but one of the dependencies my project has uses generics. I tried export GOPHERJS_EXPERIMENT=generics then building, but it still gave me problems - maybe the environment variables aren't passed from fyne into gopherjs?

You could use the develop branch of Fyne and/or the new tools/cmd/fyne repo/location which no longer uses GopherJS for the web build.

[jbcpollak]

You could use the develop branch of Fyne and/or the new tools/cmd/fyne repo/location which no longer uses GopherJS for the web build.

How would I do this? I tried go get ...@develop but I got a lot of compiler and import errors I wasn't sure how to proceed with.

[Jacalz]

Never try to go get github.com/fyne-io/fyne/v2. You should still use fyne.io like usual

[jbcpollak]

@Jacalz in that case how do I use the develop branch? Or should I just not try that?

You could use the develop branch of Fyne and/or the new tools/cmd/fyne repo/location which no longer uses GopherJS for the web build.

[Jacalz]

These two commands ought to work:

go get fyne.io/fyne/v2@develop
go mod tidy

[jbcpollak]

Ah, ok that works, thanks. When I do that I get:

$ fyne serve
../../go/pkg/mod/fyne.io/fyne/v2@v2.4.6-0.20240430125557-56342a2b034a/app.go:84:16: Pointer not declared by package atomic

error building application: exit status 1

is that something I'm doing wrong or a temporary hiccup with the develop branch?

Sorry, I realize this is veering off topic from the original issue request but it is potentially more directly addressing my primary goal.

[Jacalz]

Ah, sorry, that's just how you get fyne from the develop branch. You also need to use the new fyne command: https://github.com/fyne-io/tools/blob/main/cmd/fyne/main.go

go install fyne.io/tools/cmd/fyne@main

[jbcpollak]

Thank you @Jacalz ! That got me going and the app works for me now. I have a small problem which is that it loads into a black screen - I think this is because of Chrome's anti-autoplay of audio policy and my app loads ebitengine to play audio, but that's a separate issue.

The specific problem I created this ticket for isn't solved but I have an even better work around, so thank you everyone who chimed in.