HDMI Firewall

This page summarizes the projects mentioned and recommended in the original post on news.ycombinator.com

Our great sponsors
  • InfluxDB - Power Real-Time Data Analytics at Scale
  • WorkOS - The modern identity platform for B2B SaaS
  • SaaSHub - Software Alternatives and Reviews
  • Lunar

    Intelligent adaptive brightness for your external monitors

    HDMI offers so many protocols I didn’t know of.

    Before finding a way to use DDC on Apple Silicon [1] for Lunar (https://lunar.fyi), I contemplated creating a universal DDC/CI device that can change brightness, contrast, volume, input and colors of a monitor, by either receiving commands through HTTP, or acting as an Adaptive Brightness standalone device.

    In my mind, it would have been an HDMI dongle with an ESP32 that gets power through the 5V line of the HDMI port, and which has an ambient light sensor to adapt brightness by itself.

    In the end, I found the I2C APIs on M1 so this was not so sorely needed anymore, but given the limitations of the M1 Display Coprocessor, I still think it might be a good idea. I just have no idea where would I start with hardware distribution and mass production, this domain seems so intangible from the software development side.

    [1] https://alinpanaitiu.com/blog/journey-to-ddc-on-m1-macs/

  • twinkle-tray

    Easily manage the brightness of your monitors in Windows from the system tray

    Well, unfortunately that will never happen because the app would need a full rewrite using DirectX and WinAPI.

    Fortunately there’s an open source alternative called TwinkleTray: https://github.com/xanderfrangos/twinkle-tray

    Someone determined enough could add adaptive brightness to it. You can even use Lunar’s wireless ambient light sensor [1] for that as it’s simply sending lux values through Server Sent Events [2]

    [1] https://lunar.fyi/sensor

    [2] https://github.com/alin23/lunarsensor

  • InfluxDB

    Power Real-Time Data Analytics at Scale. Get real-time insights from all types of time series data with InfluxDB. Ingest, query, and analyze billions of data points in real-time with unbounded cardinality.

  • lunarsensor

    Server that mimics a Lunar ambient light sensor, with support for multiple lux data sources

    Well, unfortunately that will never happen because the app would need a full rewrite using DirectX and WinAPI.

    Fortunately there’s an open source alternative called TwinkleTray: https://github.com/xanderfrangos/twinkle-tray

    Someone determined enough could add adaptive brightness to it. You can even use Lunar’s wireless ambient light sensor [1] for that as it’s simply sending lux values through Server Sent Events [2]

    [1] https://lunar.fyi/sensor

    [2] https://github.com/alin23/lunarsensor

  • ddcutil

    Control monitor settings using DDC/CI and USB

    ddcutil is the standard utility on Linux for that. It is just command line but it’s highly compatible and very easy to use: https://www.ddcutil.com/

    I even use it for the network-based DDC in Lunar through a Raspberry Pi when wire-DDC from the Mac is not available: https://alinpanaitiu.com/blog/journey-to-ddc-on-m1-macs/#the...

  • ddcctl

    DDC monitor controls (brightness) for Mac OSX command line

    No worries! The same sentiment is what keeps me enthusiastic about programming day after day :)

    So computer monitors have support for a communication protocol called Display Data Channel which is normally used by the host (Mac, PC) to get info about supported resolutions, frame rates, signal timing etc.

    On top of that, a command interface has been created called MCCS or Monitor Control Command Set [1] which allows changing brightness, volume, input and a ton of other aspects of the monitor, by sending specific bytes through the cable. That cable can be HDMI, DisplayPort, Thunderbolt, VGA, DVI. It doesn’t matter, as long as it has dedicated wires to carry the I2C signal.

    I2C is the 2-wire communication protocol used by DDC, and it basically defines things like “a pulse of 5V (volts) of x milliseconds followed by 0V of y milliseconds means the 0 bit. The 1 bit is represented by a pulse of 5V of 2x milliseconds”. It’s a bit more complex than that, also defining TCP-like features with data frames and ACK packets, but you get the idea. It’s something that both devices agree on so that they can send raw bytes using 5 volt pulses.

    I’ve created Lunar as an adaptive brightness app for macOS after finding out about a little CLI called ddcctl: https://github.com/kfix/ddcctl

    That’s where I learned how DDC packets look like, where to place the payload (brightness value between 0 and 100, input ID, etc) and how to write that to the monitor using the macOS I2C APIs.

    When Apple Silicon came out, none of that was possible anymore so I had to go looking around kernel assembly and private macOS frameworks for “the Apple Silicon way” of writing data through I2C.

    If you’re also curious how I learned that, it’s a very cool domain called “reverse engineering” and I learned it while working as a Malware Researcher at Bitdefender. A bit hard to get started, but so many gems to discover once you know how to open binaries in IDA/Hopper and look around their disassembled code.

    [1] https://milek7.pl/ddcbacklight/mccs.pdf

  • mqtt_usb_switch

    Firmware for adding an ESP32 to a Plugable 3.0 USB Switch to add MQTT Functionality

    I have a repo for the switch firmware, which has some pics and other details. Keep in mind though that was pretty quick and dirty, and I think there is a fix for the secondary switch that I still need to push. I should hopefully have some free time to get back to it soon though.

    The HDMI dongle repo is still private, and I really want to do some cleanup before making it public. But, as for parts, I just used a breakout off amazon, and some cheap perfboard to make a hat containing the ESP32.

    USB Switch Repo: https://github.com/byt3swap/mqtt_usb_switch

  • gr-tempest

    An implementation of TEMPEST en GNU Radio

    Its worth noting that prior to the growth of cable/satellite TV channels and the introduction of Digital TV broadcasting... the "TV Detector" was actually a real workable process. Regardless of how often their enforcement actually used them or how diligently they used them (and thus false positives). The fact the "evidence" from the vans was never used in court does not mean they could not or did not work.

    "TV Detection" was actually just a civilian use of Radiation Intelligence, the kind of RF emanation that the USA has the entire TEMPEST hardening requirements https://en.wikipedia.org/wiki/Tempest_(codename) in order to prevent nation state attackers from being able to snoop data from their electronic equipment. This is a very real security principle and plenty of demonstrations out there to show how much information can be leaked from unshielded systems. You can check out gr-tempest which uses modern software defined radio hardware https://github.com/git-artes/gr-tempest. You can see pretty good demo of it here https://old.reddit.com/r/RTLSDR/comments/q59ofn/i_was_finall...

    The basic truth is that over time it got harder and harder to build "simple" detectors to work out if people were using their TVs to watch the BBC (and this is the tricky part, a valid argument is "I don't watch the BBC", so they need to detect BBC channels being displayed on the TV and not detect other channels) and so it gradually became a less and less directly useful tool for the license enforcement teams to use, so it has sort of transformed from a genuine relatively accurate tool, into a sort of mythical boogeyman that gets used to scare people into paying for the license. The wikipedia article is actually pretty good for explaining how the older detection mechanisms worked https://en.wikipedia.org/wiki/TV_detector_van#Detection_tech...

  • WorkOS

    The modern identity platform for B2B SaaS. The APIs are flexible and easy-to-use, supporting authentication, user identity, and complex enterprise features like SSO and SCIM provisioning.

  • Rectangle

    Move and resize windows on macOS with keyboard shortcuts and snap areas

    > MonitorControl for M1 wouldn’t have been possible if I hadn’t open sourced Lunar’s code and my reasearch on that.

    Thank you for your open source contributions.

    > I can’t have it fully open source and still earn money from it.

    I understand. No one asked you to make it 100% open source, but it would be great if the open source parts of the app are decoupled and can be independently built.

    Actually, I knew several partially open source apps, similar to Lunar. For example, Rectangle [1] has both an open source version and a pro (paid) version. However, unlike Lunar, the open source code of Rectangle is buildable. In fact, Lunar might be the first partially open source app I know that is not buildable.

    [1]: https://github.com/rxhanson/Rectangle

NOTE: The number of mentions on this list indicates mentions on common posts plus user suggested alternatives. Hence, a higher number means a more popular project.

Suggest a related project

Related posts