[GB] R2 Zephyr 65% Custom Keyboard

Hard forking QMK? LOL. What I did is develop RGB code and “keymaps in EEPROM” in a development branch, with the intent to generalize it with help from others and merge back to QMK master, if and when someone designed a PCB that could use it. The only people who have done that so far is @jackhumbert and yiancar (HS60 PCB), and we worked together on this, but only relatively recently. Until then, I have had effectively zero offers of help from anyone to help generalize/merge back to QMK.

The “janky command line tool” was only meant to be a temporary solution to the problem (at the time) of needing to install an entire build environment to compile QMK so you could change a keymap. I could have bashed out a Windows-only GUI for this ages ago, but thought a truly cross-platform (perhaps browser based?) solution was better. However, instead of learning how to do front-end programming in JS or whatever the cool kids are using these days, I instead chose to concentrate on a) developing firmware, b) designing Zephyr, c) designing PCBs for other people, d) helping other people design PCBs, e) helping other people fix their janky PCBs that weren’t designed by me, e) having a life outside of keyboards.

Sorry for not doing stuff as fast as people would prefer, not being good at everything and not having infinite time to do it.

11 Likes

Is it too late to drop in a Tada68 joke?

If I remember correctly (and it’s quite possible that I don’t, it’s been a while), the “keymaps in EEPROM” stuff was one of the big splits in your fork as it requires a different amount to be allocated for different sizes of boards. There’s only so much EEPROM to go around (until everyone switches to ARM, anyway, most of those have plenty). That being said, I think you mostly just built that to support the .bat config tool, which leads us to…

I had never gotten the impression that it was intended to be a temporary thing from talking with zeal or the (extremely few and brief) interactions we’ve had on Reddit (where I think we’ve argued about the same thing. When R2 zephyr ships are you just going to point people at config.qmk.fm + qmk toolbox, then? Or are you waiting for something more like Haata’s hid-io?

I also didn’t know you designed the case for the Zephyr! Feels like that should be on the product page or something :thinking:. Maybe it’s just because you hang out more on Geekhack, or the time difference or something, but you always just seemed like a quiet mystery, riding around in the background, making PCBs for people.

I’m sorry I misunderstood the intent of your config tool. As you can see in my other post, that is basically my only complaint with either of the zeal6* boards, so I’m glad to hear that was just temporary.

It looks like you double-booked your “life outside of keyboards” time :wink:

1 Like

The “keymaps in EEPROM” is not really a split, but this way of driving QMK, effectively “compiling” the keymap on the host, instead of needing to recompile QMK, is going against the QMK paradigm. Not saying either way is the better solution. There are pros and cons for each. It’s using EEPROM memory that’s not being used by core QMK core features, and also using it to store RGB settings. I’ve been working on breaking up the coupling, as well as the HID command stuff. Ideally, these features can be used in any QMK keyboard firmware, much like any QMK keyboard firmware can be made to work with config.qmk.fm.

The command line tool will be replaced at some point soon, with a GUI tool… but this is just a prettier interface to configure things without needing to rebuild firmware. However, I’ll also get things to a point that people can use either this or the “standard” way (config.qmk.fm + qmk toolbox).

1 Like

Yeah there is definitely a very strong case to be made for RGB stuff in the EEPROM, as that is something that users will likely want to change frequently. IMO, the case for keymaps in EEPROM is less strong, as people don’t tend to change keymaps that often. Maybe some people do, though? Idk. Would he cool to see like a #DEFINE KEYMAP_IN_EEPROM flag or something I guess, so that it is an option if people want it. It might start to be a problem on larger boards, though, not sure how much headroom is left.

As for the HID stuff, I’d recommended looking into the hid-io spec that @haata has been working on (hopefully he has an update on the status there as that GitHub looks a little dead). @algernon (probably not on KT yet) was working on building out some support for that from the qmk side, but beyond that I’m not really sure of the status. It looks like Haata was also working with keyboard.io to build out support for their board as well. It would be really nice to have a unified standard that can work for everyone. Then you wouldn’t even need to build a GUI tool and could just piggyback on what he has built for the ktype (and the other boards he is expanding it to)!

:tada: That’s great to hear!

I get what you’re saying here, but we’re definitely interested in supporting keymaps in the EEPROM as an option for any board. We’ve talked about introducing versioning for both the EEPROM space, and keycodes, which would help make this easier to implement.

Making the keymap-in-eeprom/eeprom in general easy to update through the Toolbox would be neat as well.

It’s R2 and I still can’t buy the PCB separately, c’mon man!

The logistics and cost of PCB production in small quantities means that offering the Zeal65 PCB separately isn’t feasible sometimes. This is a group buy for the Zephyr and technically a continuation of the first round, as the case and PCB design has not changed, and parts were pre-purchased for a limited number of units.

Why do you want a PCB separately?

Thanks for the feedback. I understand the cost and logistics of production in small quanties. I’m not wondering why there hasn’t been a separate run of PCB. I’m wondering why I can’t pre-purchase an additional unit to be made during the R2 order.

I need a PCB for custom I’m building, and there aren’t that many 65% QMK options available. Last keyboard I made was a low profile TADA with a JC65 QMK, but those aren’t available at the moment.

I would also possibly pick up a standalone pcb. I’m trying to keep my board budget in check so not sure I can shell out for the full deal (though I really want a board with a nice thicc plate like that), but it would be cool to have a pcb to play with. Some people might also be interested in spare PCBs as well in case they butcher one trying to solder it or something.

Adding additional PCBs to the order should help lower costs a bit on your end anyway, right?

1 Like

Finally broke down and bought one. I went with the purple with the silver brass pvd. Incredibly excited to try this!

Have you considered a clueboard PCB? It’s technically a 66% but I love mine :slight_smile:

I’m not into the wasted space. I really like the layout on my m65 and my tada with jc65 qmk pcb.

Do you think the same Penumbra set will look good on purple? That’s what i’m thinking of doing, just not sure how they will pair up. Obviously it looks slick on yout midnight blue!:slight_smile: but i am also thinking of maybe changing it to 1965 later, and that might look beter with purple.

I have got blue Zephyr.

5 Likes

i really like this layout

What caps are people planning on putting on Eggplant Purple? Trying to decide which color to go with…

I’m thinking GMK Phantom.

1 Like

I’m thinking violet tendencies.

Any news on the eggplant purple zephyr* sample? *Looks like before Aug 31st