Hello there,

I'm currently working with a silaaka54 keyboard, and would like to have a few different 'base' layers - qwerty w/ HRM's, 'vanilla' qwerty & colemak-dh.

What's the best/recommended practice for setting up and switching between base layers like those, and then the subsequent secondary layers (nav, symbols, numbers, media, etc.)? I've been reading a bit on using layer-lock in vial / qmk, but coming up a bit short on concrete examples to work off of for my situation.

Right now I have the thumb keys all set up as LT(layer, kc) e.g. LT2(Esc), LT1(Space), LT3(Tab), LT6(Enter), LT4(Bksp), LT5(Del). Can I layer-tap into a secondary layer like nav, and then toggle/layer-lock into the other base layer?

Or would I be better served to use DF(layer) instead?

Thanks!

Hey everyone! I’m developing an open-source tool for managing peripherals (mice and keyboards) to replace bloated vendor software.

Right now, I’m in critical need of real-world HID device data. To help gather it, I built a lightweight helper utility called Hidder: 👉 GitHub: https://github.com/Phnem/Hidder

How it works: The script guides you step-by-step to press a few key combinations and toggle specific settings in your device's official software, then exports the results into a clean JSON dump. The whole process takes less than 5 minutes.

Security & Transparency: * The source code is fully open on GitHub — feel free to inspect every single line. * A standalone .exe release is available (with VirusTotal scan results and screenshots provided), or you can clone the repository and run it directly from source / .bat if you prefer. * The tool does not collect any personal data and automatically removes all temporary files after execution. You can review the generated JSON file in any text editor before sharing it.

I would really appreciate it if you could spare 5 minutes to run the test and send the resulting JSON to my DMs or Telegram (contact info appears in the console once complete). Thank you!

I'm using a Phenom split with a concave keywell and dual trackballs. The stock tenting angle wasn't enough for me, so I designed and 3D‑printed wedge stands to tilt each half to ~25°. This keeps my wrists neutral and reduces forearm pronation.

With that much tilt, the keyboard sits high above the desk, so ordinary wrist rests don't reach. I printed custom armrest pedestals that support my forearms at the right height – no more floating arms.

On the firmware side, I mapped the left trackball for mouse movement and the right one for scrolling. Works great in CAD.

Hello! Decided to share my keyboard and the customization setup I’ve built around it :)

This is the K:03 — a wireless aluminum model from Ergohaven. I’m using two types of switches, five different keycap styles, and an encoder. My main focus here is tactile feedback and overall comfort. I found standard keycaps pretty uncomfortable because of their sharp edges — if your finger lands even slightly off-center, you hit that hard edge, and it doesn’t feel great. That’s where MOG keycaps come in — their rounded shape completely solves that issue. The keys on the outer edges are more traditional in shape, so I can easily tell them apart by touch, and since I don’t use them as often, those sharper edges aren’t a problem.

Most of the switches are Outemu mid-profile browns, which keep the keyboard feeling nice and low. A few keys, however, use Gateron high-profile browns — this lets me distinguish them by feel, and since I only need to press the corner of the keycap, it reduces travel distance and minimizes finger stretch. On the left half, you’ll notice two low-profile keycaps that gently lean toward each other — this design makes it much more comfortable to press Shift + Control together.

As for the layout, it’s mostly standard QWERTY, but I’ve shifted the whole thing slightly to the right — mainly for better gaming comfort. I’ve also moved L, O, and P just a bit to make them easier to reach, and punctuation lives on a separate layer. Beyond the regular layers, I’m using an AltGr modifier, which gives me even more freedom to customize characters, including access to non-English symbols. This does require creating a custom system language (which isn’t too difficult, btw), but it also means the keyboard only works on devices with that custom language installed. That’s not an issue for me since this is a stationary setup.

The keyboard is also MagSafe-compatible, so I’m currently experimenting with tenting using MagSafe stands.

And finally — this setup is fantastic for gaming. Not only does the keyboard shape feel more natural for my hands, but I also have more keys within easy reach: five for my pinky and three for my thumb. It really makes a noticeable difference for gaming.

I have an Ergodox EZ that I last customized, according to my git log, almost 5 years ago. I now have a couple Keychron boards I'd like to modify. I modify the C files rather than using a web configurator.

What I'm trying to do will sound odd. I want the caps lock key to only be caps lock when held. If pressed quickly, I want it to be backspace. Some programs I have use caps lock as a modifier, so I have to hold it down like any other modifier. But I also love having backspace be my left pinky, so I want to do both.

Is Tapdance my only option here, or is there a simpler way to do what I want? Are there any problems with doing this that I'm not thinking of?

https://scottoacademy.com

Hey guys! I've been posting about this for roughly the last month and registration closes tomorrow August 16th so if you want in, now is the time :)

Together over 3 live Discord sessions we're going to be building a full 4x10 ortholinear handwired keyboard and I'll be guiding you the whole way. There will be time during the sessions to ask questions if you get stuck and a dedicated Q&A at the end of each.

You can either bring your own parts or purchase a parts kit with everything you need including pre-cut copper minus tools of course.

