linux-devmgmt: the Windows Device Manager rebuilt on Qt6 and sysfs

What linux-devmgmt actually replaces

On Linux, the equivalent of the Windows Device Manager is a scattering of commands: lspci for the PCI bus, lsusb for USB, lsmod for loaded modules, modinfo for driver metadata. None of them present a single two-level tree, and none of them offer a Properties dialog. linux-devmgmt is aimed at the person who knows what Device Manager looks like and wants that shape on Linux without memorising four tools.

The README describes it as "a faithful recreation of the Windows Device Manager built with Qt6 and real hardware backends via sysfs/procfs." The emphasis on real backends matters. The device list is not a static database or a mockup; it is read from the kernel's sysfs and procfs interfaces. The project is written in C++ and licensed GPL-3.0.

It is explicitly built for CachyOS and Arch Linux, and packaged as a Nix flake for NixOS. The README warns that some features depend on dkms and pacman and that other distributions may need minor adjustments. That is a narrower target than most desktop utilities claim.

The device tree, the Properties dialog and the module blacklist

The README lists a full two-level device tree organised by type, backed by sysfs and procfs. Selecting a device opens a Properties dialog with four tabs: General, Driver, Details and Resources. The Driver tab shows the version and date of the driver in use, and the screenshots in the repository include one of the same tab displaying an older, unmaintained driver, so the date is doing real work there. The Details tab is a dropdown paired with a large text area, and the Resources tab reports device resources such as IRQ assignments.

The most interesting design decision is how enable and disable work. According to the README, devices are enabled or disabled via kernel module blacklisting, not by unbinding the device from its driver. That means the action is not a runtime toggle of the current device state; it changes which modules the kernel loads. For a device backed by a loadable module this is a persistent, reboot-scoped change. For hardware whose driver is built into the kernel, blacklisting has nothing to act on.

Other actions in the same list include uninstalling DKMS drivers, an Update Driver wizard, a Driver Details viewer that shows modinfo output, and a Scan for hardware changes command. Battery levels are read for AirPods, per pod and per case, and the README notes they are read on request rather than polled continuously.

Installing from the AUR and first launch

The README gives an AUR package for Arch and CachyOS. This is the shortest path, and it pulls in the Qt6 runtime for you.

 yay -S linux-devmgmt

After installation, the binary is named devmgmt. Launching it opens the two-level tree, with categories such as the device classes reported by the kernel.

If you prefer a pre-built binary, the README points at the Releases page and gives these two commands. The example filename is the x86_64 build.

chmod +x devmgmt-x86_64
sudo mv devmgmt-x86_64 /usr/local/bin/devmgmt

Building from source on Arch or CachyOS takes two packages and three commands, per the README.

sudo pacman -S qt6-base cmake
cmake -B build
cmake --build build -j
./build/devmgmt

On NixOS the flake covers the build and the runtime dependencies. The README gives both a build and a direct run.

nix build
./result/bin/devmgmt

# or run directly
nix run

A dev shell with Qt Creator and GDB is also documented, via nix develop. Before relying on the privileged actions, check that pkexec, modinfo and bluetoothctl are installed; the README lists them as runtime dependencies that Arch users install separately.

Where the Arch and CachyOS assumption bites

The runtime dependency table is the clearest limitation. Privilege escalation for enable, disable and uninstall goes through pkexec. Driver details come from modinfo. Bluetooth device disconnect goes through bluetoothctl. DKMS driver management needs dkms, and the package date lookup needs pacman. The first three are broadly available, but the last two are the ones that make this an Arch-family tool. On a distribution without pacman, the driver date lookup has nothing to query. The README says other distributions may need minor adjustments rather than claiming they work.

The blacklisting approach to enable/disable is the second constraint. A user who expects the Windows behaviour of toggling a device off and immediately seeing it disappear from the tree may be surprised, because the mechanism operates on module loading rather than on the live device. Nothing in the README documents a rollback path for a blacklist entry, and the README does not document what happens to a blacklisted module on the next boot beyond the change taking effect. That is a gap worth knowing about before you disable something you need to reach the network.

The AirPods battery feature is narrow by design. It is per pod and per case, read on request, and it is not a general battery monitor for Bluetooth peripherals.

Against lspci, lsusb and a terminal

The honest alternative is not another GUI. It is the command line you already have. lspci enumerates the PCI bus, lsusb enumerates USB, lsmod lists loaded modules and modinfo prints driver metadata. Together they cover most of what the Properties dialog shows, and they pipe into scripts, which linux-devmgmt does not.

The difference in approach is structural. The command-line tools each report one bus and print text. linux-devmgmt merges the buses into one type-organised tree, attaches a tabbed dialog to each node, and adds actions that the command-line tools do not perform: blacklisting a module through pkexec, uninstalling a DKMS driver, and running an Update Driver wizard. If your task is to inspect one GPU's driver version, modinfo is faster and needs no GUI. If your task is to browse the whole machine and act on a device, the tree is the point.

There is also a cosmetic layer. The README says the app is best enjoyed with AeroThemePlasma but looks great on regular KDE as well, and the repository ships a .desktop file so it appears in the application menu like any other KDE program.

Maintenance, licensing and what upgrading costs you

The repository is not archived. The most recent release listed is v2.1.1 from 2026-08-01, following v2.1 on 2026-07-31 and v2.0.4.1 on 2026-06-06, and the last push to the default branch was on 2026-08-19. That is roughly a month before today, so the project is being worked on, though the release cadence across those three versions shows two of them landing one day apart, which suggests v2.1.1 was a quick follow-up rather than a scheduled release.

Upgrade cost depends on how you installed it. The AUR package and the Nix flake both track the project, so an upgrade is a package manager operation. The pre-built binary path is manual: you download a new file and move it into place yourself, and nothing in the README describes an in-app updater. The README does not describe a migration step for the blacklist entries the app creates, so if you have disabled devices through it, check those entries after a major version bump.

The licence is GPL-3.0. If you redistribute the binary or a modified build, the GPL's source and licence obligations apply. That is a statement about the licence text, not legal advice; read the LICENSE file in the repository for the terms.

Editorial conclusion

Adopt linux-devmgmt if you run Arch, CachyOS or NixOS and you want a graphical, Windows-shaped view of your device tree with enable/disable and DKMS uninstall actions. Skip it if you are on Debian, Fedora or another distro without pacman, or if you need scriptable device management rather than a GUI. Before installing, confirm that pkexec, modinfo and bluetoothctl are present, since the README lists them as separately installed runtime dependencies.

Frequently asked questions

Official sources

1. actuallyaridan/linux-devmgmt on GitHub
2. Issues
3. License: GPL-3.0
4. README
5. Releases