USB PD is a fun protocol to explore, but it can be a bit complex to fully implement. It makes sense we’re seeing new stacks pop up all the time, and today’s stack is a cool one as far as code reusability goes. [Vitaly] over on Hackaday.io brings us pdsink – a C++ based PD stack with no platform dependencies, and fully-featured sink capabilities.

This stack can do SPR (5/9/15/20V) just like you’d expect, but it also does PPS without breaking a sweat – perfect for your Lithium Ion battery charging or any other current-limited shenanigans. What’s more, it can do EPR (28V and up) – for all your high-power needs. For reference, the SPR/PPS/EPR combination is all you could need from a PD stack intended for fully taking advantage of any USB-PD charger’s capabilities. The stack is currently tailored to the classic FUSB302, but [Vitaly] says it wouldn’t be hard to add support for a PD PHY chip of your choice.

It’s nice to have a choice in how you want your PD interactions to go – we’ve covered a few stacks before, and each of them has strong and weak sides. Now, if you have the CPU bandwidth, you could go seriously low-tech and talk PD with just a few resistors, transistors, and GPIOs! Need to debug a particular USB-C edge case? Don’t forget a logger.

Now, Rock 5 ITX+ is no x86 board, sporting an ARM Rockship RK3588 on its ITX form-factor PCB, but reading this blog post’s headline might as well give you the impression. [Venn] from the [interfacinglinux.com] blog tells us about their journey bringing up UEFI on this board, thanks to the [EDK2-RK3588] project. Why? UEFI is genuinely nice for things like OS switching or system reconfiguration on the fly, and in many aspects, having a system management/configuration interface for your SBC sure beats the “flash microSD card and pray” traditional approach.

In theory, a UEFI binary runs like any other firmware. In theory. For [Venn], the journey wasn’t as smooth, which made it very well worth documenting. There’s maybe not a mountain, but at least a small hill of caveats: having to use a specific HDMI port to see the configuration output, somehow having to flash it onto SPI flash chip specifically (and managing to do that through Gnome file manager of all things), requiring a new enough kernel for GPU hardware acceleration… Yet, it works, it really does.

Worth it? From the looks of it, absolutely. One thing [Venn] points out is, the RK3588 is getting a lot of its features upstreamed, so it’s aiming to become a healthy chip for many a Linux goal. From the blog post comments, we’ve also learned that there’s a RPi UEFI port, even if for a specific CPU revision of the Model 5B, it’s still a nifty thing to know. Want to learn more about UEFI? You can start here or here, and if you want a fun hands-on example, you could very well start by running DOOM.

Connected devices are ubiquitous in our era of wireless chips heavily relying on streaming data to someone else’s servers. This sentence might already start to sound dodgy, and it doesn’t get better when you think about today’s smart glasses, like the ones built by Meta (aka Facebook).

[sh4d0wm45k] doesn’t shy away from fighting fire with fire, and shows you how to build a wireless device detecting Meta’s smart glasses – or any other company’s Bluetooth devices, really, as long as you can match them by the beginning of the Bluetooth MAC address.

[sh4d0wm45k]’s device is a mini light-up sign saying “GLASSHOLE”, that turns bright white as soon as a pair of Meta glasses is detected in the vicinity. Under the hood, a commonly found ESP32 devboard suffices for the task, coupled to two lines of white LEDs on a custom PCB. The code is super simple, sifting through packets flying through the air, and lets you easily contribute with your own OUIs (Organizationally Unique Identifier, first three bytes of a MAC address). It wouldn’t be hard to add such a feature to any device of your own with Arduino code under its hood, or to rewrite it to fit a platform of your choice.

We’ve been talking about smart glasses ever since Google Glass, but recently, with Meta’s offerings, the smart glasses debate has reignited. Due to inherent anti-social aspects of the technology, we can see what’d motivate one to build such a hack. Perhaps, the next thing we’ll see is some sort of spoofed packets shutting off the glasses, making them temporarily inoperable in your presence in a similar way we’ve seen with spamming proximity pairing packets onto iPhones.