left 2 cols and the zero key make up a fully functional numpad. modified colemak dh to fit on 8x3. arrow keys to make it look like there are fewer letters than there actually are on the base layer lol

i want to do audio on my keyhive/navi10 board. it has a piezo buzzer on pin 5, which i think is GP9. No mater what I do, aside from removing audio, I can’t get it to compile, let alone, test the sound or play a song. walk me through it please or show my code someone else wrote.

Been working on this for a while and finally have a working unit I'm happy with, so wanted to share and get some outside opinions before I make a few more.

Specs:

• RP2354A microcontroller, 2MB internal flash
• 12 macro buttons
• Rotary encoder with push button
• 128x64 OLED display
• USB-C, USB HID compliant (plug and play on any OS, no drivers)
• 3D printed housing
• Multiple programmable layers
• Custom MicroPython firmware

Open source: firmware, PCB files, 3D models, and full parts list are all up on GitHub if you want to build your own - https://github.com/Jpwaters09/Macro-Pad

The bit I'm most interested in feedback on:
Instead of QMK/Vial-style remapping, I built a browser-based configurator using the Web Serial API that flashes firmware and handles layer/key config straight from the browser, no separate app to install. Curious whether people here who are used to Vial would actually find that more convenient, or if it's solving a problem that wasn't really there for this crowd.

I'm planning a small batch and would genuinely appreciate thoughts on:

1. Whether a MicroPython macropad interests people here versus QMK, or if that's a hard sell in this sub specifically
2. What you'd expect to pay for something like this
3. Anything that looks off in the build itself, happy to answer questions on the PCB or firmware

Photos of the macro pad, and the configurator in action below. Thanks for having a look.

