Monthly Archives: November 2025

Browse and run your Sway keybindings with Rofi

Remembering every Sway shortcut is tough. I wrote a small script that parses your Sway config, displays all bindsym shortcuts in a clean, searchable list via Rofi, and executes the command associated with whichever one you select.

It’s fast, keyboard-friendly, and great for discovery: “What did I bind to Mod + Shift + P again?” Now you can search, see, and execute it.

What the script does

  • Reads your Sway config from $XDG_CONFIG_HOME/sway/config (or ~/.config/sway/config)
  • Finds all bindsym … lines
  • Formats each entry nicely, e.g.

Mod + Return → exec alacritty

  • Shows the list in a wide Rofi dmenu
  • When you select an entry, it executes the associated command through swaymsg

Dependencies

  • sway (for swaymsg)
  • rofi
  • awk, sed, grep (standard on most distros)
  • notify-send (optional – shows an error if the config isn’t found)

The script

Save this as ~/.local/bin/rofi-sway-keybindings.sh and make it executable.

How it works

The core of the script is a small text-processing pipeline that reads the config and renders a nice two-column list for Rofi:

  1. grep -E '^\s*bindsym' finds all bindsym lines (ignoring leading whitespace)
  2. grep -v '^[[:space:]]*#' ignores full-line comments
  3. sed 's/^\s*bindsym\s*//' strips the leading bindsym
  4. awk splits the line into (and does some cleanup):

keys: the first token (e.g. $mod+Return)
cmd: the rest of the line (e.g. exec alacritty)

It also strips trailing inline comments (after #) and skips bindsym flags like --release or --locked before reading the key. Finally, it prettifies modifiers and prints a fixed-width column so the arrows line up.

Rofi presents that list with -dmenu. When you pick one, the script extracts the command part (after ) and sends it to swaymsg. That means anything you can put after bindsym (like exec …, workspace …, kill, etc.) will run on demand.

Usage

  • Run the script from a terminal: rofi-sway-keybindings.sh
  • Or bind it to a key in your Sway config, e.g.:

Tip: the window is set to 60% width for readability; tweak it via -theme-str if you prefer.

Nice touches in the UI

  • Replaces $mod with Mod
  • Shows Shift as and Control as Ctrl
  • Adds spacing around + so chords read clearly: Mod + ⇧ + q
  • Aligns the left column to 35 characters for a tidy two-column look

Why this is handy

  • Onboarding: perfect for new setups or when you come back after a while
  • Discovery: search by key or by command to find what you already have
  • Launcher: use it as a programmable “cheat sheet” that also runs things

Here are some screenshots (including filtering):

Modern Java in LaTeX listings (Java 17)

If you use the LaTeX listings package to typeset Java, you’ve probably noticed that modern Java has moved faster than the package itself. Records, var, and text blocks may not highlight correctly out of the box. The good news: the listings package is extensible so that you can teach it “modern Java” with a tiny language definition.

The minimal language extension for Java 17

Here’s a drop‑in snippet that builds on the stock Java lexer to support key Java 17 features:

What each line does:

  • language = Java: inherit all of the listings’ built‑in Java rules.
  • morekeywords = {var,record}: colorize var and record as keywords (var is contextual, but highlighting it improves readability in code listings).
  • deletekeywords = {label}: avoid mistakenly highlighting labeled statements like label: for (…) { … }. label is not a Java keyword; removing it prevents false positives.
  • morestring=[b]”””: treat triple quotes as a balanced string delimiter so Java text blocks highlight as a single string.

Using it in your document

Activate the language globally:

…or per listing:

If you already have a custom style (e.g., mystyle) with colors and fonts, combine them:

Minimal working example

This is a compact MWE you can compile with pdflatex, xelatex, or lualatex. Adjust the style to your taste:

Here’s the result, where you can see the differences (note in the standard behavior the wrong highlighting of the double-quoted string in the text-block):

Happy highlighting! 🙂

Getting Your MacBook Air Webcam Working on Linux

If you’ve installed Linux on your MacBook Air, you’ve probably discovered that while most hardware works out of the box, the built-in FaceTime HD camera is notably absent from your video applications. Don’t worry—you’re not alone, and there’s a solution that doesn’t involve external USB webcams or complicated workarounds.

The issue stems from Apple’s use of Broadcom’s proprietary FaceTime HD camera hardware. Unlike most standard USB webcams that work with Linux’s UVC (USB Video Class) drivers, the MacBook Air’s camera uses a PCIe interface with the Broadcom 1570 chipset, which requires specialized drivers that aren’t included in the Linux kernel.

Identifying Your Hardware

Before diving into the solution, let’s confirm you have the same hardware. Open a terminal and run:

If you see output similar to this, you’re dealing with the same Broadcom camera:

The key identifier here is [14e4:1570]—this tells us we have the Broadcom 1570 chipset that needs the reverse-engineered driver.

The Solution: Community-Developed Drivers

Thanks to the hard work of the Linux community, reverse-engineered drivers are available through the Arch User Repository (AUR). These drivers have been developed by analyzing the hardware behavior and creating open-source alternatives to Apple’s proprietary drivers.

If you’re using an Arch-based distribution (like EndeavourOS, Manjaro, or plain Arch), you can search for the available packages:

This will show you several packages:

  • facetimehd-dkms: The main reverse-engineered driver
  • facetimehd-firmware: Required firmware files extracted from macOS
  • facetimehd-data: Sensor calibration data for optimal performance
  • facetimehd-dkms-git: Development version of the driver

The installation is straightforward. Install the main driver package:

The package manager will automatically pull in the required dependencies, including the firmware and calibration data packages.

After installation, you must reboot your system. This isn’t just a suggestion—the kernel module needs to be loaded fresh, and the hardware needs to be properly initialized during the boot process.

Once your system boots back up, your webcam should be functional. However, there’s an important caveat to be aware of.

While the driver successfully enables the webcam, there are some compatibility quirks:

  • Google Chrome/Chromium: Works perfectly
  • Firefox: May not detect the camera
  • Native Linux applications (like Kamoso): May have issues

This inconsistency likely stems from the different ways in which various applications interact with the video4linux (V4L2) subsystem and handle the specific quirks of this reverse-engineered driver.

Maintaining KDE dotfiles with Chezmoi Modify Manager

I have already blogged about managing KDE dotfiles with chezmoi and chezmoi_modify_manager. But what about maintaining them?

For example, one of the KDE configuration files changes, and you want to update the version managed by chezmoi.

Here’s an example where the Kate configuration file changed on the system and chezmoi detects that:

You can see the change with “chezmoi diff”:

Remember that the part with “+” is the version known by chezmoi, while the one with “-” is the version in the local system.

You now want to update the corresponding file managed by chezmoi.

The command “chezmoi re-add” won’t help because that file is handled by chezmoi_modify_manager, which splits it into two files: “modify_private_katerc” and “private_katerc.src.ini”.
The latter contains only the parts of the file we want to track, and the former is the corresponding modification script.

Moreover, “chezmoi merge” won’t help either for the same reason. Here’s what this command shows (I configured chezmoi to use the GUI program “meld” for such a command):

However, “chezmoi_modify_manager” has an option for such situations. Here’s the option to use with “chezmoi_modify_manager”:

Here’s the command and the output:

By using “chezmoi cd” and “git diff”, we can verify that the corresponding “.src.ini” file has been correctly updated (and the git repository can then be committed and pushed):

In the end, it’s easy, once you know the right option to use with “chezmoi_modify_manager”!

Enjoy your KDE dotfiles! 🙂