Update (1 September 2026): The original fix below covered cold boot, but the same bug can also show up after waking from suspend (e.g. running in clamshell mode with an external keyboard). Added a second hook for that case, plus a more robust way to target the device that survives USB re-enumeration — see “The same bug also hits after suspend/resume” further down.

If you’re running a Razer BlackWidow V4 on Ubuntu (or any Linux distro) with OpenRazer and Polychromatic, and the keyboard’s RGB lighting simply refuses to turn on after boot — even though everything looks configured correctly — you’re not alone. This is a well-documented issue with this specific keyboard, and after a fairly deep troubleshooting session, I found a reliable, permanent fix. Here’s the full story, including the dead ends, so you can skip straight to what works.

The symptom

• Polychromatic (the GUI for OpenRazer) shows the keyboard, with a static effect and a color set, brightness at 40%.
• The keyboard is completely dark.
• No errors anywhere — not in the GUI, not in the OpenRazer daemon logs.

What turned out to be fine (so you can skip these)

Working through this methodically, the following were all ruled out one by one:

1. Kernel driver not loaded. lsmod | grep razer showed razerkbd loaded correctly.
2. Missing permissions. The user was already in the plugdev group, which OpenRazer requires for device access.
3. USB detection. lsusb | grep -i razer showed the keyboard correctly enumerated (1532:0287 Razer USA, Ltd Razer BlackWidow V4).
4. Daemon not running. ps aux | grep openrazer confirmed the daemon was active.
5. Daemon errors on restart. Manually restarting the daemon in the foreground (openrazer-daemon -F) showed a completely clean log — the device was found, initialized, and set to “driver” mode without a single error.
6. CLI commands failing silently. Using polychromatic-cli to directly set brightness and effects executed without errors, but still no light.

Everything on the software/permissions/detection side was working. And yet: still dark.

The actual cause

