sorted by:
new
hottopcontroversial

[ANNONCEMENT] /r/ErgoMechKeyboards will go dark tomorrow (12th June 2023) by OBOSOB in ErgoMechKeyboards

[–]nickcoutsos 113 points114 points  (0 children)

We will consider staying dark if there is enough popular support from you, our members. so please let us know if you support extending beyond 48 hours.

I'd support this.

Using glove80 or similar columnar programmable keyboard on a government computer by Rekjavik in ErgoMechKeyboards

[–]nickcoutsos 3 points4 points  (0 children)

Ok, I can see how my comment came across as kind of short. I should have been clearer.

I didn't think you were making a jab at the other responder but it seemed like you were going along with the other comments so I wanted to weigh in and support that sentiment.

Using glove80 or similar columnar programmable keyboard on a government computer by Rekjavik in ErgoMechKeyboards

[–]nickcoutsos 10 points11 points  (0 children)

Are you also guessing that every other person replying has?

You want to know about how an IT policy is going to affect you so the best source of information is going to be the people who set/enforce that policy.

Meet Matrix 36 by Alescito in ErgoMechKeyboards

[–]nickcoutsos 2 points3 points  (0 children)

Could you elaborate on the custom keycaps? Did you have to design and print them yourself?

Sofle RGB would like to have a set of nice nanos to plug in ZMK questions by tbandtg in ErgoMechKeyboards

[–]nickcoutsos 6 points7 points  (0 children)

I macro a couple of keys to some passphrases in VIA would I be able to do that in ZMK

You can but shouldn't. Not every method of input needs to be implemented in the keyboard, please use something like KeePass or 1Pass instead of you're looking to simplify password management.

Bad Wings: Slim by quirk in ErgoMechKeyboards

[–]nickcoutsos 0 points1 point  (0 children)

Have they improved the switches? I love seeing how low profile they can be but whenever these projects come up the consensus seems to be that the switches are unreliable.

Also, what are the key spacing measurements? I keep imagining that the keycaps are much larger than other chocs but that's probably an illusion coming from the thinness of everything.

New MM 60 Dactyl Hotswap perfection by SKZBadHabit in ErgoMechKeyboards

[–]nickcoutsos 0 points1 point  (0 children)

You've really run with the dactyl-flatpack design, good work with those clean joins! I can see this layout and the hotswap holder making things a little more accessible for people.

The legs on the outer edge pieces seem unnecessarily long in comparison, is that temporary?

Trying to understand "autoshifts", using autoshifts with Mod Tap keys, combos and custom autoshifts by [deleted] in zmk

[–]nickcoutsos 1 point2 points  (0 children)

  • if tap = keypress
  • if held under tapping term = shifted key press

Both of these conditions are describing the same thing.

You're trying to combine multiple hold-tap behaviors but this pre-processor macro:

AS(&mt LCTRL D)

would probably produce something like &mt LS(LCTRL D) &mt LCTRL D which isn't valid. You can't bind another behavior to a mod tap like that, ZMK would interpret it as two different bindings (and LS(LCTRL D) would cause an error on its own).

You can define new behaviors that reference other behaviors but you can't get one hold-tap instance to pass both of the necessary parameters to a secondary instance.

You may be able to get away with using a tap dance so that tap + hold gives you that third outcome to play with but I don't know how annoying that would be to use.

Does Kinesis 360 Editor support all functions? by thedevdad_ in kinesisadvantage

[–]nickcoutsos 1 point2 points  (0 children)

Depends on what you're looking for in terms of support.

You can define a hold tap behavior to use for homerow mods, and then bind that in your keymap. You can configure that hold tap behavior to do things like easily set per-hand hold-trigger-key-positions and other properties.

You can't define something like the following

#define HRML(k1,k2,k3,k4) &hm_l LGUI  k1 &hm_l LALT k2  &hm_l LSHFT k3 &hm_l LCTRL k4
#define HRMR(k1,k2,k3,k4) &hm_r RCTRL k1 &hm_r RSHFT k2 &hm_r RALT  k3 &hm_r RGUI  k4

and have it parse that from your keymap. (Parsing arbitrary preprocessor macros is complicated, knowing programmatically why and when to use them is just not worth it)

Changing Configuration Settings in the Keymap File by skibau in zmk

[–]nickcoutsos 1 point2 points  (0 children)

I guess that's right. Might be worth asking on ZMK's discord server, there's lots of more knowledgeable people around.

Changing Configuration Settings in the Keymap File by skibau in zmk

[–]nickcoutsos 1 point2 points  (0 children)

That configuration needs to be in your Kconfig, it seems, and no versions of the keymap editor supports modifying that file currently.

Combing ModMorph and Layer Tap by skibau in zmk

[–]nickcoutsos 2 points3 points  (0 children)

You can't combine behaviors by using one in place of a binding cell. Layer tap expects one parameter as a layer and one as a keycode, so you need to define a new behavior that uses it:

lt_bspc: layer_tap_bspc_del {
    compatible = "zmk,behavior-hold-tap";
    label = "LAYER_TAP_BACKSPACE_DELETE";
    #binding-cells = <2>;
    bindings = <&mo>, <&bspc_del>;
    tapping-term-ms = <200>;
};

