site  contact  history  index

Inkscape compiled in OpenEmbedded

April 10, 2021 — BarryK

As already posted, I have recompiled everything in OE:

https://bkhome.org/news/202104/dunfell-recompile-commencing-in-openembedded.html

Also added 'pngoverlay-cairo':

https://bkhome.org/news/202104/pngoverlay-cairo-utility-now-in-woofq.html

Cross-compiling can be a challenge with some packages, and some of the big ones, such as SeaMonkey, LibreOffice and Inkscape, I have compiled in a running EasyOS (with the "devx" SFS loaded).

I have previously compiled LibreOffice in OE, see the Pyro series. But it was a lot of work.

Today I have imported Inkscape into OE. Had to import these dependencies into OE:

double-conversion potrace gdl

Then inkscape compiled, no issues. Good, I congratulate the developers on a well-behaved build. It is version 1.0.2.

My latest OE, based on the Dunfell release, is available as a tarball. It is really just the Dunfell release of OE with my "meta-quirky" layer. The tarball has some documentation. Available here:

http://distro.ibiblio.org/easyos/project/oe/dunfell/dunfell-20210410.tar.gz

...there is no git repo, just these tarballs, that are snapshots of my local system. My host OS is EasyOS Dunfell-series 2.6.2 x86_64, with "devx" loaded. You need a partition with at least 350GB free -- my build was done on a new 1TB SATA SSD (connected via USB3), and so far using 326GB. If I was to do another build, for a different target, say i686, then the used storage would jump way up -- so good to have 1TB drive.    

Tags: oe

pngoverlay-cairo utility now in woofQ

April 09, 2021 — BarryK

EasyOS, and older pups, have the 'pngoverlay' utility, which overlays two 48x48 PNG images. We use it to create the "close box" on the partition icons on the desktop.

/usr/sbin/pngoverlay is written in BaCon, and has been very troublesome. It requires the executable to be in the same folder as the icons, if build it in OE, a cross-compile environment, it compiles but segfaults when try to use it. It changes the "PWD" variable, that I commonly use in scripts -- that one took me by surprise!

We also have /usr/sbin/pngoverlay.sh, that uses 'netpbm' utilities. It was broken but I fixed it in 2020.

Mick (01micko on the forum) has written two replacements in C, 'pngoverlay-gtk' and 'pngoverlay-cairo'. I am now retiring the BaCon 'pngoverlay' and using Mick's 'pngoverlay-cairo'. See info here:

https://github.com/puppylinux-woof-CE/woof-CE/issues/1470

As posted this morning, have recompiled everything in OE. Will add source package 'pngoverlay-cairo-20190623.tar.gz' to the build. The source package will be hosted on ibiblio.org soon.

I have modified these scripts in woofQ to recognize 'pngoverlay-cairo' and use it if exists. Just in case, the fallback will be to use 'pngoverlay' if doesn't exist:

rootfs-skeleton/usr/local/easy_containers/easy-containers
rootfs-skeleton/usr/sbin/icon_switcher_cli
rootfs-skeleton/usr/sbin/icon_switcher
rootfs-skeleton/usr/local/sfsget/dir2sfs
3buildeasydistro

Note, the BaCon 'pngoverlay' is in the 'pup-tools' package, will pull it out.   

Tags: easy

Dunfell recompile commencing in OpenEmbedded

April 09, 2021 — BarryK

Gwhere is a "removable media catalogue manager", quite interesting, but I don't know if anyone uses it. It has been in Puppy since the early days, and is very old and shaky code. We have patched it and patched it, but yesterday I noticed that 'wdlkmpx' has done a lot of work on it:

https://github.com/wdlkmpx/gwhere

So decided to drop my badly-hacked source. Now have the latest source from wdlkmpx's github repo in OpenEmbedded.

There is another chap who is an audiophile and wants to use the 'jack' server in EasyOS. So I have added the jack package to the build-list, and enabled support for jack in these packages:

ffmpeg mpv xine-lib mhwaveedit audacious

From a bit of reading, it seems that ideally the kernel needs to have some real-time features enabled for jack to work well.

As far as I know, having support for jack in those apps doesn't mean we have to use it. It is an optional server.

