Runtime error with VNC on RaspbianOS

[allesharr]

I've tryed to run an appclication, writed by pc on my Raspberry pi 4B. The program was very simple. Code is:

package main

import (
	"fyne.io/fyne/v2/app"
	"fyne.io/fyne/v2/container"
	"fyne.io/fyne/v2/widget"
)

func main() {
	a := app.New()
	w := a.NewWindow("Hello")

	hello := widget.NewLabel("Hello Fyne!")
	w.SetContent(container.NewVBox(
		hello,
		widget.NewButton("Hi!", func() {
			hello.SetText("Welcome :)")
		}),
	))

	w.ShowAndRun()
}

Error is:

panic: runtime error: invalid memory address or nil pointer dereference
[signal SIGSEGV: segmentation violation code=0x1 addr=0x0 pc=0x80a210]

goroutine 1 [running, locked to thread]:
github.com/go-gl/glfw/v3.3/glfw.(*Monitor).GetPhysicalSize.func1(0x0, 0x40005e23c8, 0x40005e23cc)
	/home/arr/go/pkg/mod/github.com/go-gl/glfw/v3.3/glfw@v0.0.0-20211024062804-40e447a793be/monitor.go:152 +0x20
github.com/go-gl/glfw/v3.3/glfw.(*Monitor).GetPhysicalSize(0x0, 0x0, 0x0)
	/home/arr/go/pkg/mod/github.com/go-gl/glfw/v3.3/glfw@v0.0.0-20211024062804-40e447a793be/monitor.go:152 +0x64
fyne.io/fyne/v2/internal/driver/glfw.(*window).detectScale(0x40003d6200, 0x40003cd9f0)
	/home/arr/go/pkg/mod/fyne.io/fyne/v2@v2.1.4/internal/driver/glfw/window.go:373 +0x38
fyne.io/fyne/v2/internal/driver/glfw.(*window).create.func3()
	/home/arr/go/pkg/mod/fyne.io/fyne/v2@v2.1.4/internal/driver/glfw/window.go:1488 +0x358
fyne.io/fyne/v2/internal/driver/glfw.(*gLDriver).runGL(0x400012e480)
	/home/arr/go/pkg/mod/fyne.io/fyne/v2@v2.1.4/internal/driver/glfw/loop.go:127 +0x5d0
fyne.io/fyne/v2/internal/driver/glfw.(*gLDriver).Run(0x400012e480)
	/home/arr/go/pkg/mod/fyne.io/fyne/v2@v2.1.4/internal/driver/glfw/driver.go:85 +0x38
fyne.io/fyne/v2/internal/driver/glfw.(*window).ShowAndRun(0x40003d6200)
	/home/arr/go/pkg/mod/fyne.io/fyne/v2@v2.1.4/internal/driver/glfw/window.go:479 +0x38
main.main()
	/home/arr/Documents/test_fyne.go:21 +0x1e4
exit status 2

Device:

RaspbianOS v. Bullseye@latest

• Go version: 1.15
• Fyne version: 2.1.4

[allesharr]

I've tryed to rebuild it on arm64 and armhf. Result is the same. X86-is building ok.

[Jacalz]

Does it work if you cross-compile to arm64 using fyne-cross?

[allesharr]

With fyne-cross is another issue. When i am trying to pull packages it comes already.

$ fyne-cross linux --pull
[i] Target: linux/arm64
[i] Checking for a newer version of the docker image: lucor/fyne-cross:linux-arm64-latest
[✓] Image is up to date
[i] Cleaning target directories...
[✓] "bin" dir cleaned: /home/arr/Documents/fyne-cross/bin/linux-arm64
[✓] "dist" dir cleaned: /home/arr/Documents/fyne-cross/dist/linux-arm64
[✓] "temp" dir cleaned: /home/arr/Documents/fyne-cross/tmp/linux-arm64
[i] Checking for go.mod: /home/arr/Documents/go.mod
[✓] go.mod found
[i] Building binary...
WARNING: The requested image's platform (linux/amd64) does not match the detected host platform (linux/arm64/v8) and no specific platform was requested
exec /usr/local/bin/docker-entrypoint.sh: exec format error
[✗] exit status 1

