site
contact
newsFirst go at evaluating LittlevGL
As posted about a couple of days ago on this blog, I have an
interest in creating small GUI apps that will talk directly to the Linux
framebuffer. Here is the post:
http://bkhome.org/news/201808/gui-creation-for-the-linux-framebuffer.html
I tentatively narrowed the choices down to LittlevGL, uGFX and Nuklear. LittlevGL looks great, so giving it a go. The website:
https://littlevgl.com/
The "PC simulator" looks like a good starting point:
https://littlevgl.com/pc-simulator
...so, I followed the instructions. Installed Eclipse IDE, etc. Got to this part:
Now you are ready to run the Littlev Graphics Library on your PC. Click on the Hammer Icon on the top menu bar to Build the project. If you have done everything right you will not get any errors. Note that on some systems additional steps might be required to "see" SDL 2 from Eclipse but in most of cases the configurtions in the downloaded project is enough.
After a success build click on the Play button on the top menu bar to run the project. Now a window should appear in the middle of your screen.
Now everything is ready to use the Littlev Graphics Library in the practice or begin the developement on your PC.
...er, no, that didn't work. Yeah, the "Hammer Icon" part is OK, it
reported a successful build, however, the "Play" button did nothing.
Searched the source, couldn't find the compiled files anywhere. Hmmm...
It turned out, the instructions are incomplete, extra steps are required, as explained on YouTube:
https://www.youtube.com/watch?v=ZzLdct2ymvg
However, decided to start again, from scratch. I was not drawn to the
Eclipse IDE, it seemed unnecessarily complex, and bloated, requiring
Java JRE. Will attempt to do it from a terminal only.
To keep a clean separation, will create another blog post...
LVGL evaluation Part-2 here:
http://bkhome.org/news/201808/tentative-first-step-framebuffer-with-littlevgl.html
Tags: linux
GUI creation for the Linux framebuffer
For a long time I have wanted some means of creating very small
GUI apps that are statically compiled and work directly with the Linux
framebuffer. The use would be for a GUI app in the initramfs.
I recently discovered LittlevGL, and then decided to ask for the
opinion of two guys who are real experts in this field, 'technosaurus'
and 'goingnuts' (their Puppy Forum names).
https://littlevgl.com/blog/23/embedded-gui-using-linux-frame-buffer-device-with-littlevgl
I sent a pm on the Puppy Forum to technosaurus, and he responded:
littlevgl has been on my radar for a while now - I
do like it, but its no gtkdialog replacement; you can see more of my
projects of interest at https://github.com/technosaurus?tab=stars
I am in the process of moving from near Houston, Texas to near Kansas
City, Missouri (U.S.) We have moved 3 times in 3 years so I have not
been coding for some time - just reading/analyzing code for future use
(thus all the starred projects, but few commits)
Besides littlevgl, the ones I know of that will work for the framebuffer (and X) are:
https://github.com/vurtun/nuklear forum thread here
https://github.com/memononen/nanovg + oui/blendish
https://github.com/ImpulseAdventure/GUIslice (uses SDL)
https://github.com/grz0zrg/fbg (lacks widgets)
more gtkdialog-like:
http://lcui.org/ some largish dependencies (libpng,libjpeg,
libxml2,freetype,fontconfig)
http://tekui.neoscientists.org/ possibly unmaintained and needs freetype and lua - uses any raw framebuffer (or X11 depending on configuration)
Some notes.
For the ones that use opengl (or GLES) a specially built Mesa is needed
and some framebuffer drivers are not supported because they lack support
for kernel mode setting (unfortunately no one has ported Fabrice
Bellard's tinygl as a fallback)
littlevgl seems to be a retained mode GUI like gtk and kde (but seems to
be simplified so that you need ~1/3 less code than gtk and without the
huge overhead of c++ and qt) There is a template here and it seems to be targeted to Linux with growing driver support
nuklear and nanovg are immediate mode GUIs which cater toward game
development and tend to use more CPU, though nuklear appears to have
addressed this since I last tested it. However, since they are single
header files, anything unused will get compiled out so they make small
binaries.
https://bitbucket.org/duangle/oui-blendish/src
GUIslice could be a good compromise since it uses SDL (1.2 or 2.x) which
will handle the framebuffer (or X) for you. It isn't as pretty though -
basically an improvement on curses.
I was aware of Nuklear, and did look at it briefly a year or so ago.
Here is another one, uGFX:
This is a commercial product, free for "home, hobby and educational"
use. It is an open source project, and will work with sdl or directly
with the framebuffer. Git project site:
Tags: linux
Nheko Matrix chat client
Purism are using Matrix for chat forums, including for the Librem 5 phone:
https://developer.puri.sm/Contact.html#matrix-chat-rooms
So, decided to give it a go. There are various Matrix client apps, and I compiled Qt5-based Nheko:
The PET for EasyOS 0.9.5+ (not yet released) is here:
http://distro.ibiblio.org/easyos/amd64/packages/pet/pet_packages-pyro/nheko-0.5.1-pyro64.pet
Dependencies are 'olm', 'libsodium', 'liblmdb', which are also PETs.
Also 'boost' version 1.66, which is in the upcoming Easy 0.9.5.
Nheko, at startup, offered to register, where a username, password,
and "Home Server" can be entered. For the latter, I entered
"matrix.org", and a captcha came up in the browser to verify that I am a
human.
After starting Nheko, I was in my own "room",
"@<myusername>:matrix.org", but unable to change out of it. Nheko
is lacking some features, but is under rapid development.
I logged in at the online browser Matrix client:
Logged in, I was able to ratify a user-agreement, that then allowed
changing rooms. I was also able to personalize my account, with email
and avatar, which cannot be done in Nheko.
Started up Nheko, logged in, then hit the "+" icon and was able to
change rooms. Chose "#community-librem-5:talk.puri.sm", and yay, there
it is!
Hmmm, perhaps it is easier just to use the online client.
Devuan package repositories
I mystery. I am getting woofQ setup for building from Devuan DEB
packages. There used to be a 'merged' directory, which I think had all
of the specially-modified non-systemd DEBs, plus everything else from
the Debian repo.
However, looking in the Devuan repo for the latest release, Ascii
(2.0), which is based upon Debian Stretch (9.0), the 'merged' path is,
well, not merged.
It seems that we have to get the Devuan-modified DEBs from the Devuan repo, and the rest from the Debian repo.
Here is a mirror of the Devuan repo:
http://mirror.vpgrp.io/devuan/pool/main/
...look in folder 'a', no 'abiword' (for example).
To get abiword, we have to go to the Debian repo, for example here, look in 'a':
http://http.us.debian.org/debian/pool/main/
Some guys have been creating Devuan-based Puppies. Forum member musher0 did a Jessie-based Devuan:
http://murga-linux.com/puppy/viewtopic.php?t=107913
Forum member Sailor Enceladus did a Ascii-based Devuan:
http://murga-linux.com/puppy/viewtopic.php?t=109842
EDIT:
The light has come on. The package database at merged/dists/ascii/binary-amd64/Packages.xz has everything, the Devuan and the Debian DEBs. In the field that has the path to the DEB, there is "pool/DEVUAN/..." or "pool/DEBIAN/...", and the online repository at merged/pool/main has a server rewrite rule, that redirects to wherever the DEB actual is.
Tags: linux
PureOS 8.0 Linux distribution
As I have ordered the Librem 5 phone dev-kit, which will have a
PureOS-based distribution on it, I thought that probably the upcoming
docs might assume a host development PC to be running their x86_64
PureOS, so I installed it. Downloaded from here:
http://downloads.puri.sm/live/gnome/2018-05-30/
Burnt it to a DVD, booted and the menu offered "Test or Install",
which booted up running in RAM. Clicking top-left, some icons dropdown,
and I chose "install", which runs the "PureOS Installer".
It is quite a nice installer. I was able to chose one partition that
had nothing in it (sda5), and not to install a boot manager (as I
already have ReFind, that I will edit manually). I took the precaution
of unplugging one of the hard drives, my main work drive.
It installed OK, except changed some of the drive partition
numbering, which was odd. Even odder, it changed the labels on all of
the partitions -- unexpected and not nice!
Also, it changed the hardware clock to UTC, whereas I have it set to
localtime. I hate it when an installer does that. It is saying, to hell
with the other OSs, this is how it is going to be! There was nowhere
after bootup to choose UTC or localtime for the hardware clock. Later, I
booted Easy and changed the hardware clock back to localtime. Then
rebooting PureOS, it was still correct time, as it was reading it from
the Internet.
The file manager is the usual awful Gnome thing, so dumbed down.
One more thing: at first bootup it asked for a new password, and
there was a checkbox to bootup without password -- except it doesn't
work, requires a password.
Using PureOS was OK, just a matter of getting familiar with where
everything is, but whenever I test a Linux distro, I always feel
relieved when I get back to Easy/Quirky/Puppy.
https://pureos.net/
Back in mid-2016, I compared the Ubuntu and Debian installers:
http://bkhome.org/news/201606/installers-for-debian-vs-ubuntu.html
Tags: linux
Aboriginal Linux 1.2.0.x resuscitated
Over the years, developing Puppy and derivatives, I have had a need to compile some utilities statically.
It has been ad-hoc, using different uClibc and Musl filesystems. Now, I
am making it more formal, and reproducable and useable by anyone.
Rob Landley's Aboriginal Linux is an archived project. I am bring it back, specifically the uClibc based version.
Introduction is here:
http://distro.ibiblio.org/easyos/project/aboriginal/readme.htm
Download (228MB):
http://distro.ibiblio.org/easyos/project/aboriginal/aboriginal-project-1.2.0.2.tar.gz
And what to do after downloading:
http://distro.ibiblio.org/easyos/project/aboriginal/start.htm
if anyone is interested, you are welcome to play!
Forum feedback:
http://murga-linux.com/puppy/viewtopic.php?t=112885
Have fun!
Tags: linux
Finally, success with OpenADK
I wanted the 'dmsetup' utility compiled statically, for use in
initramfs. This is in the LVM2 package. It turned out to be a saga of
many many hours...
Unfortunately, both OpenEmbedded and Landley Aboriginal dropped
support for uClibc, going over to musl. What is really odd, is the
developers on both of these projects gave the same reason, that uClibc
is a dead project. That is very odd, as uClibc-ng is very active. Were
they ignorant of the existence of uClib-ng? -- incredible if so.
Anyway, musl. have used it many time, just don't like it. uClibc is
far more glibc-compatible, and hence far easier to compile source
packages.
I did attempt to compile 'dmsetup' in an Alpine Linux x86_64 musl
rootfs, but finally used Landley's Aboriginal x86_64 uClibc rootfs,
version 1.2.0 -- very old, but it works great. year 2012 in fact.
However, uClibc does not have the fmemopen() function, so I had to
compile an older LVM2 that does not require that function -- version
2.02.119. Success, compiled it statically, about 500KB stripped.
OpenADK
I ruminated on what other rootfs's and toolchains there are out
there, that will have a recent version of uClibc. One of them is
OpenADK, that I have tried a few times over the years, always failed,
see these reports:
http://bkhome.org/news/201606/playing-with-cross-compile-toolsets.html
http://bkhome.org/news/201704/openembedded-morty.html
Decided to have another go!
Downloaded the latest snapshot, ran "make menuconfig" and then
"make", hit some failures, fixed them, but finally gcc compile failed
with "unable to determine size of (long long)".
Scratched my head for sometime over that, but then it occurred to me
that my host system might not support "long long". That does not seem to
good, but anyway. My host is EasyOS Pyro64, the packages were compiled
in OpenEmbedded, targeting embedded systems, and perhaps this is one
compromise.
So, went over to Quirky Xerus64 8.5, which is built with Ubuntu 16.04.4 DEBs. This time success:
# make distclean
copy DOTconfig to .config
# make menuconfig
# export FORCE_UNSAFE_CONFIGURE=1
# make
copy /usr/bin/autom4te to openadk/host_x86_64-oe-linux/usr/bin/
# make
...as you can see above, a couple of little tricks were required, the
"export FORCE_UNSAFE_CONFIGURE=1", and coreutils wanted a "autom4te"
file.
Tags: linux
Easy network printing with CUPS
I have been trying all day to setup printing over a small
network, just two PCs running Easy 0.6.6, connected to an ethernet
router (and to the Internet via wi-fi wan, to my mobile phone hotspot).
One PC, my "midi-tower", has a Brother HL-2040 laser printer
connected via USB port. Local printing works fine. The other PC is my
Mele "mini-pc", and I want to be able to print from it.
The problem is, I cannot get the "ipp" protocol to work. I have
studied online documentation, and can get the client machine, my
mini-pc, to see the remote printer, however when do an actual print, get
the dreaded "Filter failed".
As stated, I have messed around all day, trying different things.
Then, I found something that "just works", very simple. I would like to
acknowledge "paulkerry" for this info:
https://bbs.archlinux.org/viewtopic.php?id=206669
Just a comment: there is a lot of outdated, vague, ambiguous and
misleading documentation about CUPS online. For example, one "very
official" site explained the format of the ipp protocol as:
ipp://hostname/printers/printername
...without explaining that only "hostname" and "printername" must be
substituted, and the text "printers" must be left as-is. There wasn't
even an example, nor was it properly explained how to find the
printername.
Anyway, I did learn how to specify ipp properly, but got stuck at "Filter failed".
The method described by paulkerry works, so here is a little tutorial
to explain how to set it up. Note, I plan to semi-automate this, by
extending QuickSamba, which I plan to rename to EasyShare. Anyway, the
tut...
1: Firewall
I ran the firewall setup on both client (my mini-pc) and server (my
midi-tower) PCs, so that the CUPS port (631) is enabled. In this
snapshot, I have also enabled Samba ports, but that isn't necessary for
just printing with CUPS:
On the server-PC, just setup the local printer as you normally would, but tick some extra boxes...
2: Server PC
You need to have the cupsd daemon running and point the web browser
at http://localhost:631. In Puppy/Quirky/Easy, you do this by running
the "CUPS Printer Wizard":
A window will popup asking if you want to add a new printer, and you click "Yes", then you will get the CUPS web interface:
...click on "Adding Printers and Classes", then the next window:
...click each of those, 1, 2, 3 and 4. Do not miss "Change Settings".
Probably "Allow remote administration" is optional, but I enabled it,
as I was then able to bring up the CUPS web interface of the server-PC
on my client-PC. Next window...
...well, anyone who has setup a local printer will be familiar with
this. Continuing, as per usual, except an important checkbox to tick...
...the first two boxes are pre-filled. It is not essential, but useful,
to fill "Location". And, you must tick "Share This Printer".
In the next window, you choose a driver...
And set some printer options...
That's it, the server-PC is setup. Before setting up the client, you
will need to know the IP-address of the server. A few ways of doing
that. Open a terminal and type "ifconfig", and you will see it -- in my
case it is "192.168.0.3":
In Puppy/Easy/Quirky, there is no need to edit the
/etc/cups/cupsd.conf main configuration file, as it is pre-configured
OK. Note, for this tutorial, I am running pristine EasyOS Pyro64 version
0.6.6.
Now for the client-PC...
3: Client PC
Over on my Mele mini-pc, setup is easy-peasy. I created file /etc/cups/client.conf...
...with content just one line, "ServerName <ip address of server>"
Finally, restart the cupsd daemon...
...and run "lpstat -t" to verify that the remote printer is found.
That's it, nothing more to do. If you ran an application and choose
"Print...", the remote printer will be offered, in my case, my Brother
HL-2040.
Also, the CUPS web interface of the server can be accessed from the
client, by going to "http://192.168.0.3:631" in the client web browser.
As stated, I have thoughts how this setup can be semi-automated,
including automatic creation and update (if the ip-address changes) of
/etc/cups/client.conf. Stay tuned.