When Standard Is Not a Standard

Having a standard is a beautiful thing. While US sockets are really shitty in general, I love how standardized they are. Every single apartment I ever lived in had the same double outlet setup. Its welcoming smiley face just awaits a device to power.

Except that this is not the standard orientation.

The standard orientation is actually upside-down of what everybody is used to. Well, when I say “the standard”, I say this loosely since it’s not part of NEC (National Electrical Code) as such. But, if you go to any hospital or industrial setting, chances are that you will find it in the “correct” orientation.

If you want to hear more then you ever cared about this, you can watch Technology Connections dealing with this exact topic. In any case, I am not watching that video ever again as it made me cry for Schuko.

In any case, I was mounting some stuff on the DIN rail and I had a choice to make. The way I planned to route wires and the text on the socket itself were both pointing toward “the standard” orientation. So I ran with it.

Do you see the problem here?

While orientation of the socket itself is not really defined, position of live and neutral wires is. In “the standard” orientation, the hot goes on the left and the neutral wire goes on the right. But here, my second socket actually has the neutral on the left. And yes, I did check that screw feeds into the socket straight up.

Since the other way of finding the neutral - its longer slot - points toward the neutral on the right, it’s obvious that markings are in fact incorrect. Manufacturer, instead of fixing the mold, just decided to sell devices nonetheless. I mean, US outlet is as shitty as it gets so it’s not like swapping the live and the neutral wire will make it any worse.

And, in reality, there is no real issue if you swap these wires at the outlet side. Heck, my belowed Schuko goes either way and even burned one is way safer than any US outlet. Outside of a few contrived examples involving houses with ancient wiring without ground, or really specific dumb equipment, which wire is live and which one is neutral doesn’t really matter.

But I find it amusing that product having such a strong opinion about the ground pin position can be so nonchalant when it comes to position of its current carrying wires.

PS: And yes, if I didn’t have two of them side by side, I would have probably missed wire labeling issue.

Updating Framework's QMK Firmware

New BIOS for Framework 16, brought also a problem. Every boot I got a message that my keyboard firmware is outdated. It was true, but also annoying warning as it paused the boot process. Normal person would just update keyboard but I had a few customizations and thus could not do the same.

What customizations? Well…

• Entering QMK firmware by holding CapsLock (keyboard) or NumLock (numpad)
• Key to mute microphone
• Disabling airplane mode key
• Reconfiguring numpad to allow volume and media controls
• Using brightness as a NumLock signal
• Simplifying background light setup

Could I live without those? Yes, but I still would prefer not to. So, I had to redo my changes on top of v0.3.1 which was simple enough as I just pretty much cherry-picked my changes directly. Maybe for the next version I also squash a few of them but I was lazy this time.

Short flash later and my numpad had a newer firmware with the same behavior. Happily I proceeded to flash the keyboard but in my excitement, I forgot to change my command line from framework/numpad to framework/ansi. Thus, I flashed my numpad firmware onto my keyboard. Annoying mistake but easily corrected by just reflashing the correct firmware on top of it. Or so I though.

My keyboard still didn’t work even after the correct firmware has been flashed. Some keys did produce something but it was never a correct letter. Did I brick my keyboard? Well, fortunately for me, with QMK answer is never yes.

QMK flashing doesn’t erase the full EEPROM when new version is loaded. So, if you end up corrupting the whole thing by flashing something very incompatible, you cannot just flash new firmware and be ok. What you need is to erase the old firmware all together. There are a few tools to do it, but I like this one.

Once EEPROM was erased, flashing my keyboard firmware worked like a charm.

Using ZFS in Docker

I have most of workloads on my server setup in Docker. It makes for self-documenting configuration, easier move to other machine, and less dependencies on the underlying OS. But one workload I kept on server itself - reporting.

The way my scripts were written, they required proper ZFS access. Now, I could adjust script to loopback via SSH to OS itself, but there was an easier way.

Docker allows for device exposing, and in the case of ZFS, all you need is to point container toward /dev/zfs:

    devices:
      - /dev/zfs:/dev/zfs

Now your scripts in container will have proper ZFS access.

Forcing a reboot

After messing with my remote server, there came a time for a reboot. Simple enough - but this time it ended in error.

Call to Reboot failed: Connection timed out

I’ve been using Linux servers for decades now and I was never faced with this issue. Fortunately, somebody at Unix StackExchange did.

Solution was to manually enter a few letters into /proc/sysrq-trigger, one letter at a time.

echo s > /proc/sysrq-trigger ; echo u > /proc/sysrq-trigger ; echo b > /proc/sysrq-trigger

This (attempts to) execute three distinct commands:

• s: syncs all file systems
• u: makes all file systems read-only
• b: reboots the system in agressive manner.

If you are curious about what other things you can do, kernel.org has a nice documentation page.

Reconnecting HDMI

Switching my media PC from Windows to Bazzite went awfully uneventful. No issues whatsoever. At least for a while.

My media computer is connected to TV courtesy of type-C HDMI output. And I verified heck out of it. Computer’s output worked flawlessly with TV.

However, once TV was off for a while, turning on TV would result in “No Signal” message. At first I though it was sleep, but no. Computer was still reachable via network and it would all start working after reboot. A lot of troubleshooting later and I found a pattern, courtesy of DP status:

cat /sys/class/drm/card1-DP-2/status

If I run it while TV was on, I would see connected status. If I turn TV off, I would still see connected status. But, once I turned TV back on (after some time has passed), status would change to disconnected. And nothing I’ve tried to do over network helped. Well, nothing but one thing.

If you ever used Ctrl+Alt+Fx keys, you saw virtual terminals in action. Most of the time we only do stuff on the first terminal, but other terminals are sometime handy too. Switching to other terminal would actually reset connection every time. And that is something you can do from the command line.

chvt 2
sleep 1
chvt 1

Figuring it out was the first part. While I now knew how to recover connection to my TV, having to do it every time via network was annoying. I wanted something automatic.

The first step was creating script in /usr/local/bin/dp-reconnect:

#!/bin/bash

function status() {
    for DP_PATH in /sys/class/drm/card1-DP-*; do
        DP_STATUS=$( cat "$DP_PATH/status" | grep '^connected$' | xargs )
        if [[ "$DP_STATUS" == "connected" ]]; then
            echo "Display $( basename "$DP_PATH" ) connected"
            exit 0
        fi
    done
}

status
echo "No connected displays"

chvt 2
sleep 1
chvt 1

status
exit 1

Next step is to create service definition at /etc/systemd/system/dp-reconnect.service:

[Unit]
Description=Switch terminal if no DP is connected

[Service]
Type=oneshot
ExecStart=/usr/local/bin/dp-reconnect

And lastly, we can create timer in /etc/systemd/system/dp-reconnect.timer:

[Unit]
Description=Switch terminal if no DP is connected

[Timer]
OnCalendar=*-*-* *:*:00
Persistent=true
AccuracySec=1s

[Install]
WantedBy=timers.target

With all files in place, the only remaining task is to enable the timer.

sudo systemctl enable --now dp-reconnect.timer

With all in place, if display gets disconnected, script will reconnect it within a minute. Not perfect but lightweight enough not to be a serious hassle.