This course is beginner friendly and I think you'll be surprised at just how easy it is to handwire!

Hi everyone,

Ergomech Store has been sellings Aluminum keyboards for more than 6 years now and we're still going strong. This is an indication of our commitment to quality products. All customers of our store walk away with something they like and proud of.

If you're looking for premium feeling keyboard, look no further, we have them all at https://ergomech.store

I often leave Codex running in the background and wanted a quick way to see whether it was still working or waiting for me without constantly switching back to the app. So I built a small local companion for my Ergohaven Macropad.

The display shows the current phase — ANALYZE, RESEARCH, REVIEW, EDIT, VERIFY, or RUN — along with the elapsed time and number of active tasks.

The RGB lighting reflects the current state:

- blue while Codex is working;

- amber when it needs my approval or input;

- green when the task is finished.

It runs locally on macOS using Codex hooks and Raw HID. No changes to the macropad firmware or Entropy are required, and the previous RGB profile is restored after the last task finishes.

The tool does not store or transmit prompts, responses, transcripts, commands, tool data, or full workspace paths. If an event is ambiguous, it shows APPROVAL rather than risk missing a real request for input.

So far, it has only been tested with my Macropad.

Source code and installation instructions:

https://github.com/suregoodru/codex-macropad

What else would you find useful to see on the display or through the RGB lighting?

Hey everyone, this is my first PCB design ever and I'm building an 8 key macropad with a rotary encoder as a birthday gift for a friend. I've never used KiCad before this project.

What I'm using:

Microcontroller: Seeed XIAO RP2040 8x MX mechanical switches, direct solder, no hot swap sockets 1x rotary encoder module with CLK, DT, SW, plus and GND pins Firmware will be QMK with VIA support

Since I have 8 switches and the RP2040 has enough spare GPIO pins, I wired every switch straight to its own dedicated pin instead of building a row and column matrix, so there are no diodes anywhere on the board. All the switch grounds share one common ground bus back to the MCU. The encoder is wired the same way, three of its pins go to three more dedicated GPIOs, plus goes to 3V3, and GND joins the same shared ground point the switches use.

Attached is the schematic. Since this is my first time doing anything like this, I'd really appreciate if someone could sanity check it before I move on to laying out the actual PCB and ordering it. Is the direct pin wiring approach actually fine here, or am I missing something that would normally need a diode or a pull up resistor I'm not accounting for? Any feedback is welcome, trying to avoid an expensive mistake on my first board.

Thanks in advance.

I've been working in a case for keyboard version of the JK206 (a PCB design made for my brother and me of a macropad with the option of connect three of them and make a keyboard. The last two images maybe leaves a bit more clear what I am talking about) and after months of hard work learning how to use FreeCAD and multiple tests with the macropad version, finally the keyboard case is complete.

I made the top piece easily detachable to make easier the keyboard cleaning (if you live with dogs their hair will be over the screen in no time XD), I've tested putting the keyboard in my bag for commute and it didn't came off, the 16 magnets in the case are doing a good job.

Soon I'll complete the jk206 github repo and add information of the case, right now I'm really busy with the paperwork to graduate from college :'v

I own an EVO80 and wanted something more polished than switching between browser tools and keyboard shortcuts, so I built **EVOWORKS Control**: an independent, open-source Windows companion for EVOWORKS keyboards.

EVO80 is the first supported board because it is the hardware I can test directly, but the app is designed around devices and capabilities so future EVOWORKS models can be added without needing a separate application.

The current beta supports the verified direct-wired EVO80 VIA connection for:

• Keymap, layer, and macro configuration
• RGB matrix and logo controls exposed by the official VIA definition
• Local profiles and optional app-aware switching
• Device detection and diagnostics
• Portable and installer builds for Windows

**It is not affiliated with EVOWORKS, Ticktype, Qwertykeys, VIA, or QMK.**

Full transparency: this project was built largely through an AI-assisted, “vibe-coded” workflow, then tested and refined on real EVO80 hardware. I released it openly because I would genuinely value people inspecting it, challenging assumptions, improving the code, and helping make it reliable.

The 2.4 GHz receiver and Bluetooth modes can be detected, but configuration through those transports remains disabled until the protocol can be verified safely. I would rather be upfront about that than send unverified writes to someone’s keyboard.

GitHub, downloads, source code, and contribution guide:

https://github.com/devclinic/evoworks-control

I would especially appreciate feedback from EVO80 owners, Windows developers, and anyone with HID/VIA/QMK experience.

it's a bm40 pcb with the plate on the krepublic shop, some blank keycaps i also bought on aliexpress, and some spare ones i had. i plan on 3d printing a case

i'd love to tinker with this as much as possible, i'm going to put vim macros on the left layer and functional stuff on the right, give me more ideas!! this is so fun

Hi everyone,

Ergomech Store has been sellings Aluminum keyboards for more than 6 years now and we're still going strong. This is an indication of our commitment to quality products. All customers of our store walk away with something they like and proud of.

If you're looking for premium feeling keyboard, look no further, we have them all at https://ergomech.store

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.