Oh, I was going to type "tonight will commence a complete rebuild in OE", but I see it is already after midnight. OK, so commencing today. It takes about 9 hours.

Note, the latest OE tarball will be here, will upload it soon:

http://distro.ibiblio.org/easyos/project/oe/dunfell/ 

One more thing: Have also added 'modemmanager' package to the build-list, and added it as a dependency to 'networkmanager' and 'network-manager-applet' packages.

There has been some discussion recently about "modem thingys" that might require 'modemmanager'. I don't know, but anyway, it will be available for anyone who might want it. has it's own GUI even, that will be in the "Network" menu.

EDIT 2021-04-09:
Also compiling Osmo personal information manager with support for libnotify. Now it will be able to put up notifications, making it a much more complete PIM.
   

Tags: easy

Some considerations for 5V solar charging

April 08, 2021 — BarryK

A couple of days ago, I posted a comparison of two small 5V solar panels:

https://bkhome.org/news/202104/comparison-of-claite-10w-and-se05-5w-solar-panels.html

And I am looking at replacing the switching regulator in the CLAITE "10W" regulator with my own design linear regulator, similar to the one I constructed in 2016:

https://bkhome.org/light/solar/panels-small-2016.htm

For that regulator, I used a LM2940 LDO (Low Drop Out) regulator, 5V at 1A maximum output. This time, I would like the design to handle higher current. Not that I really need to handle higher current, as that "10W" panel is so pathetic -- I did a quick test of it today, bypassing the regulator, to find out what it is really capable of, and only got about 0.7A at the peak power point, however, sky was a bit misty and solar intensity was only 815W/m2.

Even if I can get solar intensity up to around 1000W/m2, it looks like won't be getting 1A out of that panel. Which will be under 5 watts, probably well under.

Anyway, would like to construct a linear regulator that can handle about 5V @ 1.2A. Altronics sell an LDO that is rated at 5A:

https://www.altronics.com.au/p/z0580-lm1084it-5a-5v-low-dropout-regulator/

...HOWEVER, it is not suitable. The voltage drop from input to output is at least 0.8V, which is too high. Dredging back into my memory, I see from the internal circuitry, that the high voltage drop is due to the darlington transistor configuration. Also, it does not have reverse current protection, and a schottky diode would be required to prevent current flow back into the panel -- which will cause more power loss when charging current is flowing.

Found this one, L4940V5, rated at 1.5A max., pretty much the same design circuitry as the LM2940, with even lower voltage drop, around 0.3 to 0.4V. Meaning, that if 1A is flowing through the transistor, 1x0.4 is 0.4W -- no heatsink required. It is that PNP transistor configuration that achieves the low voltage drop. Ordered it from eBay:

https://www.ebay.com.au/itm/L4940V5-ST-Microelectronics-5V-Positive-LDO-Voltage-Regulator-TO-220-GENUINE/202370864172

Also available from other vendors, such as:

https://au.rs-online.com/web/p/voltage-regulators/2988491/

img1

In the above link to tests done in 2016, I mentioned how the Chinese phones determine if a charger is limited to 0.5A or is capable of up to 1.7A. Simply by shorting D+ and D- together marks the charger as capable of the higher current. This article explains:

https://www.eetimes.com/how-to-conform-to-chinas-new-mobile-phone-interface-standards/

...what is also very interesting in that article, is it shows details of the circuitry inside a phone.

Actually, that detail of connected D+ and D- together is a USB standard:

https://en.wikipedia.org/wiki/USB_hardware#Power

...it also mentions how the requirements for Apple phone is different.

The above article contains links to PDFs that show charging circuits, and it does look possible to satisfy both Android and Apple high-current determination, with three resistors.   

Tags: light

Wallpaper corruption in containers maybe fixed

April 07, 2021 — BarryK

When you bootup EasyOS, on the desktop there is an icon labelled "dunfell", clicking which will launch the entire Dunfell 2.6.2 desktop in a container. The key combination ALT-F6 flips back to the main desktop. Other puppies can also be run in a container.

A problem we have had right from the start, is wallpaper corruption in the container. It is ROX-Filer that manages the desktop wallpaper and icons, and the instance of ROX that runs in the container is not completely isolated from the ROX on the main desktop. I have not been able to understand exactly what the cause of the problem is, but a "sleep 4" after starting JWM and before running ROX results in OK wallpaper -- but not always, it seems some PCs require longer sleep.

