[HN Gopher] Writing GUI applications on the Raspberry Pi without...
___________________________________________________________________
Writing GUI applications on the Raspberry Pi without a desktop
environment (2019)
Author : raytopia
Score : 175 points
Date : 2024-07-03 02:29 UTC (3 days ago)
(HTM) web link (avikdas.com)
(TXT) w3m dump (avikdas.com)
| codetrotter wrote:
| The way I did it was to run Weston without any icons or anything
| and using systemd to start my app and also having systemd reopen
| my app if it closes. Worked well enough.
| vially wrote:
| I haven't personally used it, but I have seen cage [0] being
| recommended a few times for similar use-cases.
|
| [0] - https://github.com/cage-kiosk/cage
| baobun wrote:
| Stumpwm is very nice if in X11.
| kees99 wrote:
| No WM at all is less nice, but can work. A bit over a
| decade ago, we shipped a kiosk/appliance that software-wise
| only had kernel, X, and firefox. All starting directly from
| /etc/inittab, something like this:
| id:5:initdefault: x1:5:respawn:/etc/rc-x11
| ff:5:respawn:/etc/rc-firefox
|
| ...where /etc/rc-* are few lines of shell that set up
| environment variables, and end with "exec chroot
| --userspec=... / /bin/firefox ..." - this way X and firefox
| run under same PIDs that sysvinit knows about, so they get
| restarted after a crash.
| sandreas wrote:
| AvaloniaUI can also utilize framebuffer to run on Raspberry PI,
| see
| https://docs.avaloniaui.net/docs/guides/platforms/rpi/runnin...
| JaggerJo wrote:
| I've used this in production. It's great.
| jug wrote:
| Wow, I would have never discovered this and I work full time
| with .NET, and have experience with Avalonia! It's just that I
| normally don't look for Pi-related stuff there, rather heading
| to Python as a clear de facto Pi language and libraries. Really
| cool to see this kind of niche being carved out by .NET and
| Avalonia! Too bad it's generally easier to get I/O boards to
| work out of the box on Python, with high level drivers and
| libraries often already written. .NET of course also has its
| way to interface but you'll likely end up doing it on a lower
| level due to the lack of drivers. There _are_ drivers but not
| as many and it's more likely to end up with more generic GPIO
| pin reading/writing libraries.
| sandreas wrote:
| Well, there are a lot of efforts to make C# / .NET suitable
| for raspberry projects.
|
| NativeAOT is on the way, so that you can compile small
| binaries without any dependencies.
|
| If that does not work, you can compile your project as
| "ReadyToRun" with "Trimming", which will treeshake all
| unneeded runtime stuff and prepare an acceptable small
| binary.
|
| One way to overcome the problem with missing drivers is to
| setup a python API (e.g. Flask) and triggering things through
| the Avalonia UI. Or you could wrap a binary execution via
| CliWrap, an excellent library for .NET to run external
| processes.
|
| I once wrote a little eventhub[1] to run on the Raspberry PI,
| it is just an experiment but worked ok.
|
| There is also .NET IoT[2], which exactly targets these
| platforms.
|
| 1: https://github.com/sandreas/eventhub/tree/main/eventhub
|
| 2: https://dotnet.microsoft.com/en-us/apps/iot
| S0und wrote:
| I've replaced an industrial windows workstation with PI +
| Avalonia in a factory. Way more compact, you don't have to care
| about Windows anymore. Is the PI industrial grade? No, but we
| have a spare PI ready, and SSD with preinstalled OS. So you can
| fix everything in a matter of minutes.
|
| Although I had to rewrite the software, because the original
| was WinForms, it was a pretty simple application.
| masijo wrote:
| Yet another alternative for drawing directly on the framebuffer
| is DirectFB 2: https://directfb2.github.io/
|
| It supports Vulkan, OpenGL, Cairo and other technologies.
| adontz wrote:
| I've successfully utilized Qt5 (probably would work with 6 too)
| for framebuffer/OpenGL.
|
| QML is nice, animations were much smoother than I expected.
| ahartmetz wrote:
| QML's main use case, commercially at least, is fullscreen
| embedded applications. Of course it works great for that in
| particular.
| demondemidi wrote:
| LVGL is pretty much the IOT industry standard for 32-bit
| architectures like Renesas RX, Arm Cortex-M, ARC, TI MSP,
| Atmel...
|
| https://lvgl.io/
| Rochus wrote:
| This is a great library, but as far as I understand it is
| rather for bare-metal or low-resource embedded operating
| systems, not for Linux. The OP apparently runs Linux. Could he
| also use LVGL on Linux and write to the FB device?
| ranger_danger wrote:
| yes you can
| Rochus wrote:
| Is this an officially supported feature, so that I could
| e.g. develop on Linux and directly use my code on an
| embedded device with no changes?
| demondemidi wrote:
| Oh, yeah, you're right. It seemed like OP was trying to prove
| he could "bare bones" it because the article was about how to
| avoid everything but a framebuffer, so I thought I'd offer
| this up... LVGL is as bare-bones as it gets!
| benhoff wrote:
| I've been trying to setup a pipeline of pass through hdmi from an
| HDMI input to an HDMI output with an OrangePI5 Plus. I could talk
| for a long time (now) about the issues with vendor supplied
| kernels and unsupported hardware. I was completely naive until I
| had the hardware in hand, having not done any embedded work.
|
| Right now, the best of breed thought that I have is to run
| Weston, have a Qt application that is full screen, and to use DMA
| buffers so I can do some zero copy processing. Rockchip has their
| own MPP and RGA libraries that are tied into the Mali GPU, and
| I'm not smart enough to understand the current level of
| driver/userspace support to not leverage these libraries.
|
| Rockchip and the ARM ecosystem is such a mess.
|
| If anyone has any pointers, experience, approaches, code, etc, I
| would love to see it.
| dividuum wrote:
| In general DRM/KMS can be quite confusing a there seems little
| userland documentation available. I assume you get the DMA
| buffers from the HDMI input somehow? If so, you should be able
| to use drmModeAddFB2WithModifiers to create a DRM framebuffer
| from them. Then attach that to a DRM plane, place that on a
| CRTC and then schedule a page flip after modesetting a video
| mode.
|
| The advantage would be that you can directly run without
| starting into any kind of visual environment first. But it's a
| huge mess to get going: I wrote quite a bit of Pi4/5 code
| recently to make a zero copy HEVC/H264 decoder working and it
| was a quite a challenge. Maybe code like
| https://github.com/dvdhrm/docs/tree/master/drm-howto can help?
| benhoff wrote:
| The HDMI receive device on the OrangePi5 plus is in a semi-
| functional state. Collabora is in the process of up-streaming
| code so the RK3588 will work with the mainline linux kernel.
|
| Until that happens, working driver code is in a very
| transitive space.
|
| To get going, and sidestep that problem, I've purchased an
| HDMI to USB capture cards that use MacroSilicon chips. I've
| some thought of using a cheaper CPU in the future with a
| daughter board based on this project which uses MacoSilicon
| chips: https://github.com/YuzukiHD/YuzukiLOHCC-PRO, which
| made it potentially not a waste of time to dig into.
|
| The MacroSilicon HDMI to USB capture cards output MJEPG,
| which Rockchip's MPP library has decoder for.
|
| So the thought is: (1) allocate a DMA buffer (2) set that DMA
| buffer as the MJEPG decoder target (3) get the decoded data
| to display (sounds like I may need to encode again?) & a
| parallel processing pipeline
|
| I'll dig into the stuff you've sent over, very helpful thanks
| for the pointers!
|
| I've thought about switching to Pi4/5 for this. Based on your
| experience, would you recommend that platform?
| dividuum wrote:
| > I've thought about switching to Pi4/5 for this. Based on
| your experience, would you recommend that platform?
|
| Their kernel fork is well maintained and if there is a
| reproducible problem it usually gets fixed quite quickly.
| Overall pretty happy. KMS/DRM was a bit wonky as there was
| a transition phase where they used a hacky mix between KMS
| and the old proprietary broadcom APIs (FakeKMS). But those
| days are over and so far KMS/DRM works pretty well for what
| I'm using it.
| ranger_danger wrote:
| you can also run Qt directly on the console fb without
| wayland/X
| benhoff wrote:
| I might end up doing that. When I was first digging into it,
| the Qt documentation seemed confusing. But after sinking
| 10-20 hours into everything, it's starting to click a lot
| more.
|
| Thanks for the pointer!
| leonheld wrote:
| We have a bunch of examples of GUIs that run inside containers
| (with different backends, frameworks, without compositor etc):
| https://github.com/toradex/vscode-torizon-templates.
| peanball wrote:
| Don't forget about the Kivy framework. It's a python framework
| that renders openGL accelerated UIs, also headlessly on the
| raspberry pi if needed. https://kivy.org
| moffkalast wrote:
| More importantly, Kivy also has Vulkan compatibility, which is
| the only thing you can run on the Pi 5 since it has no OpenGL
| support.
|
| Can you really use it without a desktop env though? Would be
| cool if one could launch it in full kiosk mode from the
| headless tty.
| jdboyd wrote:
| I have an application deployed on Raspberry Pi 3 machines
| running a GUI touch application running on EGL without X11.
| To do so you set the Window provider to `egl_rpi`. My recall
| is that I had to do a custom build of Kivy to do this at the
| time. I'm pretty sure you can do this with a Raspberry Pi 4,
| but I don't know for sure about a Raspberry Pi 5.
| peanball wrote:
| I have a project with Raspberry Pis up to 3B+
| (https://just-functional.com). egl_rpi is not supported on
| 4, but KMS/DRM is, still headless.
| kcb wrote:
| > which is the only thing you can run on the Pi 5 since it
| has no OpenGL support.
|
| https://mesamatrix.net v3d conformant up to OpenGL 3.1.
| TrevorFSmith wrote:
| PyGame is also great for scripting quick UIs for the fb. You
| don't want to write big apps in it but for ease of setup and use
| it's sweet.
| alias_neo wrote:
| I've been doing some R&D for building a Home Assistant dashboard
| with a nice touchscreen display I bought to go on the wall at
| home, with the ultimate goal of expanding it into many home-
| rolled displays.
|
| Having slimmed down the RPi Lite OS as much as I can, running
| Wayfire with a Chromium kiosk is just too much for the Pi 3B+ I'm
| using once I add a streaming camera to the dashboard, and it
| can't cope. My goal is to have a responsive touch-screen display
| for Home Assistant using something in the form-factor of a Pi
| Zero 2W, so that I can put the SBC _inside_ the display and build
| a wooden picture frame to house it all, so it doesn't stick out
| like a sore thumb.
|
| I'm not sure what kind of API HA has for the frontend, but my
| first thought, was to build a native application with a Go
| backend (I write Go for my day job) and use something like
| Wails[0] for the frontend and completely cut out the heavy-weight
| Chromium browser.
|
| I have Pi4's and Pi5's but I really want to use the littlest
| amount of compute (and power) I can to achieve this, even it
| means writing the UI myself. I've tried looking for a lighter-
| weight browser that I can simply run the HA dashboard in to no
| avail.
|
| [0]https://wails.io/
| benhoff wrote:
| I've been looking at the Radxa zero3w/zero3e.
|
| Looks like this guy got Chromium to work?
| https://www.youtube.com/watch?v=XAnN1A_sye0
| kragen wrote:
| conceivably interesting to you if you want to do this: my library
| yeso https://gitlab.com/kragen/bubbleos/blob/master/yeso supports
| drawing on the framebuffer or in an x window; for c programs you
| choose which at link time, but the luajit and python bindings
| dynamically one shared library or the other according to whether
| they're running under x-windows or not
|
| yeso is a very small and simple library, so you have to do more
| things from scratch than with libraries with more comprehensive
| functionality, but being able to test your app in a window before
| running it on the framebuffer could be useful
|
| yeso's input handling on the linux framebuffer is not as complete
| as its x-windows handling, but it's good enough that yeso
| programs like ./tetris-fb (with wasd) and ./mand.lua do work on
| the framebuffer console. the terminal emulator admu-shell-fb
| mostly works, but it has the problem that things like control-z
| or control-c suspend or kill the terminal emulator instead of
| what you're running in it :)
|
| (i haven't actually tried yeso on the pi, but if it doesn't work
| there i'll fix it)
| squarefoot wrote:
| Years ago I played with TekUI on a Allwinner A10 board and it
| worked fine also displaying GUIs on the framebuffer without any
| underlying X environment.
|
| http://tekui.neoscientists.org/
|
| Only caveats: it's quite old and doesn't seem maintained anymore,
| although it still compiles fine, and it's Lua only, but being
| written in C it shouldn't be too hard to port it to other
| languages.
| tetris11 wrote:
| MPV can play videos direct to the FB, with hardware acceleration
| too
| haddr wrote:
| One problem with Raspberry Pi displays is that not all of them
| provide vsync signal in SPI mode. That leads to high CPU usage
| (due to very high frame rate) and its generally inefficient.
| Choose your display carefully.
___________________________________________________________________
(page generated 2024-07-06 23:00 UTC)