torvalds/ScrollWheel: an RP2350 magnetic encoder knob you have to rewire yourself

What the RP2350 scroll wheel project actually provides

This is a firmware sketch, not a peripheral. It reads an AS5600 magnetic angle sensor over I2C, watches one to four GPIOs wired to switches whose other leg goes to ground, and emits HID reports over USB. Two build modes are defined in the Makefile: SCROLLWHEEL and VOLUME. The README frames the whole thing as a way to "make random hardware knobs", and suggests taking it as a base and doing something else.

The audience is narrow by design. You need an RP2350 board, an AS5600 breakout, and a Qwiic or equivalent I2C connection. The README names the Pimoroni Tiny 2350 as a typical host because it carries a Qwiic connector. Nothing here targets a consumer mouse, and the related search traffic around mouse scroll wheel replacement, settings and parts describes a different problem: this project does not repair or emulate a mouse wheel, it builds a standalone USB knob.

AS5600 over I2C, PIO for the LED, TinyUSB for HID

The data path is short. The AS5600 reports absolute magnetic angle over I2C. Rotation is turned into scroll or volume deltas. Switch GPIOs supply the button events, and debounce.pio handles the contact bounce in a PIO state machine rather than in software polling. hid-device.c and hid-device.h hold the USB HID side, built on the bundled TinyUSB submodule. A second PIO program, ws2812.pio, drives a WS2812 addressable RGB LED.

The repository layout confirms all of this: blink.c, debounce.pio, hid-device.c, hid-device.h, ws2812.pio, an include/ directory, plus pico-sdk and tinyusb as submodules. CMakeLists.txt and a Makefile sit at the top level. Two of those files are the ones you will almost certainly edit: the PIO debounce and the board pin mapping. The README is explicit that the GPIO assignments are "random based on board" and that the included board file is set up for the more normal GPIO4/5 rather than the Pimoroni layout.

The LED choice is the sharpest constraint. The firmware assumes a WS2812 smart LED with a PIO program to feed it. The README notes this is common (the Waveshare RP2350 Zero is given as an example) but "by no means universal". The Pimoroni Tiny has a dumb RGB LED instead, with red, green and blue on GPIO 18, 19 and 20 respectively, normally driven by PWM. A WS2812 PIO program will not light it.

Building torvalds/ScrollWheel and flashing a first knob

The Makefile is the entry point. The prep target initialises the submodules and configures CMake for the RP2350 platform, so run it before anything else. The README gives no other installation route; there is no package, no release binary and no configuration file.

make prep

That runs git submodule update --recursive --init and then cmake -DPICO_PLATFORM=rp2350 -S . -B build. The two submodules, pico-sdk and tinyusb, are pulled in at this step, so expect a slow first run.

Next pick a mode. The Makefile defines scrollwheel and volume, each of which reconfigures the build directory with -DMODE set and then builds the blink target.

make scrollwheel

This is equivalent to cmake -B build -DMODE=SCROLLWHEEL followed by cmake --build build --target blink. The output artifact is build/blink.elf, which is worth noting: the target name does not change with the mode, so the only way to tell which firmware you built is the mode you passed.

Flashing uses picotool, which must already be on your PATH and the board must be in bootloader mode.

make flash

That runs picotool load build/blink.elf && picotool reboot. If the load step fails, the reboot never runs and the board stays in bootloader mode. What you should see after a successful flash is the board enumerating as a USB HID device and reporting rotation and button events to the host.

Where this project will waste your afternoon

The README's own warning is the honest summary: "don't expect to just 'build and use as-is'". Everything board-specific lives in code you have to edit. If your board puts I2C on different pins, or has a single-GPIO LED rather than a WS2812, the firmware will compile and then do nothing useful, or drive the wrong pin.

There is no configuration layer. No Kconfig, no runtime settings, no serial console. Changing the number of switches, the I2C pins or the LED type means editing C and PIO sources and rebuilding. That is a deliberate consequence of the project's size, but it means the cost of the second board is nearly the cost of the first.

Maintenance is the other constraint. The last push to the repository was on 2026-06-02, which is more than three months before today's date, and there are no releases. The README describes the code as one of the author's early RP2350 project trials with minimal updates to bring it up to snuff again. Treat the repository as a snapshot of a working experiment rather than a project with a support commitment. There is also a typo in the README ("rp2354") that nobody has corrected, which tells you how much copy-editing attention the documentation has received.

The wrong tool: if you want a scroll wheel that works on a laptop without a mouse, or you are trying to fix a failing mouse wheel, this is irrelevant. It is a USB HID device you build, not a driver or a repair path.

RP2350 firmware versus QMK and KMK

The obvious comparison is QMK or KMK running on a microcontroller with an encoder. Those projects give you a keymap file, a large library of supported boards, and encoder support that is configured rather than coded. You describe the hardware in a config and flash it.

This project inverts that. There is no keymap abstraction and no board database. You get a small C program with a PIO debouncer, a TinyUSB HID layer and a WS2812 driver, and you change the source to match your wiring. The trade is transparency for convenience: every line that runs is in the repository, and there is nothing to learn about a build system's board definitions. If your goal is a keyboard with a knob, QMK or KMK will get you there faster. If your goal is to understand how an AS5600 and a PIO debouncer fit together on an RP2350, this is a much shorter read.

Licence and the cost of keeping it building

The repository is GPL-2.0. If you distribute a device built from modified sources, the licence obligations attach to that distribution; if you keep the knob on your own desk, they do not. This is a description of the licence identifier in the repository, not legal advice, and the pico-sdk and tinyusb submodules carry their own licences that you should read separately if you plan to ship anything.

Upgrade cost is dominated by the submodules. Because pico-sdk and tinyusb are vendored as git submodules and pulled by make prep, moving to a newer SDK means updating those submodule pointers and then fixing whatever the PIO or TinyUSB APIs changed. The project pins no versions in the Makefile, so a fresh clone today may not build against the same SDK revision the author used. If reproducibility matters to you, record the submodule commit hashes before you start editing.

Editorial conclusion

Adopt this if you already have an RP2350 board, an AS5600 breakout and a soldering iron, and you want a readable C base for a magnetic knob rather than a finished device. Do not adopt it if you expect a prebuilt binary, a config file, or support for a board whose pinout you have not checked. Before wiring anything, open the board file in include/ and confirm the I2C pins and the LED type: the README states the Pimoroni Tiny puts i2c0 on GPIO20/21 while the included board file targets GPIO4/5, and the WS2812 PIO program will not drive the Tiny's three-GPIO dumb RGB LED. Verify those two things first, then run make prep.

Frequently asked questions

Official sources

1. Issues
2. License: GPL-2.0
3. README
4. torvalds/ScrollWheel on GitHub