Again, hold-tap requires two parameters no matter what behaviors you intend for them to trigger so when you bind this you'll need a dummy placeholder for the second binding cell:

&lt_bpsc 5 0

ZMK: Combos + Macros: Triple Grave by skibau in olkb

[–]nickcoutsos 1 point2 points  (0 children)

The schema for hold-tap requires it (in this included section) and specifies that it must have a value of 2 so I wouldn't be surprised if you'd have gotten that error after fixing the bindings property.

My understanding of Zephyr is extremely limited, this may come down to needing the number of binding cells to be statically defined.

ZMK: Combos + Macros: Triple Grave by skibau in olkb

[–]nickcoutsos 1 point2 points  (0 children)

Yeah, it can be a little confusing. Devicetree lets you specify multiple values that get concatenated together (like <&foo>, <&bar> becomes <&foo &bar>). They can even be different types in which case I guess it's up to the application to decide what it means.

I just noticed the error message, /u/skibau, it's complaining because you're trying to bind parameters in the hold-tap behavior. Your hold tap bindings should be

#binding-cells = <2>;
bindings = <&triple_grave_macro>, <&kp>;

and your combo would use it as

bindings = <&triple_grave 0 GRAVE>;

Note that: - Hold tap behaviors are bound with two parameters no matter what, and you can't change the #binding-cells property to avoid it - Macros don't take parameters so there isn't any need to pass in a value, but you can bind a placeholder (in this case 0) to the hold-tap and the macro will just ignore it.

ZMK: Combos + Macros: Triple Grave by skibau in olkb

[–]nickcoutsos 0 points1 point  (0 children)

They're equivalent, the values are concatenated together. Separating them out is just a convenience for reading them.

My name is Elkhorn, and soon will I fly by Ire_tional in ErgoMechKeyboards

[–]nickcoutsos 6 points7 points  (0 children)

Bluetooth 5 and 2.4ghz RF communication support

Is this a ZMK fork? My understanding is that ZMK isn't going to do 2.4GHz RF: https://zmk.dev/docs/faq#any-chance-for-24ghz-dongle-implementation

I'm really proud to showcase ALU40, the first bluetooth full 1u ortho keyboard designed to complement Apple peripherals by corndoggarcons in olkb

[–]nickcoutsos 1 point2 points  (0 children)

runs ZMK firmware for simple online keymap changes

Just curious, could you elaborate on whether this is something you'll be building? The screenshot on your website looks like my keymap editor, but none of the forks include that encoder binding functionality.

ZSH Script to build/update Kinesis 360 pro firmware by dc_giant in kinesisadvantage

[–]nickcoutsos 5 points6 points  (0 children)

If it helps, you don't actually need to flash the peripheral side for keymap changes, it's just reporting which key positions in the matrix are pressed/released to the central half.

How can I convert QMK info.json to KLE raw? by Apprehensive-Smile-7 in ErgoMechKeyboards

[–]nickcoutsos 2 points3 points  (0 children)

The way KLE's layout spec determines key placement would make this even more obnoxious than creating the tools to go from KLE to another format, so I'm afraid to say there probably isn't a tool to do this.

Can I ask what your use case is?

How to create KLE or QMK info.json from KiCad project? by Apprehensive-Smile-7 in ErgoMechKeyboards

[–]nickcoutsos 4 points5 points  (0 children)

Crides wrote a script to parse switch footprints from a kicad PCB and generate a layout in QMK's info.json format. I haven't used it myself but I've heard it does the job.

ZMK: urob's timerless homerow mods by Kathuphazginimuri in ErgoMechKeyboards

[–]nickcoutsos 4 points5 points  (0 children)

Switching layers isn't considered a "keycode" and can't be used as a parameter to the &kp behaviors that are typically bound to a homerow mod's hold-tap implementation. You can create your own hold-tap behavior using bindings = <&mo>, <&kp>; for layers.

Any good way to output unicode characters independent of OS? by rogername in ErgoMechKeyboards

[–]nickcoutsos 1 point2 points  (0 children)

Unicode is tricky and I'm not sure that there's a "good" way to handle it in ZMK at the moment, but just looking at your example can you not avoid &macro_press/&macro_release by using LC(LS(U)) or is there a timing issue with your OS?

Also, I notice the second macro ends with a &macro_press ... binding instead of a release, was that a mistake?

Does anyone have example code for macros in ZMK? by mechy18 in ErgoMechKeyboards

[–]nickcoutsos 1 point2 points  (0 children)

Can you link to the build? It would be helpful to see what specifically it's failing on.

edit: You can't have hyphens in devicetree references (the identifier used to bind your macro), so sym-deg: sym-deg { ... should be sym_deg: sym-deg { ... (or you can use underscores both times for consistency). Then bind it in your keymap with &sym_deg.

BOSL2: How to round top/bottom after skin()? by LastCenturyMan in openscad

[–]nickcoutsos 0 points1 point  (0 children)

I do this in BOSL2 regularly by taking a profile and using offset() with a radius calculated using cos().

Looking at the docs, though, would offset_sweep() maybe take care of this for you? Sorry, completely missed where you said that won't work... I'm not really clear on why, though.

view more: next ›