This turned out to match a known OpenRazer bug (see openrazer/openrazer#2291): the BlackWidow V4 doesn’t reliably “wake up” its lighting on a cold boot or fresh login, even though the daemon and driver both report success. The fix that does work, reported by multiple users, is unplugging the USB cable and plugging it back in — at which point the keyboard immediately lights up with the last-set effect.

Physically unplugging and replugging works, but it’s not something you want to do every time you boot your laptop.

First (failed) attempt: unbind/bind via sysfs

My first idea was to emulate a “software unplug” using the kernel’s USB driver unbind/bind mechanism:

bash echo "5-1.3.3" > /sys/bus/usb/drivers/usb/unbind sleep 2 echo "5-1.3.3" > /sys/bus/usb/drivers/usb/bind

This detaches and reattaches the kernel driver from the USB device. It ran without errors — but the keyboard stayed dark. The reason: unbind/bind only affects the driver association in the kernel. It does not cut power to the physical USB port. The BlackWidow V4’s onboard firmware apparently needs an actual power interruption (like a real unplug) to reload its stored lighting profile — a driver-level detach isn’t enough to trigger that.

The actual working fix: uhubctl

The tool that solves this properly is uhubctl, which can toggle power on individual USB hub ports — a true, real power cycle, done entirely in software (provided your hub/port supports per-port power switching, which is common on USB-C docks and many external hubs).

Step 1 — Install uhubctl

bash sudo apt install uhubctl

Step 2 — Find your keyboard’s hub and port

bash sudo uhubctl

This lists every USB hub and its ports. Look for your keyboard’s vendor/product ID (1532:0287 for the BlackWidow V4) in the output, e.g.:

Current status for hub 5-1.3 [03f0:086b Microchip Tech USB2734, USB 2.10, 4 ports, ppps] Port 3: 0503 power highspeed enable connect [1532:0287 Razer Razer BlackWidow V4]

The ppps flag in the hub’s description confirms it supports per-port power switching — without this, the rest of the fix won’t work on that particular hub.

Note the hub location (5-1.3 in this example) and port number (3).

Step 3 — Test a manual power cycle

bash sudo uhubctl -l 5-1.3 -p 3 -a cycle

Watch the keyboard: it should go completely dark for a moment (this is a real power cut, so key input briefly stops working too) and then light back up automatically with the last-configured effect.

Step 4 — Automate it with a script (don’t hardcode the port!)

My first version of this script hardcoded the hub location and port number from Step 2 (-l 5-1.3 -p 3). That worked — for a while. A few days later the same fix silently stopped working, and digging into the logs showed why:

razer-usb-reset.sh: No compatible devices detected at location 5-1.3!

The USB bus/port numbering isn’t guaranteed to stay the same across reboots — it can shift depending on enumeration order, especially behind a dock. So instead of a fixed location, target the device by its description string, which uhubctl can search for directly with -s:

bash sudo uhubctl -s BlackWidow

This finds the right hub/port regardless of where it currently sits in the USB topology. Use this in the script instead of a hardcoded -l/-p:

bash printf '#!/bin/bash\nsleep 1\nuhubctl -s BlackWidow -a cycle\nsleep 3\n' | sudo tee /usr/local/bin/razer-usb-reset.sh > /dev/null sudo chmod +x /usr/local/bin/razer-usb-reset.sh

(Using printf piped into tee instead of a text editor avoids line-ending corruption that can happen when pasting multi-line scripts into nano over some terminal setups — worth knowing if you’ve ever seen a systemd unit fail with a cryptic “Bad message” or a script fail with exit code 127 for no obvious reason.)

Step 5 — Run it automatically on every boot with systemd

“`bash printf ‘[Unit]\nDescription=Razer BlackWidow V4 USB Reset for Cold-Boot Lighting Bug\nAfter=multi-user.target\n\n[Service]\nType=oneshot\nExecStartPre=/bin/sleep 8\nExecStart=/usr/local/bin/razer-usb-reset.sh\n\n[Install]\nWantedBy=multi-user.target\n’ | sudo tee /etc/systemd/system/razer-lighting-fix.service > /dev/null

sudo systemctl daemon-reload sudo systemctl enable razer-lighting-fix.service sudo systemctl start razer-lighting-fix.service “`

The ExecStartPre=/bin/sleep 8 gives the system a few seconds to finish bringing up USB and the OpenRazer daemon before the power cycle happens — without it, the reset might fire before the daemon is even watching the device.

Step 6 — Reboot and verify

Restart the laptop. A few seconds after login, the keyboard should briefly go dark and then light up on its own — no cable required.

The same bug also hits after suspend/resume

Booting isn’t the only time this bug shows up. If you run your laptop in clamshell mode (lid closed, external keyboard/monitor via a dock) and it goes to sleep, the BlackWidow V4 can come back dark after resume too — same root cause, different trigger. The boot-time systemd service above only runs at boot, so it won’t cover this case. You need a second hook that fires on resume.

Linux has a dedicated mechanism for exactly this: any executable script placed in /usr/lib/systemd/system-sleep/ gets automatically run by systemd-sleep, once before suspend and once after resume, with $1 set to pre or post.

Add a resume hook

bash printf '#!/bin/bash\ncase "$1" in\n post)\n sleep 3\n /usr/local/bin/razer-usb-reset.sh\n ;;\nesac\n' | sudo tee /usr/lib/systemd/system-sleep/razer-usb-reset > /dev/null sudo chmod +x /usr/lib/systemd/system-sleep/razer-usb-reset

This reuses the same razer-usb-reset.sh from Step 4, only running it on the post (i.e. after-resume) phase, with a short delay to give USB a moment to come back up.

Verifying it actually fires

Note: when you go looking for this in the logs, search for systemd-sleep, not system-sleep — the directory has a hyphen in “system-sleep”, but the actual process name that shows up in the journal is systemd-sleep (with a “d”). Searching for the wrong string will make it look like the hook never ran, when it actually did:

bash journalctl -b | grep -i "systemd-sleep\|razer-usb-reset\|uhubctl"

You should see the hook’s uhubctl output sitting right between the “sleep operation” and “System returned from sleep operation” log lines for each suspend/resume cycle.

Summary

Attempt	Result
Check driver, permissions, USB detection, daemon status	All fine — not the cause
Restart OpenRazer daemon	Clean logs, still dark
polychromatic-cli direct commands	No errors, still dark
Physical unplug/replug	Works
USB driver unbind/bind (software)	Runs clean, but no effect — doesn’t cut power
uhubctl port power cycle, hardcoded location	Works until the USB topology shifts, then breaks silently
uhubctl port power cycle, matched by description (-s)	Works reliably, survives reboots and re-enumeration
Boot-time systemd service only	Fixes cold boot, doesn’t cover suspend/resume
Boot service + /usr/lib/systemd/system-sleep/ hook	Fully covers boot and resume

If your BlackWidow V4 (or possibly other Razer devices with the same firmware quirk) won’t light up on Ubuntu — whether after boot or after waking from suspend — check whether your USB hub supports per-port power switching with sudo uhubctl, and if it does, the two hooks above will fix it permanently: no more unplugging cables, ever.

---

Tested on Ubuntu 24.04 with OpenRazer 3.12.4 and Polychromatic, Razer BlackWidow V4 connected via an HP USB-C Dock G5.

Updated 1 September 2026: added coverage for the suspend/resume case and switched to matching the device by description instead of a hardcoded USB port.