Raspberry Pi Zero W and Funtoo

After finding the PaPiRus ePaper panel, I picked up a Raspberry Pi Zero W to drive it. To be perfectly honest, the early Raspberry Pis never really excited me. However, the Raspberry Pi Zero’s small footprint caught my attention. Add in WiFi and Bluetooth, as found on the Zero W, and you have a solid IoT starter board.

Thanks to the popularity of the Raspberry Pi, both Funtoo and Gentoo have guides on setting up Funtoo/Gentoo on a Raspberry Pi. Getting a base system up and running is straightforward. Though, if you have to compile anything it will take a while.


Getting WiFi to work requires some compiling. Funtoo’s guide for setting up WiFi on the Raspberry Pi 3 works for the Zero W for the driver side. On the userland side, you will probably want something like NetworkManager and wpa_supplicant. Unfortunately, neither package come installed in the base install for Funtoo/Gentoo.

Normally, chrooting in from a liveCD with working networking, installing the requisite package, and rebooting is sufficient. However, in this case, you’ll need to setup Qemu on your workstation and then use it to chroot into the ARM environment to compile and install NetworkManager. This will take quite some time.

Playing with PaPiRus

PaPiRus is a ePaper pHAT for the Raspberry Pi Zero. It contains an I2C LM75 temperature sensor, a few push button switches, a SPI NOR flash, and a ePaper panel. Unfortunately, it does not have an I2C memory device to store the device tree overlay information needed for auto-configuration of the SoC.

Since the installer for PaPiRus’ driver, and the manual instructions for that matter, assume a Debian based system, they do not work with Funtoo. Instead, follow the “Install Driver – Option 2” instructions, and rather than apt-get, use the following:

emerge -av sys-fs/fuse dev-python/pillow media-fonts/freefonts

After running make rpi-install the last few steps diverge from the “Install Driver – Option 2” instructions. Since Funtoo by default uses OpenRC rather than Systemd, the epd-fuse.service isn’t going to work. Instead, the OpenRC script below can be used (save as /etc/init.d/epd-fuse).

# Copyright 1999-2007 Gentoo Foundation
# Distributed under the terms of the GNU General Public License v2