I've read it is a docker problem, I need to run it with parametrs like docker buildx build --platform linux/amd64,linux/arm64 <container which name i didn't find> . But running with fyne-cross linux -arch arm64 <filename>.go is not working too. The same issue. Can you explain how can it be solved to answer the first queston?

[allesharr]

fyne-cross linux -arch arm64 -image lucor/fyne-cross:linux-arm64-latest main.go - is not working too. Error is the same:

[i] Target: linux/arm64
[i] Cleaning target directories...
[✓] "bin" dir cleaned: /home/arr/Documents/fyne-cross/bin/linux-arm64
[✓] "dist" dir cleaned: /home/arr/Documents/fyne-cross/dist/linux-arm64
[✓] "temp" dir cleaned: /home/arr/Documents/fyne-cross/tmp/linux-arm64
[i] Checking for go.mod: /home/arr/Documents/go.mod
[✓] go.mod found
[i] Building binary...
WARNING: The requested image's platform (linux/amd64) does not match the detected host platform (linux/arm64/v8) and no specific platform was requested
exec /usr/local/bin/docker-entrypoint.sh: exec format error
[✗] exit status 1

[andydotxyz]

I don't think this is a compilation problem (also this is runtime not a build error).
It looks like something isn't present in the GLFW driver when it expects info to be available.
From the stack trace it seems not able to detect a monitor!

Can you please confirm what graphical device is connected and any info you have about the graphics setup?

[allesharr]

Currently it's running throw the VNC-Desktop with resolution 640x480. The monitor as a device is not connected. I will try to rerun building with connected hdmi-exit

[lucor]

WRT fyne-cross the image at the moment is available only for linux/amd64, hence your error:
WARNING: The requested image's platform (linux/amd64) does not match the detected host platform (linux/arm64/v8)

[alexanderi96]

Hi, I get the same error while building/running a GUI app trough VNC. I also use a pi4 with Raspberry Pi OS. If I try to run/build with a monitor connected there is no problem.

[andydotxyz]

How is VNC started without a monitor attached? My understanding was that it provides remote access for the graphical setup of an existing system?

[alexanderi96]

So, Raspberry Pi OS provides a version of Real VNC built into the system. Enabling it is as easy as clicking a toggle inside the settings and rebooting (there is also an option to set the resolution of the virtual monitor).
If you boot with a monitor attached and connect to the pi via VNC you get a stream of the actual monitor. If you boot without a monitor attached RealVNC creates a virtual monitor with the selected resolution (don't ask me how it works in details because I do not know)

Edit:

I have to correct my first phrase. Since it is a runtime exception it only occours whenever I try to run the binary or the source with go run, and not when I try to build the source.

[andydotxyz]

Right I think I see. We do ask for monitor configuration to understand DPI.
Do you have suggestion about what the expected behaviour would be when there is no graphical context? Should we default to a standard value do you think?

[alexanderi96]

Maybe you could fallback to a default value like 96dpi, giving also the ability to set it manually if this is possible. I also don't know how clean a solution like that could be. I wanted to understand how other applications manage the dpi scaling on VNC mode but without results.

[andydotxyz]

I wanted to understand how other applications manage the dpi scaling on VNC mode but without results.

Yeah that's not surprising - most other places assume pixel-for-pixel rendering or have a toolkit level multiplier. We are trying to do something much more complex, but can fallback to that assumption.

[andydotxyz]

Fixed on develop ready for next release

[lucas-bernardino]

I was having problems when accessing the vnc viewer to control my raspberry pi and i found this article: https://picockpit.com/raspberry-pi/tigervnc-and-realvnc-on-raspberry-pi-bookworm-os/ where i was able to control my raspberry py using a vnc viewer alternative called tigervnc. I just follow the tutorial (setting up the tigervnc in the raspberry py and in the pc) and it worked flawlessly.