I plugged this into a system running Debian testing (trixie) and had no intention of doing any sort of fancy mouse customisations, let alone letting using Razer's own software for anything. Unfortunately for me, it came out of the box with a very bright RGB-illuminated logo on the top that is continuously cycling through colours. I was thinking about just putting a sticker over it when I noticed that there is a very shmick OpenRazer project to facilitate controlling these Razer peripherals on Linux, so I thought I would give that a go. I would tolerate installing a bit of one-off software but I wanted to avoid adding custom apt repos or installing anything wildly unmaintained.

Complete success: my LED is now off.

First install the required Debian packages:

apt install openrazer-meta python3-pip

Then reboot the machine to let the driver take effect.

Install razer-cli, a CLI configuration tool written in Python. It needs to use the system openrazer install so I passed --break-system-packages, but to contain any chaos to my own user I also passed --user. This has the ultimate result that the program works and is installed at ~/.local/bin/razer-cli.

pip3 install razer-cli --user --break-system-packages

Hooray, it works:

$ ./.local/bin/razer-cli -l
Found 1 Razer device(s)
Razer Cobra:
   type: mouse
   DPI: (1800, 1800)
   max DPI: 8500
   DPI stages: (3, [(400, 400), (800, 800), (1600, 1600), (3200, 3200), (6400, 6400)])
   polling rate: 500
   generic zone:
   logo zone:
      brightness: 75.0
      colors: ['00FF00', '00FFFF', '0000FF']
      effect: spectrum
      speed: 1
      wave_dir: 1
      effects available: breath_dual, breath_random, breath_single, brightness, none, reactive, spectrum, static
   serial: PM2443H27003395
   firmware version: v1.0
   driver version: 3.9.0
   supported capabilities: name, type, firmware_version, serial, poll_rate, supported_poll_rates, dpi, dpi_stages, lighting, lighting_logo, lighting_logo_brightness, lighting_logo_spectrum, lighting_logo_static, lighting_logo_none, lighting_logo_reactive, lighting_logo_breath_single, lighting_logo_breath_dual, lighting_logo_breath_random

Now let's set that brightness down to zero.

$ ./.local/bin/razer-cli -b 0
creating path and file
Adding new settings entry

All done. Nice.

Weirder yet, my desktop could ping the laptop but if I tried to connect to the Syncthing port with nc -v $ip 22000 then it would report "no route to host". What? My routes are fine!

As many sysadmins would know, and I had forgotten, you can get this strange-looking error when the connection is being denied by a firewall. This is all well and good, but since when does Debian have a firewall installed by default?

Apparently this is actually due to a "recommends" dependency on firewalld when you choose the "KDE" option in the installer. I don't know but I suspect this is a packaging bug more than an intentional decision. Anyways, uninstalling firewalld got me back in business.

One of the most popular USB audio interfaces for amateur radio is a gizmo called the Digirig. I own two of them. When I plug it in to my Win11 desktop, cpal offers me four choices for consuming the audio input: u8, i16, i32 or f32 sample formats all at 48 kHz and with one channel. This is correct—it's a mono device.

You can imagine my surprise when I plugged exactly the same device into my Win11 laptop and cpal offered me i32 or f32 at 48 kHz with four channels. Suspiciously, this is exactly the same combinations offered by the laptop's built-in microphone. How did it go so wrong? Was it a bug in cpal? (Spoiler: It was not.)

Onboard sound card:
SupportedStreamConfigRange { channels: 4, min_sample_rate: SampleRate(48000), max_sample_rate: SampleRate(48000), buffer_size: Range { min: 0, max: 4294967295 }, sample_format: I32 }
SupportedStreamConfigRange { channels: 4, min_sample_rate: SampleRate(48000), max_sample_rate: SampleRate(48000), buffer_size: Range { min: 0, max: 4294967295 }, sample_format: F32 }

Digirig:
SupportedStreamConfigRange { channels: 4, min_sample_rate: SampleRate(48000), max_sample_rate: SampleRate(48000), buffer_size: Range { min: 0, max: 4294967295 }, sample_format: I32 }
SupportedStreamConfigRange { channels: 4, min_sample_rate: SampleRate(48000), max_sample_rate: SampleRate(48000), buffer_size: Range { min: 0, max: 4294967295 }, sample_format: F32 }

It turns out my Lenovo laptop came with some fancy Dolby drivers which by default would insert themselves to do some sort of signal processing on the input and output of an attached USB audio device. As a result cpal was talking to this virtual audio component which had different expectations of format, instead of directly providing samples for the digirig behind it like I wanted.

Luckily the solution was quite simple. I just had to go through sound settings for both the USB input and output devices and disable audio enhancements.

Now cpal enumerates the configurations for the Digirig how I expected. The lesson is clear—if you're using a Digirig on Windows you will definitely want to make sure this is disabled. Otherwise a driver like this might interfere with your digital radio signals. This is my fault of course. Digirig's getting started guide warns that you need to turn off "custom features" like "spatial audio". I hadn't checked; when I first got the Digirig I was using it with a Linux system and had no such issues.

SupportedStreamConfigRange { channels: 1, min_sample_rate: SampleRate(48000), max_sample_rate: SampleRate(48000), buffer_size: Range { min: 0, max: 4294967295 }, sample_format: U8 }
SupportedStreamConfigRange { channels: 1, min_sample_rate: SampleRate(48000), max_sample_rate: SampleRate(48000), buffer_size: Range { min: 0, max: 4294967295 }, sample_format: I16 }
SupportedStreamConfigRange { channels: 1, min_sample_rate: SampleRate(48000), max_sample_rate: SampleRate(48000), buffer_size: Range { min: 0, max: 4294967295 }, sample_format: I32 }
SupportedStreamConfigRange { channels: 1, min_sample_rate: SampleRate(48000), max_sample_rate: SampleRate(48000), buffer_size: Range { min: 0, max: 4294967295 }, sample_format: F32 }

As far as I can tell reading around online there used to be an explicit "YOLO mode" in the preferences but this seems to have disappeared. There's an auto-approve setting where you can choose which commands (or regexes matching commands) are allowed. Unfortunately, even though /.*/ is documented as "allow every command" this simply doesn't work and one ends up having to click "Approve" a lot.

The good news is that the YOLO setting remains although it's a little hard to find. (A Microsoft employee mentions it in the second issue above.) The trick is that you need to open the remote settings JSON for your codespace—it doesn't work if you set it locally—and enable chat.tools.global.autoApprove.

So if you Command-Shift-P, choose Preferences: Open Remote Settings (JSON).

Then inside the global { ... } JSON object, add:

    "chat.tools.global.autoApprove": true,

Now, the first time GitHub Copilot tries to run a command in a given session you'll get a dialog box asking you to confirm YOLO mode. You say yes, and then it will blissfully go ahead and run all the commands it wants to. Magnificent.

I found the solution by accident: install a proper font for Chinese characters. Although these texts were English they had Hanzi sprinkled liberally throughout. In some parts of the UI they were rendered extremely poorly and in other parts they were missing entirely. I'm not exactly sure why this hits the CPU so hard. I guess it was doing some sort of search to figure out what to display instead? So I ran:

sudo zypper in google-noto-sans-cjk-fonts

...and now I not only have all the characters, but everything is nice and fast. Aren't computers grand?