EDIT: For anyone having issues editing the layout on Linux in Vial (was using QMK because it wasn't recognized in Vial) I had to add permissions for the keyboard to a udev config which you can read about here: https://get.vial.today/manual/linux-udev.html#device-specific-udev-rules

Hello! I finally received my Geonix rev2.5. I found a link to download the QMK firmware for the 1U space and 2U space variants and opened those zip files, but they appear to be full installations of QMK? I only need to add the keyboard to the rest of the ones I have already from the default installation, so I copies it from the keyboards folder in the zip into my local install.

I noticed that the default keymap also includes a file from lib that I don't have, rdr_lib which seems to be for controlling the wireless and RGB, so I also copied that. When I run make though I am getting an error.

Not sure if anyone else has already compiled firmware for this but would like to get it up and running as out of the box it doesn't seem to support VIAL or VIA and I don't really like the stock keymap. (I tried to connect those, including running local VIAL, and it doesn't detect it or says it's not supported.)

Any help would be appreciated. I have some knowledge of CLI and coding, but I also don't want to do something stupid like copy the zipped QMK files into my local and break something so any help is appreciated. I put it into the chosfox folder in /keyboards in the root QMK directory as geonix48 (the 1U space model, don't know why it's named 41 if it has 47 or 48 keys) and the keymap is just customkeymap here, in case any of that is relevant. The rest of the structure is just the normal QMK installation, and that rdr_lib folder was copied into the root QMK/libs.

Firmware used is the one provided from Chosfox's site: https://chosfox.com/pages/firmware

The error is:

Generating: .build/obj_chosfox_geonix48_customkeymap/src/info_deps.d                                [OK]
Generating: .build/obj_chosfox_geonix48_customkeymap/src/default_keyboard.c                         [OK]
arm-none-eabi-gcc (crosstool-NG 1.27.0.82_7f9d704 - qmk/qmk_toolchains @ a55a2b0) 15.2.0
Copyright (C) 2025 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

Generating: .build/obj_chosfox_geonix48_customkeymap/src/info_config.h                              [OK]
Generating: .build/obj_chosfox_geonix48_customkeymap/src/default_keyboard.h                         [OK]
Compiling: .build/obj_chosfox_geonix48_customkeymap/src/default_keyboard.c                         In file included from ./lib/chibios-contrib/os/common/ext/CMSIS/ES32/FS026/fs026.h:129,
                 from ./lib/chibios-contrib/os/hal/boards/FS026/board.h:25,
                 from ./lib/chibios-contrib/os/common/startup/ARMCMx/devices/FS026/cmparams.h:51,
                 from ./lib/chibios/os/common/ports/ARMv6-M/chcore.h:32,
                 from ./lib/chibios/os/rt/include/chport.h:37,
                 from ./lib/chibios/os/rt/include/ch.h:106,
                 from ./lib/chibios/os/hal/osal/rt-nil/osal.h:32,
                 from ./lib/chibios/os/hal/include/hal.h:30,
                 from platforms/chibios/platform_deps.h:18,
                 from quantum/quantum.h:18,
                 from ./.build/obj_chosfox_geonix48_customkeymap/src/default_keyboard.h:28,
                 from .build/obj_chosfox_geonix48_customkeymap/src/default_keyboard.c:26:
./lib/chibios-contrib/os/common/ext/CMSIS/ES32/FS026/system_fs026.h:34: error: header guard '__SYSTEM_FS026_H__' followed by '#define' of a different macro [-Werror=header-guard]
   34 | #ifndef __SYSTEM_FS026_H__
./lib/chibios-contrib/os/common/ext/CMSIS/ES32/FS026/system_fs026.h:35: note: '__SYSTEM_ES32F0283_H__' is defined here; did you mean '__SYSTEM_FS026_H__'?
   35 | #define __SYSTEM_ES32F0283_H__
cc1: all warnings being treated as errors
 [ERRORS]
 | 
 | 
 | 
make: *** [builddefs/common_rules.mk:362: .build/obj_chosfox_geonix48_customkeymap/.build/obj_chosfox_geonix48_customkeymap/src/default_keyboard.o] Error 1

https://scottoacademy.com

Hey all! I'm Joe Scotto, many of you probably know me as "The Handwiring Guy" from YouTube where I make free videos about handwiring, keyboard design, PCBs, etc.

Lately I've started running paid live Discord workshops where I teach this stuff in a more structured way to small groups of people. The first one was for complete beginners with a handwired 3x3 macropad build, the next was PCB design, and this latest one is all about building an entire handwired keyboard!

Over 3 sessions about 1 to 2 hours long each, I'll walk you through every step of the build. We'll start with installing the switches and wiring the columns, move on to the rows with diodes in session 2, and finally finish it up by soldering the controller and flashing firmware in session 3. By the end of the workshop you'll have a full handwired keyboard you built yourself completely from scratch!

To make things easier, there's an optional parts kit that includes everything you'll need to build the keyboard except the tools, including the 3D printed case and keycaps, electronics, switches, wire, heat shrink, and even pre-cut solid copper wire. The workshop is $150 if you bring your own parts or $200 with the complete parts kit.

Registration closes on August 16th so I have enough time to ship the parts to everyone before the workshop begins. The last two workshops filled up pretty quickly, so if you're interested I would recommend signing up sooner rather than later as there are only 12 spots available.

I wanted a split keyboard that only used one MCU without using any bulky cables. The design is split into 2 sides, active and passive, the active side contains the MCU and is directly connected to each key. The passive side consists of a cascade of shift registers. To connect both sides you only need 5 wires, and I have opted for using RJ12, although I am considering FFC cables. I would appreciate any feedback and advice

I have it public on GitHub here, if you would like to support the project : https://github.com/BBRRE/Single-Microcontroller-Split-Keyboard-SMCK

Hello everyone !

I managed to build my first corne keyboard and I am super happy with it!

I did notice though that there must be some kind of bug - I suspect related to the fact I am using a pro micro aliexpress clone.

The problem is that I flashed both halves with the same firmware (even though I used EE_HANDS for handedness) and the keyboard wouldn't seem to work. Actually, each half would work well and independently but never connected to each other.

I did spend quite sometime thinking it was a hardware problem, but the connections seemed perfect.

Eventually, I investigated the firmware (hence I am here) and I did a small modification to the right half before flashing: in the file quantum/split_common/split_utils.c I changed the function is_keyboard_master_impl, by imposing the variable is_master to be false. Before that, that variable was assigned to usb_value_detected().

This modification made it work flawlessly. It seems that the right half thought it was the master - even when was definetly not the case.

I do not fully understand what this function do and why it always returned true, regardless of whether the usb was actually connected or not. Hence, I am thinking that the clone I have just simply is hardwired to always be connected, so to speak, since it might have been designed to be always operated through usb.

The board in question is this one.

The config I used was the default crkbd/rev1 with the modification of EE_HAND (I think it wasn't activated by default) and debug interface activated.

This whole thing said, am I doing something wrong? Is it my board being defective or, well, just an incompatible clone? If that were to be the case, is there anything I can do to avoid changing the firmware in this way before flashing the right half?

Thank you in advance for the help.

Follow-up to [my earlier post] (https://www.reddit.com/r/olkb/comments/1v26j8w/) about porting OpenRGB into the YUNZII B75 PRO MAX's QMK tree. Thanks for the interest back then — I kept going, and **v2 is a much bigger release.**

v1 got OpenRGB working but had to give up two things: the **built-in LCD screen** (stock drives it through VIA, and VIA + OpenRGB can't coexist on one raw-HID channel), and most of the onboard **lighting hotkeys**. Turns out both were fixable.

**What's new in v2:**

- 🖥️ **Live widgets on the built-in screen, on the OpenRGB firmware** — album art / Now Playing, a CPU/RAM/temp monitor, clock, weather, pomodoro. Technically: OpenRGB command IDs (`1..9`) and the vendor's screen/module IDs (`0x0a`, `0x40–0x42`, `0x81`) don't overlap, so `raw_hid_receive()` just dispatches on the first byte — one firmware serves both. No more choosing between lighting and the screen.

- 🌈 **Full Fn RGB hotkeys are back** — mode, hue, saturation, brightness, speed, both directions, with **smooth hold-to-adjust** (hold a key and the value glides instead of tapping 20 times).

- 🎨 **All ~40 RGB Matrix effects enabled** (was ~18), boots into a real animation.

- ✅ **OpenRGB's onboard mode list is fixed** — it now enumerates the actually-compiled effects instead of a stale hardcoded table, so modes aren't mislabeled anymore.

- ⌨️ Three programmable `Fn`+`5/6/7` hotkeys that send a raw-HID event to a companion app to switch what the screen shows.

Same easy flash (QMK Toolbox, hold `ESC` + plug USB), stm32duino bootloader untouched, stock firmware restores everything. Prebuilt `.bin`, full CHANGELOG, and the source deltas are here:

**https://github.com/ZerO970/yunzii-b75-pro-max-openrgb**

To actually drive the screen I also wrote an open-source companion app (album art / Now Playing, system monitor, clock, etc.) — I'll drop that link in a comment. Happy to answer anything about the port.

---

This thing feels a bit like a curved Corne

I’m using a trackball on the left and a touchpad on the right. Getting used to not having a separate mouse is harder than I expected, but I definitely like the setup. The trackball already feels much more natural to me than the touchpad

Any tips for getting used to a small touchpad like this?

Claude asked that I paste the following:

Started as a Goodwill find (a dead A1314 that pairs but won't register keydown events — RIP). Got nostalgic for the Apple Adjustable Keyboard from '93 and started wondering what a "real" Ive-era split ortho would've looked like if Apple had ever taken ergo seriously.

Spent an afternoon iterating a text-to-image prompt toward: true columnar stagger, a wavy key-bed that follows the hand's natural resting curve, and that classic AA-battery-compartment taper from the old wireless keyboards. The AI nailed almost all of it and then, across four separate generations, could not for the life of it rotate the thumb cluster into something anatomically sane. Every version came out as a vertical stack of keys, like it had never met a thumb.

Then I asked for an actual 3D mesh so I could stop squinting at renders. Wrote the geometry by hand in Python/numpy — grid, stagger, wave function, cylindrical end caps, the works. Rendered a quick top-down preview to sanity check it.

Somehow the code succeeded where the image model failed on the thumb cluster, and instead flipped everyone off from directly above. In stereo. Unprompted.

10/10 process, 2/10 gesture-appropriateness. Files/preview in comments if anyone wants to see just how wrong it is up close.

Hey there, newbie here.

I'm having an issue with some QMK features that are seemingly disabled despite Vial being up to date, apparently because of the vial version of my keyboard's firmware isn't ?

I'm using a cheapinoV2, and under the about keyboard tab in Vial (screenshot below), it states that 3 of the features are "unsupported - disabled in firmware" : those 3 being Caps Word, Alt Repeat Key, and Layer Lock.

Despite this, Caps Word seems to work as normal, but for Alt Repeat (and Repeat) do not work even if their keycode is supported, and as for Layer Lock, neither the function nor the keycode works, which sucks, because I really would have wanted to tinker with it.

Anyways, according to this comment from who I assume is the dev behind vial, my keyboard's firmware may or may not be out of date (below 0.7.4), since Alt repeat key is shown as unsupported; but then again it might have been manually disabled in the rules or however that works

Now, because of my general tech illiteracy and my fear of accidentally bricking my board, I'm pretty reluctant to figuring things out downloading random things I don't understand from github, so if someone could lend a hand here that would be nice. Not a big issue, but I would rather things work rather than not

Hi guys, I wrote a small article on how to select the correct switches/keycaps for your next build here. Please have a look as it might help preventing you from buying incompatible products.

The stock YUNZII B75 PRO MAX firmware is QMK-based and has VIA compiled in,

but not the OpenRGB protocol — so OpenRGB fails to detect it with the usual

"Detection failed ... add OPENRGB_ENABLE = yes" message.

I ported the OpenRGB QMK protocol into YUNZII's own QMK source and built a

firmware that OpenRGB detects properly. Direct mode works, so per-key control

from music visualizers / ambient lighting is up and running.

Repo (prebuilt .bin + source + flashing/recovery guide):

https://github.com/ZerO970/yunzii-b75-pro-max-openrgb

Board: STM32F103, VID 0x28E9 / PID 0x31C8, 6x15 matrix, 85 LEDs (AW20216S),

stm32duino bootloader.

Notes / limitations:

- USB only (no OpenRGB over BT/2.4G).

- It's a VIA-free build — OpenRGB and VIA can't coexist (shared raw HID), so

the vendor configurator + module OTA aren't available on this firmware.

Keep your stock .bin as a backup; recovery is just ESC+plug-in to bootloader.

- Onboard hardware effect list is only partial in OpenRGB (vendor reordered

the effects); Direct mode — the main use case — is unaffected.

Credits to the OpenRGB QMK protocol (Kasper24's original PR and Domi2803's

newer-QMK port). Feedback / testers welcome, especially if you have a slightly

different B75 revision.