depend() {
        need localmount

start() {
        EPD_OPTS="-o allow_other -o default_permissions"
        ebegin "Starting epd-fuse"
        mkdir -p $EPD_MOUNTPOINT
        if ! grep -qw fuse /proc/filesystems; then
                modprobe fuse >/dev/null 2>&1 || eerror $? "Error loading fuse module"
        if ! grep -qw $EPD_MOUNTPOINT /proc/mounts; then
                /usr/sbin/epd_fuse --panel=$EPD_SIZE $EPD_OPTS $EPD_MOUNTPOINT >/dev/null 2>&1 || \
                        eerror $? "Error mounting control filesystem"
        eend ${?}

stop() {

        ebegin "Stopping epd-fuse"
        if grep -qw $EPD_MOUNTPOINT /proc/mounts; then
                umount $EPD_MOUNTPOINT >/dev/null 2>&1 || \
                        eerror $? "Error unmounting control filesystem"
        eend ${?}

After saving the epd-fuse script, rc-service epd-fuse start can be used to start the driver. Of course, installing Systemd and uninstalling OpenRC is an option. However, that is quite a bit of effort for something that is overkill for a Raspberry Pi.

Other things to consider, while Funtoo places fonts under /usr/share/fonts, the font packages and directory structure of /usr/share/fonts differs from what PaPiRus expects. The easy way to resolve this is to modify the examples with the correct font location.


Rather than the older module blacklist/modprobe method for enabling various SOC features, the Raspberry Pi kernel has moved to Device Tree Blobs. Which is not entirely bad. However, they can be difficult to get working.

For short-term testing, to get the PaPiRus to work, I ended up using dtoverlay to enable the SPI and I2C buses, and then had to use modprobe to remove the LM75 driver so that the I2C bus was available to the epd-fuse driver.

-John Havlik

[end of transmission, stay tuned]

Dell TB16 vs TB15

A year and a few months ago, I picked up a Dell TB15 to use with my new XPS 15 9550. Since then, the TB15 was discontinued due to hardware issues. Last December, the WD15 as the only available replacement, even though its link was USB C, not Thunderbolt 3 like the TB15. However, Dell has since released the TB16, which officially replaces the TB15.

Since January, Dell has replacing existing TB15 units with TB16 for customers who open a support ticket requesting an exchange. Additionally, it appears that Dell is, as of late April, proactively sending out TB16 units to those who purchased a TB15 unit from Dell.com—this is how I ended up with a TB16. In addition to the TB16, Dell includes a letter explaining the exchange process and a shipping label for returning the old TB15.

The Hardware

As the official successor to the TB15, the TB16 is extremely similar to its predecessor. It contains the same assortment of IO ports, and is physically the same size. Externally, the only change is the addition of two thermal vents, one on each of the two sides without ports. Internally, there is a fan that spins up after being powered for a while when driving a monitor.

Linux Compatibility

In the case of the XPS15 (and other Dell products), make sure in the UEFI settings that Thunderbolt Security is set to “No Security”. This appears to be the only mode that works with Linux at the moment. In the other modes, only the monitor ports work. The Ethernet adapter and audio ports appear as USB devices. Frankly, it looks eerily similar to the WD15.

The Ethernet adapter is a Realtek RTL8153, which your kernel may or may not have a driver compiled in. If not, you can find it under Drivers > Network Devices > USB. The Audio adapters is a Realtek device. Again, this is a USB device (device ID 4014. This device appears to work with the snd-usb-audio driver.

Of course, the advantage over the WD15 is being able to drive more than just two 1080p displays. It definitely can drive a 4K display at 60Hz. Additionally, hot-plugging and hot-unplugging works.

-John Havlik

[end of transmission, stay tuned]

Making Sense of the *title Breadcrumb Template Tags

Currently, there are several, closely related template tags that each exhibit slightly different behaviors. These are: %title%, %htitle%, %ftitle%, and %fhtitle%. As their names suggest, they will be replaced with the resource’s title. However, how this title is processed differs between the tags.

Note that the “Max Title Length” setting is deprecated. Hence, both %ftitle% and %fhtitle% are deprecated and not recommended for use. They are included in this discussion for the sake of completeness.

Below is a table outlining the behavior of these tags for the same title with the max length set to ~10 characters and with the max length setting disabled.

Template Tag Max Title Length1 Title Result
%title% 10 Hello <em>World</em> Leaders Hello <em…
%htitle% 10 Hello <em>World</em> Leaders Hello <em…
%ftitle% 10 Hello <em>World</em> Leaders Hello World Leaders
%fhtitle% 10 Hello <em>World</em> Leaders Hello <em>World</em> Leaders
%title% Disabled Hello <em>World</em> Leaders Hello World Leaders
%htitle% Disabled Hello <em>World</em> Leaders Hello <em>World</em> Leaders

%title% and %htitle%

Notice that the resulting strings for the standard %title% tag and the %ftitle% tag do not contain HTML tags. Thus, they are safe for use within HTML tag attributes (e.g. the title attribute). To maintain HTML tags present in the resource’s title, use the %htitle% tag.

%ftitle% and %fhtitle%

Note that the Max Title Length setting does not affect the resulting string for the %ftitle% and %fhtitle% template tags. In fact, by design, they are the same as %title% and %htitle% when “Max Title Length” is disabled. However, note that since the Max Title Length setting is deprecated, these template tags are as well.

Lastly, note that when using the Max Title Length setting, HTML tags may be left open or even incomplete. Therefore, it is strongly recommended that CSS is used to trim the breadcrumb title length rather than the deprecated Max Title Length setting. An additional benefit to using CSS is it does not mess with the actual content of the breadcrumb trail, allowing search engines to pick up on the full titles rather than the trimmed ones.

-John Havlik

[end of transmission, stay tuned]


  1. Note that use of the Max title Length setting has been deprecated in favor of using CSS to trim Breadcrumb titles lengths.

Breadcrumb NavXT Menu Magic 1.1.5

Announcing the immediate availability of Breadcrumb NavXT Menu Magic 1.1.5. This version fixes a bug relating to Breadcrumb NavXT Menu Magic’s handling of CPT root pages.

Previously, if a CPT root page was located in a menu, the menu hierarchy would only be followed when on said CPT root page, or if said root page had a parent page that is not the front page. This normally manifested itself when on a single post instance of a CPT, the menu hierarchy containing the CPT root page would not be followed. With version 1.1.5, Breadcrumb NavXT Menu Magic will always follow the menu hierarchy that a CPT root page is in.

Users with valid and activated license keys should receive an update notification within the WordPress dashboard and be able to use the update mechanism to update (just like with any plugin in the WordPress.org repository).

-John Havlik