Author Topic: Framebuffer GUI Toolkit  (Read 8066 times)

0 Members and 1 Guest are viewing this topic.

Offline blueskullTopic starter

  • Supporter
  • ****
  • !
  • Posts: 367
  • Country: cn
  • BA7LKP
Framebuffer GUI Toolkit
« on: October 23, 2017, 05:21:49 am »
Hi all. Is there an easy to use, small footprint GUI toolkit that doesn't depend on X11 or Wayland?

I know there's Qt and more, but I need a few features specifically:
1. 100% static build without even libc dependency.
2. If can't be statically linked, it must be Yocto friendly.
3. Simple build environment (no Qt mess).
4. Free (no uGFX).
5. With RAD tool.

So far my best candidate is Mono/Winforms, but it doesn't play well with Yocto and the official OE mono layer doesn't compile.

Any suggestions on a GUI toolkit or suggestion on how to get mono to work?
 

Offline nctnico

  • Super Contributor
  • ***
  • Posts: 26751
  • Country: nl
    • NCT Developments
Re: Framebuffer GUI Toolkit
« Reply #1 on: October 23, 2017, 10:38:43 am »
I have used WxWidgets together with the minimal version of X-Windows. I have looked into this as well but without some form of X-Windows you will end up in a world of pain.
There are small lies, big lies and then there is what is on the screen of your oscilloscope.
 

Offline Fredderic

  • Regular Contributor
  • *
  • Posts: 67
  • Country: au
Re: Framebuffer GUI Toolkit
« Reply #2 on: October 23, 2017, 12:48:19 pm »
Also, what programming environment are you using?  Many of them bring along a lightweight UI toolkit of their own (anything from Microsoft, of course, will be pushing you towards Windows and .NET), which tends to be pretty system agnostic and static, though they often don't have RAD tools — though for anything with those other requirements you list, I've typically found the RAD tools to be more fiddly than just doing it in code (extra files, separate bindings, and a lot of extra allocations and fluff that wouldn't otherwise be necessary).  You mention Qt, so probably C++ or it's ilk, but figured it was worth asking.
 

Offline abraxa

  • Frequent Contributor
  • **
  • Posts: 377
  • Country: de
  • Sigrok associate
Re: Framebuffer GUI Toolkit
« Reply #3 on: October 23, 2017, 09:24:47 pm »
The enlightenment foundation libraries (EFL) may be worth a look:

https://www.enlightenment.org/about
https://www.enlightenment.org/docs/distros/yocto-start

As far as I can tell, the main issue seems to be that there's no RAD tool.
 

Offline nctnico

  • Super Contributor
  • ***
  • Posts: 26751
  • Country: nl
    • NCT Developments
Re: Framebuffer GUI Toolkit
« Reply #4 on: October 23, 2017, 09:34:39 pm »
I have used WxWidgets together with the minimal version of X-Windows. I have looked into this as well but without some form of X-Windows you will end up in a world of pain.
I use wxWidgets all the time, but it seems wxUniversal is almost dead and wxEmbedded is dead as a rock. I will try not to use X11 as much as possible -- my system doesn't even have sysvinit or systemd, it's literally Linux kernel booting into a single program that replaces init. My goal is to boot the system to GUI in 5 seconds from power up on a 528MHz iMX6ULL. So far I've given uboot a shrink, give kernel a big shrink and got rid of uboot delay, splash and kernel splash. Now it takes 4 secs to boot into kernel CLI hello world. By recompiling uboot with even less features (ethernet, LCD init, etc.), I think 3 sec to CLI is possible.
You need to get your disk faster. With an mSata SSD you should be able to get the boot time down a lot.
There are small lies, big lies and then there is what is on the screen of your oscilloscope.
 

Offline andersm

  • Super Contributor
  • ***
  • Posts: 1198
  • Country: fi
Re: Framebuffer GUI Toolkit
« Reply #5 on: October 23, 2017, 09:40:08 pm »
I last looked seriously at this maybe five years ago, and back then Qt was the only serious contender. At work we're currently using a browser-based UI running on QtWebKit. We're still on Qt 4.8, which is well supported in Yocto, but the downside is that its version of WebKit is very outdated which has created a few headaches with third-party Javascript libraries.

Offline nctnico

  • Super Contributor
  • ***
  • Posts: 26751
  • Country: nl
    • NCT Developments
Re: Framebuffer GUI Toolkit
« Reply #6 on: October 23, 2017, 09:54:49 pm »
You need to get your disk faster. With an mSata SSD you should be able to get the boot time down a lot.
I'm talking about a small $7.5 chip with at most eMMC4.5 support and only 16 bit DDR3L support. The system is supposed to be fit inside a portable music player.
It's part of my HiFi music player project, the CPU handles GUI, eMMC/uSD data fetching, audio decoding, interpolation and sigma delta modulation, then the modulated bitstream goes to two high speed 4-bit thermometer coded DAC ASICs for L and R channels.
How about keeping the system in standby and only boot long when the battery went flat? You'll need to figure out the power domains carefully though to get the consumption down to a few mA.
There are small lies, big lies and then there is what is on the screen of your oscilloscope.
 

Offline Whales

  • Super Contributor
  • ***
  • Posts: 1899
  • Country: au
    • Halestrom
Re: Framebuffer GUI Toolkit
« Reply #7 on: October 23, 2017, 11:31:14 pm »
SDL 1.2 supports directFB as an output device.  I suspect there are lots of SDL-based GUI toolkits available.  I'm not sure what complexity/level of UI you want (just text, checkboxes and buttons; or combo boxes, hover effects and resizing).

Quote
created a few headaches with third-party Javascript libraries.

Wait, is this on a portable device?  [flee emoticon]


Offline apelly

  • Supporter
  • ****
  • Posts: 1061
  • Country: nz
  • Probe
Re: Framebuffer GUI Toolkit
« Reply #8 on: October 24, 2017, 01:04:50 am »
Any ideas?
I haven't closely read the whole thread, but I reckon that's what I'd do.

The guy that wrote this blog post: http://andybrown.me.uk/2013/10/19/vivaz-u5-lcd/  from memory has an Atmel & an ARM graphics library on github. You'll have to dig out a link from somewhere on that site though because I don't seem to have a bookmark handy.

Qt & Wx seem like way over-kill, and as you pointed out, Wx is about dead anyway.
 

Offline andersm

  • Super Contributor
  • ***
  • Posts: 1198
  • Country: fi
Re: Framebuffer GUI Toolkit
« Reply #9 on: October 24, 2017, 04:43:13 am »
Quote
created a few headaches with third-party Javascript libraries.
Wait, is this on a portable device?  [flee emoticon]
No, but if you're sensible about it, it doesn't consume much CPU. We're on a dual-core Cortex-A9 at 800MHz, and the idle CPU load is a couple of percent. Also, ever used the browser on your smartphone?

Offline abraxa

  • Frequent Contributor
  • **
  • Posts: 377
  • Country: de
  • Sigrok associate
Re: Framebuffer GUI Toolkit
« Reply #10 on: October 24, 2017, 05:50:02 am »
The enlightenment foundation libraries (EFL) may be worth a look:

https://www.enlightenment.org/about
https://www.enlightenment.org/docs/distros/yocto-start

As far as I can tell, the main issue seems to be that there's no RAD tool.

Seems like it also runs on top of X11 or Wayland?

On the about page I linked to, it says
"Framebuffer, Wayland, X11, Windows, OSX Cocoa, SDL, PS3, Linux DRM handling" :)

