-
-
Notifications
You must be signed in to change notification settings - Fork 39.9k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[Keyboard] Add splitkb.com's Halcyon Kyria rev4 #24512
Conversation
03bbe28
to
47444ed
Compare
Is there a specific reason for labeling this as "rev4"? I'm guessing because the kyria has 3 revisions already. But this isn't the same design, and features fewer keys. And if that's the reason, then calling this rev4 doesn't really make sense. That would be like olkb calling the preonic the planck rev2. It's not the same design, and not really a revision. It's a different board, completely. |
The design is mostly similar except for the microcontroller area but still has the same amount of keys, key positions and layout, nothing is changed in that aspect. What made you think it's not the same design/amount of keys? |
I apolgize. I have no ideay why I thought it had a different layout (specifically 3x5). That said, the naming is still... problematic, IMO. Eg, it's not the 4th revision in the halcyon kyria series, which is distinctly what the name implies. And the readme doesn't shed any light on that fact. The initial text for the PR would actually do well in the readme.n |
As for the naming: Halcyon as a project name, similar to Aurora, should be distinctive enough that having the board be revision 1 should be workable. However, a few year of customer support taught me that the revision number is the thing people look at. I anticipate questions such as "is my case compatible", "I thought I could order these parts" and so on and so forth, which would be common enough to become a real headache—both for customers and myself. For that reason, I feel like picking revision 4 is the safest choice, despite revision 1 being more technically "right". |
Re the naming, that's a fair point, and you would have more experience with that as a vendor, I'd think.
Re peripheral hardware defaults: I still think it would be best to have them here. I'm not sure this is the best way to handle it, but this is what I've done locally for some of the config: And since core features that use i2c/spi use the As long as there is a way, that's good. But my concern is with people not using the splitkb/halcyon userspace, or having to copy the code. |
Updated to latest breaking changes. |
* Add Halcyon Kyria Rev4 * Remove bootmagic and unused features * Fix encoderindex * Update readme.md * Remove rgblight * Implement requested changes * Add encoder update user * Remove rules.mk and add VIK configuration * Move options to config.h * Update RGB keycodes (qmk#24484) * implement changes --------- Co-authored-by: harvey-splitkb <[email protected]>
* Add Halcyon Kyria Rev4 * Remove bootmagic and unused features * Fix encoderindex * Update readme.md * Remove rgblight * Implement requested changes * Add encoder update user * Remove rules.mk and add VIK configuration * Move options to config.h * Update RGB keycodes (qmk#24484) * implement changes --------- Co-authored-by: harvey-splitkb <[email protected]>
* Add Halcyon Kyria Rev4 * Remove bootmagic and unused features * Fix encoderindex * Update readme.md * Remove rgblight * Implement requested changes * Add encoder update user * Remove rules.mk and add VIK configuration * Move options to config.h * Update RGB keycodes (qmk#24484) * implement changes --------- Co-authored-by: harvey-splitkb <[email protected]>
* Add Halcyon Kyria Rev4 * Remove bootmagic and unused features * Fix encoderindex * Update readme.md * Remove rgblight * Implement requested changes * Add encoder update user * Remove rules.mk and add VIK configuration * Move options to config.h * Update RGB keycodes (qmk#24484) * implement changes --------- Co-authored-by: harvey-splitkb <[email protected]>
* Add Halcyon Kyria Rev4 * Remove bootmagic and unused features * Fix encoderindex * Update readme.md * Remove rgblight * Implement requested changes * Add encoder update user * Remove rules.mk and add VIK configuration * Move options to config.h * Update RGB keycodes (qmk#24484) * implement changes --------- Co-authored-by: harvey-splitkb <[email protected]>
Halcyon Kyria rev4
Description
This pull request adds support for splitkb.com's latest product, the Halcyon Kyria rev4.
It is the fourth Kyria version and the first product in our new Halcyon range. These keyboards will be similar to our Aurora series but where all the components will be pre-soldered. The microcontroller will still be hot swappable with our new Halcyon standard. The keyboards will come with a microcontroller pre-installed. Additionally we added a VIK connector to the keyboards. We plan to release more of our Aurora keyboards as Halcyon keyboards in the future.
The Halcyon Kyria rev4 is available for sale next month at splitkb.com
For more information about the Halcyon series, please see our summer blog post
Types of Changes
Checklist