[mondalaci]

The modules are a game changer of actual usability value which haven't been implemented by any keyboards yet. Ignoring their value and calling them doodads is unfair.

None of the open source firmwares support the modular architecture of the UHK or allow for the easy update of the configuration without using full-blown compilers so they are not suitable for us.

We'll release further UHKs of additional layouts, columnar included.

[SuperPaintMan]

Seems easy enough to check if a device at a given I2C address is there and enable functionality. There few a few devices doing this already.

Via has been doing non-flashing keymap updates for years and is cross platform. Reach out and help contribute.

Here's hoping you can make a keyboard worth the name. Exposing interfaces to users can bodge on their own hardware would be a good start. Maybe getting a ergonomics nuts on the team as well.

[mondalaci]

You're vastly oversimplifying product design. It's not just about I2C. No other split keyboards allow for the attachment of extra modules in the middle.

You hardly ever used the UHK, yet you keep suggesting that we should use external firmware projects. We use ours because it offers certain benefits specific to our design. Even if you used the UHK, there's a good chance you'd ignore what it can offer because you're so biased toward columnar layout and other open source firmware projects.

I appreciate the value of columnar layouts, but the rest is bias towards your own preferences.

[SuperPaintMan]

You're right, it's about prototyping, finding the right components that won't bust the BOM, stress testing, manufacturing molds and handling all the warts of production and fulfillment at scale. A broad range of engineering schools and non-eng talents are needed to bring a decent product to market and you've done that. So kudos.

I'd be curious to know why you didn't use QMK or add in the features seems like it would be a hell of a lot easier and allow for contribution. SplitCommon support has been around forever, and you can do dynamic keymaps removing the need for full board flashes. Worst case PRs, that's how Zeal does their boards for features that don't exist.

I am very biased, that is correct. I wouldn't have tried to design a modular/hackable keyboard otherwise. Sadly I'm a one man shop and busy as hell with everything involved so making gUnit 1u/2u modules and interconnect devices hasn't been given much time. If you look around hard enough you can find working trackball modules for Gergo and the interface is simple enough that you can easily bodge in gear with 15$ in prototypes off JLC.

It's very hacky, there's breakouts everywhere, members do all sorts of strange crap with their boards (look at some of the firmware for Georgi on GitHub, it's gross and beautiful colemak-dh on 2rows?), TrackPoints, balls, vibration motors and other goofy shit.

But that's the crux of it, it's _not_ a polished keyboard (I had 300$ and wanted to design a better keyboard), it's a keyboard meant for hacking on and extending with a focus on Ergonomics. If it doesn't have bodge wires flying off of it, you're doing it wrong.

For the record: A simple Y-splitter for a TRRS is all you need to get power/comms retrofitted on 95% of splits for extra modules.

[mondalaci]

QMK tries to be everything for everyone. I'm sure we could make it work, but the UHK firmware is designed in very specific ways dictated by our objectives. This includes everything, such as the binary configuration serialization format, the USB protocol, the module protocol, and the I2C scheduler and drivers. At the end, we would end up hacking the hell out of QMK, and probably still wouldn't meet certain goals we're after given the inherent design of QMK. It's great that QMK exists, but I'm confident our firmware suits our needs better.