As for the licenses, I actually forgot to check. Oops. I just did and here's the list in case you want to check for yourself:
https://git.enlightenment.org/core/efl.git/tree/COPYING
 

Offline stmdude

  • Frequent Contributor
  • **
  • Posts: 479
  • Country: se
Re: Framebuffer GUI Toolkit
« Reply #11 on: October 24, 2017, 06:30:32 am »
I don't think I can get sysvinit and x11 to load in 2 seconds.

I see no issue with that actually. SysV init isn't a requirement for X11, so I don't know why you're bunching those together. SysV is plenty fast though, but as soon as you start adding standard distro stuff in it, it slows down. Standard distro stuff would be hardware probing, looking for mountable FSes, etc, etc. Stuff you don't need on an embedded system.

X11 starts in <100ms on an ARM9 (no, not ARMv9, a 200MHz ARM9), assuming your display-driver doesn't spend a lot of time probing monitors and crap.
The key to starting X11 quickly is to not have any extensions you don't need (as they're all loaded when you start, making the disk IO the bottleneck), and configuring your inputs and displays in the config files and don't let X probe for them.

As for kernel boot time, have you looked into the "lpj" kernel argument? That usually shaves off 100ms or so from the boot-time for me.
 

Offline stmdude

  • Frequent Contributor
  • **
  • Posts: 479
  • Country: se
Re: Framebuffer GUI Toolkit
« Reply #12 on: October 24, 2017, 06:58:14 am »
I don't know much about Linux GUI, but isn't X11 supposed to be started in somewhere like RC.1 and being managed by sysvinit or systemd as a service? Can I run it without an init manager?

For a SysV _compliant_ system, runlevel 5 is supposed to start X. But X runs just fine without SysV-anything. It's just an app. Nothing magic. It'll get a bit cranky if you haven't setup your loopback interface and assigned it the 127.0.0.1/8 IP. A host-file entry for "localhost" probably wouldn't hurt either.