What this means is that when you click on "dunfell" the first time, which sets up and starts the container and switches into it, there is a delay where you will see the JWM tray along the bottom, the rest of the screen white, for about 4 seconds, then the desktop icons and wallpaper appear.

I was extremely interested in the overhaul of the /proc filesystem in the 5.8+ kernel, and I thought this might be the fix. Phoronix have explained:

https://www.phoronix.com/scan.php?page=news_item&px=Linux-5.8-Modernizes-Procfs

Running the 5.10.26 kernel, I have reduced that startup delay from 4 to 0.5, and not getting wallpaper corruption. I tested on three different PCs, including my old Compaq Presario, and consistently got a non-corrupted desktop.

I didn't do anything different when mounting /proc, it seems the overhaul has made each mount of /proc more of an independent proper filesystem, so /proc in the container is more independent. So it seems.

Of course, if someone posts that they are getting wallpaper corruption with EasyOS 2.6.2 Dunfell-series, that will shoot down my theory that the 5.10 kernel has fixed the problem. Anyway, the delay is now 0.5 seconds, so startup of the container will be much faster.  




Tags: easy

Osmo crash fixed

April 06, 2021 — BarryK

Testers of EasyOS 2.6.2 Dunfell-series have reported that Osmo personal information manager crashes when try to create a new contact:

https://forum.puppylinux.com/viewtopic.php?f=63&t=2562

As I posted in that thread, this is an old problem, that applies to all pups:

http://www.murga-linux.com/puppy/viewtopic.php?t=115567

I also posted that 'wdlkmpx' has applied some patches to the 0.2.10 version of osmo:

https://github.com/wdlkmpx/osmo

Note that we use version 0.2.10 of osmo, as that is the last that uses libhtml2 for markup. Later versions of osmo require webkitgtk, which is an enormous package.

libhtml2 is small and is used in a couple of other apps in EasyOS and the pups. One of them is Notecase, the other is Surfer (the small html file viewer used in EasyOS for viewing local help documents).

So please don't recommend that we upgrade osmo! We will keep patching it for as long as we can.

It is suggested in the Murga Forum thread linked-to above, that libxml2 version is to blame. I found that 2.8.0 is too old, a required function is missing. However, 2.9.0 works.

What I have done is build the osmo executable by linking it statically with libxml2.a from the 2.9.0 package. This results in a somewhat larger 'osmo' binary, that works in EasyOS and there is no conflict with the later version libxml2 shared libraries in Easy.

This will be in the next release of easyOS, but you can grab it now if you want:

http://distro.ibiblio.org/easyos/amd64/packages/pet/pet_packages-dunfell/osmo-0.2.10-dunfell64.pet

...you don't necessarily have to install the PET, you could just open it up and copy the 'osmo' binary to /usr/bin.

This might work in other recent pups, you will have to try it and see.

Oh, should mention: I have given with one hand and taken with the other. Accidentally left out libical support.
If someone figures out a patch to fix the crash, that would be the best solution, what I have done is just a workaround. Whatever, plan to put a fix into the OpenEmbedded recipe and rebuild, and include libical support.

EDIT 2021-04-7:
We have a fix! 'wdlkmpx' determined that it is libgtkhml2 that is causing the crash. It requires a patch for libxml2 2.9.5+. See his patches here:

https://github.com/wdlkmpx/libgtkhtml2/commits/master

I have put this patch into the recipe for libgtkhtml2 in OpenEmbedded, and will rebuild that library.  

Tags: easy

Comparison of CLAITE 10W and SE05 5W solar panels

April 05, 2021 — BarryK

I tested the SE05 "5W" 5V solar panel in 2016:

https://bkhome.org/light/solar/panels-small-2016.htm

I recently purchased the CLAITE "10W" 5V solar panel:

https://bkhome.org/news/202103/10w-solar-panel-for-usb-charging.html

It has been cloudy recently, but today the clouds cleared, just a bit of faint mistiness, so did a quick comparison of these two panels.

Date is April 5, 2021, 1.00pm, fairly clear sunny sky, solar intensity reading is 830W/m2, ambient temperature is 30 degC -- Autumn, but quite a warm day. Negligible breeze.

