[jogme]

Thanks!

Good point for the splay. For some reason I didn't consider it, but looking at it rn I could put a some of the keys in an angle which would feel better. I'll consider it for the next release (or a different version)!

I have nothing against 36 keys layout, the only reason for eliminating 2 thumb keys is that I can't find a proper place for the third thumb key where it would be in a nice position. I could add one key at the inner side, but the thumb just goes below the palm and it is not a comfortable position (for me at least). If you have any suggestions, please let me know! There is always space for improvement.

The lateral pinky position wasn't on the first design, but then someone with a shorter pinky who couldn't comfortably reach the top key tried it and suggested to place it there. I tried it and actually felt a lot better. (to reach the top pinky key I need to make a wrist movement, but not like this). I love it.

[jhardy54]

Honestly I’ve never tried a 34-key layout, though I’ve seen loads in the keyboard layout DB. Are you using something like Seniply?

Also in case it’s useful: much ink has been spilled about TRRS and its alternatives, but I haven’t found any references to folks using an I2C connector (4-pin JST) instead, which eliminates hotplugging risk without introducing the risks of USB/etc.

I purchased a KB2040 (which has a female I2C connector), a 400mm male-to-male I2C cable, and an I2C GPIO expander, which is slightly cheaper than a second RP2040 on the second hand (though a second KB2040 is cheap anyway). I’m optimistic about using I2C and avoiding TRRS, but wanted to highlight it as an option since I hadn’t seen it mentioned anywhere else.

[jogme]

If you are interested you can always try it out on your current kb, right?

> Seniply Yes, the idea is the same. I'm using Base layer + 3 other and using one shot for the function keys. Tap dance wouldn't be a problem either, I just prefer one shot.

> trrs cable Interesting idea. Why would you like to avoid TRRS? What are the issues with it? I am thinking for the next version some BLE between the sides as it has low latency, but it's a mere idea for now and more research is needed. (also it would be for a wireless version as it would need batteries anyway)

[jhardy54]

Yep, I can just avoid using one of the keys, I just haven’t seen many key maps with the sort of popularity that Miryoku has, and I hate the analysis paralysis of trying to decide between 10 comparable keymaps (or trying to build my own from scratch).

The issue with TRRS is that you can easily damage your controller(s?) if they’re powered while the TRRS cable is either unplugged or left in a “not quite 100% plugged in” state, as the metal contacts in the connector create a short (between data and power IIRC?) when mid-way plugged in.

I recently fried a controller this way because I didn’t realize that the TRRS connector had gotten slightly yanked and was ~90% plugged in, creating a short, and the controller has been busted since.

In general the advice is “never plug/unplug TRRS while your keyboard is powered” and “always check to make sure TRRS is fully seated”, but in practice it’s easy to make a mistake that requires replacing your controller (and desoldering it if you didn’t socket it, oops).

[jogme]

I like the T-34 layout[0] - I like how much 'science' (research) did he put in it. An another one is the callum layout[1].

There is an option with QMK to rediscover TRRS cable when it gets disconnected or is plugged after startup, but I see now that that's not the only problem. TRRS is an easy/cheap solution, but a dangerous one if not correct.

[0] - https://www.jonashietala.se/blog/2021/06/03/the-t-34-keyboar... [1] - https://github.com/callum-oakley/qmk_firmware/tree/master/us...