adding opengl about gokrazy

[bkleiner]

I kinda already did the DRM part: https://github.com/bkleiner/krayons
Just without libdrm. It's really just a wrapper around a few ioctls.

You should be able to run the package with the above kernel config.
It will display some basic info on the screen connected to HDMI.

[bkleiner]

My intent was pretty much the opposite: I just wanted to display some text and/or images as simple as possible. No fans, no whistles, and certainly no bulky c-legacy code.

@gedw99 While i like your idea, i think you should probably do something from scratch.
Your thingy is just too different:
By the time you packaged the libraries you gonna need just to run the x-server (which you will need for sdl?) you will be at twice the size of a gokrazy distribution.

[bkleiner]

@stapelberg just be aware of the dragons :) As i'm pretty strapped on time also, i haven't gotten around to clean it up. I just wanted it out there for people to have a peek at how it could be done without any c involvement.
FYI: As far as i can tell we could have some hardware acceleration on aarch64 (currently we can't without loading some binary blob) as soon as some of these patches land in mainline. That would really improve performance and power-efficiency.

@carwyn there are a few pure golang 2D solutions out there. I think for 3D you have to have opengl.

https://github.com/as/a

• 2D golang GUI with a PROPER rich Text editor
• Lots or other nice stuff.

https://github.com/g3n/g3nd

• its amazing
• Has 2D and 3D opengl gui widgets
• BUT its opengl based

[stapelberg]

@bkleiner Thanks for the config changes you suggested. I merged them (with slightly different comments and CMA values) in gokrazy/kernel@d796ebd

[Merovius]

gokrazy doesn't support HDMI; what good would OpenGL do for you?

[stapelberg]

HDMI support might be in reach eventually (it could be as simple as a kernel config change), but I don’t know anything about OpenGL and what userspace components are required.

The answer to this is the same as to any other software question: to run on gokrazy, you need to be 100% Go. Full stop.

[joeblew99]

i know a fair bit about opengl. I can try it out and let you know how i go ?

[bkleiner]

I don't know about OGL as you would have to re-implement libgl in golang to stay true to gokracy's philosophy.
Simpler stuff, like sofware rendering and putting it onto the framebuffer, however seems possible.

I managed to enable HDMI output and the VC4 DRM driver with a more minimal kernel config.
Tested on 4.15.13. As a bonus even HDMI-CEC seems to be a go

const configAddendum = `
CONFIG_ARCH_BCM2835=y 
CONFIG_HW_RANDOM_BCM2835=y
CONFIG_DMA_BCM2835=y
# CONFIG_I2C_BCM2835=y seems to work now as far as i can tell
CONFIG_SPI_BCM2835=y
CONFIG_SPI_BCM2835AUX=y
CONFIG_SERIAL_8250_BCM2835AUX=y
CONFIG_BCM2835_WDT=y
CONFIG_SND_BCM2835_SOC_I2S=y
CONFIG_USB_USBNET=y
CONFIG_USB_NET_SMSC95XX=y
CONFIG_BCM2835_MBOX=y
CONFIG_RASPBERRYPI_FIRMWARE=y
CONFIG_RASPBERRYPI_POWER=y
CONFIG_IPV6=y

# For physically connecting the gokrazy bakery:
CONFIG_USB_SERIAL=y
CONFIG_USB_SERIAL_FTDI_SIO=y

# For physically connecting the scan2drive USB LCD:
CONFIG_USB_ACM=y

# enable simple framebuffer for early boot
# edit: seems needed too
CONFIG_FB_SIMPLE=y

# enable the vc4 drm driver
CONFIG_DRM=y
CONFIG_DRM_VC4=y
CONFIG_DRM_VC4_HDMI_CEC=y

# seems needed. the default (16) is to small.
# maybe configure this via cmdline?
# https://cateee.net/lkddb/web-lkddb/CMA_SIZE_MBYTES.html
CONFIG_CMA_SIZE_MBYTES=128
`

[carwyn]

This seems relevant, looks at using fbdev and DRM directly without any userspace libs:

http://betteros.org/tut/graphics1.php

(Also this popped up on HN just now: http://seenaburns.com/2018/04/04/writing-to-the-framebuffer/)

Trying to statically link libdrm into the Go binary would be the next step up I guess. Beyond that to get OpenGL in you'd then be looking at pulling in Mesa and KMS/DRI:

https://github.com/anholt/mesa/wiki/VC4

(or maybe the older proprietary Broadcom driver, can't find those details).

Basic character based or at a push basic framebuffer (with work) seems feasible but beyond that you're heading to a regular minimalist distro or chunky static binaries. (Or re-implementing OpenGL in Go)

[carwyn]

For Go based OpenGL and other thing from Go on a Pi this also seems useful:

https://github.com/djthorpe/gopi

This sounds really exciting.

If the intent here is to have a desktop environment with only the bare minimum then I would use flutter desktop.

I am using flutter for mobile and desktop apps and it's write once run everywhere.

At the moment there are a few different ways of embedding flutter on desktops.
The one I like is SDL. Google have gotten MAC and Linux working and Will does is coming soon.

https://github.com/google/flutter-desktop-embedding

It would be very easy to build a desktop GUI with flutter. A few tried with QML / QT but flutter is much more extensive.

I should add that I typically build systems currently with flutter for the GUI and golang as the backend to the GUI.

Golang and flutter can communicate however you want.

• grpc
• ipc using flutter Method Channels. You can use json, protobufs and anything.

I just read that anything other than golang is not allowed in gokrazy.
Does that mean SDL dependencies are not allowed ?
The flutter sdl dependencies are here

https://github.com/ds84182/flutter_sdl

The stuff needed for managing a desktop is here:
https://github.com/ds84182/flit

[stapelberg]

I have no intent of building a desktop environment (maybe someone else has, but I haven’t heard any plans).

Yes, SDL dependencies will not work. gokrazy only supports Go, nothing else.

Ok thanks for the responses. If would be interested in working in order to get just the bare minimum of c and sdl to run flutter desktop. I know you are not keen on accepting but can you give me any tips about including extra raspberry Debian packages in the core kernal blob that gocrazy builts. My intent is that all OS updates use the gokrazy updating process.

…

On Tue, Apr 10, 2018, 9:28 AM Michael Stapelberg ***@***.***> wrote: I have no intent of building a desktop environment (maybe someone else has, but I haven’t heard any plans). Yes, SDL dependencies will not work. gokrazy only supports Go, nothing else. — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#32 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/ATuCwogTrcK4JQaOgTDvqOjb2VaSvrbeks5tnF8MgaJpZM4OkDBu> .

[stapelberg]

gokrazy does not use Debian packages (or any distribution packages), so you can’t include any others. The kernel is just an upstream kernel with the minimal config to work on the Raspberry Pi. You shouldn’t use our kernel, just re-use Raspbian’s, or fork ours, and then start something custom as @bkleiner explained.

(Side note: @bkleiner, I still want to have a closer look at your code, but I’m short on time currently. Maybe over the weekend :))

@bkleiner
Thanks for the feedback.
Regarding SDL and X-Server, you can run SDL without X-Server on Raspberry PI.
IN this script, you can see "without x" setting for example on MacOS. i dont have a link for RaspberryPI script right now.
https://github.com/Homebrew/homebrew-core/blob/master/Formula/sdl2.rb

I agree that the code will be bigger but that actually fine. The main thing is to have gokrazy as the main controller. Just like how CoreOS have golang code for the main control .

I had a look at your code.
There is also a very good SDL golang bridge BTW that is the official one.
https://github.com/veandco/go-sdl2

[carwyn]

Personally I'd agree that gokrazy would be best sticking to it's Go-only origins and at most having some mechanism for using the framebuffer directly akin to what @bkleiner has started. As soon as you get to dragging in masses of C code I think you're better off with one of the other micro distros.

Are there any prominent pure go graphics libs that a back end could be made for, e.g. gg or draw2d?

The other direction that could be explored is pure terminal handling to enable things like Termbox-go.

The project I'm working on uses gopacket that needs libpcap so I'm stuck needing a micro distro really but still interested in experimenting with this.

thanks for all your feedback.

Your right and now i see the merit of not adding all the c stuff.

[carwyn]

Interestingly someone is trying to implement a Vulcan driver by interfacing directly with the DRM interface:

https://github.com/Yours3lf/rpi-vulkan-driver

May become a useful reference for anyone trying to do more via the DRM interface from Go.

@carwyn i can see why his avatar is a superman logo... Hard stuff

[xmikus01]

And what about fauxgl - software-only 3D renderer written in Go (no cgo included)? Unfortunately no HW acceleration, but at least it would be portable.

https://github.com/fogleman/fauxgl

[stapelberg]

And what about fauxgl - software-only 3D renderer written in Go (no cgo included)? Unfortunately no HW acceleration, but at least it would be portable.

That should work. I wasn’t aware of this implementation, but unfortunately the GitHub repository doesn’t look particularly active either. Someone would have to try and see how well it works :)

[gedw99]

Fauxgl is a software renderer. It’s slow

i Wonder is gioui would work ?

It recently got a lot of work for Linux support .

It would allow building GPU accelerated apps .

https://github.com/gioui

[fasmide]

Fauxgl is a software renderer. It’s slow

i Wonder is gioui would work ?

It recently got a lot of work for Linux support .

It would allow building GPU accelerated apps .

https://github.com/gioui

gioui would be absolutely amazing to be able to run on a gokrazy appliance, but it does seem to require libEGL and so on