I used resistances to place different loads on the panels, and plotted voltage-current graphs. Here is the CLAITE "10W" panel:

img1

Here is the graph of the SE05 "5W" panel:

img1

...in the latter graph, see the foldback effect, which I think is a very good feature.

For the SE05, the peak power point is about 4.78V @ 0.59A, which is 2.8W. For the CLAITE panel, peak power is only about 4.86V @ 0.6A, which is 2.9W. You see why I am putting those "5W" and "10W" ratings in quotes!

Hmmm, it seems that the CLAITE panel is throttling its output. It has a short-circuit current of 2.16A, which is an indicator that this panel potentially has a much higher peak power point.

I did a quick test connecting the CLAITE panel to two Android phones, and got 0.52A and 0.57A. My 2016 post explains D+ and D- pin connections required for Android phones. Shorting D+ and D- together made no difference.

Measuring the resistances between the GND, D+, D- and 5V pin on the USB socket, there are resistors connected to D+ and D-, indicating this panel is designed to charge Apple devices, not Android devices. Here is information for Apple devices:

https://www.instructables.com/Modify-a-cheap-USB-charger-to-feed-an-iPod-iPhone/

https://learn.adafruit.com/minty-boost/icharging

Anyway, connections of the D+ and D- pins does not matter when just applying resistance loads, as I did for the above graphs. The regulator in the CLAITE panel is throttling the output. It should not be doing that.

It looks like I will have to sacrifice this panel, see if can open up that regulator, maybe replace with my own that I built in 2016 -- see link at top of this post.

EDIT 2021-04-06:
Today, just after 11am, I noticed that the clouds had cleared, just some wispy clouds off to the sides, but quite intense blue overhead. Did a very quick test with the CLAITE panel, time 11.30am, April 6, 2021, Perth, Western Australia, sun intensity 885w/m2, ambient temperature 27 degC. Negligible breeze.

I did this very quickly, didn't allow the panel to completely warm up in the sun. Just brought it out from inside, aimed it at the sun, running through an inline voltage-current digital meter, and wrote down the readings.

Charging my Huawei phone, a 2019 model that I actually purchased early 2020 (so I escaped the Google embargo), battery was at 93% and the charging was 4.90V @ 0.78A, which is 3.82W.

Then plugged in my Voltaic V15 battery bank, which is approximately 50% charged, and read 5.05V @ 0.62A, which is 3.13W.

I expected better with the stronger sunlight, but those reading are nowhere near the claimed 10W!

I need to find out what the panel is actually capable of, without the regulator getting in the way. I used a serrated kitchen knife to cut the plastic covering, exposing the regulator:

img1

...at the bottom are the two tabs from the panel, so I should be able to remove the regulator and solder directly to those tabs. The glue is flexible, probably a silicone sealant, so should be able to pry the board off.

The main chip is "XL1410E1" and on the next line "01103". Would be interesting to find the specs on it.   

Tags: light

Serious Xorg Wizard bug fixed

April 05, 2021 — BarryK

The Xorg Wizard is script /usr/sbin/xorgwizard-cli. If exit from X via the Shutdown menu, type "xorgwizard" at the prompt, and the wizard will run, in text-mode. Note that /usr/sbin/xorgwizard will just run xorgwizard-cli.

The wizard detects "hybrid" video systems, that is, those with two video hardware interfaces. This could be a plugin card, or in some cases there are two video interfaces on the motherboard. An example is the video interface builtin to the Intel CPU chip, and a second one, perhaps an Nvidia GPU.

The script was getting confused, thinking that the 'modesetting' driver is a second GPU. The details are difficult to explain, but the point is, it is fixed.

The confusion caused Xorg to no longer work. My PC has Intel video, no second GPU, and when chose Xorg 'modesetting' driver, the script wrote "options i915 modeset=0" to /etc/modprobe.d/i915.conf, and Xorg failed.

Both the Xorg 'intel' and 'modesetting' drivers require kernel modesetting to be on, that is "options i915 modeset=1" which passes the parameter "modeset=1" when the kernel 'i915' module loads. That is the default anyway.

it is working nice now, can flip between using the Xorg 'intel' and 'modesetting' drivers, desktop loads, no issues.   

Tags: easy