As for kernel boot time, have you looked into the "lpj" kernel argument? That usually shaves off 100ms or so from the boot-time for me.

Will take a look. Will add it to uboot and see how it works.

Ok, it's not quite that easy. What it does is to skip calculating the "loops per jiffy" variable on each boot. Meaning, you need to look at the kernel output from a boot without the lpj argument, take that loops-per-jiffy number and add it to the commandline like "lpj=123456".
 
The following users thanked this post: blueskull

Offline stmdude

  • Frequent Contributor
  • **
  • Posts: 479
  • Country: se
Re: Framebuffer GUI Toolkit
« Reply #13 on: October 24, 2017, 09:14:30 am »
My system displays 6.00 bogoMIPS? That's insanely slow!

Calibrating delay loop (skipped), value calculated using timer frequency.. 6.00 BogoMIPS (lpj=30000)

Any reason how can this happen?

FWIW, I set tick timer to 1ms instead of the default 10ms.

Many reasons. Kind of hard to tell from a distance. It could be how you changed the timer interval. It could also be that it's running at a "safe" frequency that early in the boot process, so you're measuring the LPJs of the CPU running at it's slowest frequency.

Unless the system is very, very sluggish, I wouldn't worry.  But, your kernel command line should be "lpj=30000". It's worth about 250ms of boot time.
 
The following users thanked this post: blueskull

Offline Whales

  • Super Contributor
  • ***
  • Posts: 1899
  • Country: au
    • Halestrom
Re: Framebuffer GUI Toolkit
« Reply #14 on: October 24, 2017, 10:32:58 am »
For what you're doing I'd definitely run and hide from a full toolkit.  Blitting pre-defined bitmaps would be perfect. You have no need for a full WIMP.

Quote
I don't know much about Linux GUI, but isn't X11 supposed to be started in somewhere like RC.1 and being managed by sysvinit or systemd as a service? Can I run it without an init manager?

I'm not sure if it was once the case that X11 could only be started by root.  These days it's definitely not true.

I don't run a graphical login manager, so my init does not start anything Xorg related at boot.  Once I login I run 'startx'.

Sidenote: I'd suggest steering clear of systemd if you can.  I've had some very bad experiences with it on both my desktop and my previous (ARM based, but that's mostly irrelevant) laptop.  From what I read I'm not the only one.  Systemd's goals are 'have every feature' and 'make Redhat great', not 'behave as I expect you to' or be simple.

Are you basing your environment off a pre-existing distro?  I've had success with Alpine Linux.  It's one of the 'comes with nothing by default' lightweight distros (unlike my old friend Debian).  It also provides an easy way for you to make your main filesystem read-only and any changes made to it temporary (lost upon shutdown); unless you intentionally run a command to save them.  I've found this useful for systems deployed remotely or given to other people.
« Last Edit: October 24, 2017, 10:37:37 am by Whales »
 

Offline Canis Dirus Leidy

  • Regular Contributor
  • *
  • Posts: 214
  • Country: ru
Re: Framebuffer GUI Toolkit
« Reply #15 on: November 01, 2017, 02:05:19 am »
SDL would be a nice option, but I have yet to find a widget library with RAD support.
What about MakiseGUI?
 
The following users thanked this post: blueskull

Offline technix

  • Super Contributor
  • ***
  • Posts: 3507
  • Country: cn
  • From Shanghai With Love
    • My Untitled Blog
Re: Framebuffer GUI Toolkit
« Reply #16 on: November 01, 2017, 04:52:38 am »
Just throwing this out here: GNUstep. By default it uses cairo on X11, but you can modify it into skipping X11 and spawn cairo directly on a framebuffer.

GNUstep does not have its own RAD tool, but due to its compatibility you can develop and test the apps on macOS using Xcode and copy them over later.

Speaking of, maybe give Apple's launchd a look as a potential systemd replacement? systemd started off as an imitation of launchd after all.

Or even more hard core, iOS's XNU kernel is open source. So XNU + FreeBSD libc + launchd + GNUstep = open source iOS imitation. You may even get to run stock iOS apps.
 

Offline voltsandjolts

  • Supporter
  • ****
  • Posts: 2277
  • Country: gb
Re: Framebuffer GUI Toolkit
« Reply #17 on: November 01, 2017, 10:10:19 am »
Pygame is nice and simple for quick display hacks.

I like the look of Kivy without X11 but haven't tried it yet.
e.g.:

 


Share me

Digg  Facebook  SlashDot  Delicious  Technorati  Twitter  Google  Yahoo
Smf