Some DZ60 layouts are obsolete.

[Micro-Biology]

After discussion here, it became apparent the DZ60 layouts need consolidating.

There are multiple layouts that could easily use another layout but with some keys doing nothing, eg the HHKB layouts or layouts with keys that are not split.

I am proposing that the layouts are reduced to:

1. layout_ANSI (currently Layout)
2. layout_ISO (as above but with an ISO enter, in the pull request linked above)
3. layout_ANSI_Arrow (currently LAYOUT_60_b_ANSI)
4. layout_ISO_Arrow (Currently LAYOUT_60_b_ISO)
5. layout_ANSI_2U_Lshift (Layout_all)
6. layout_ISO_2U_Lshift (as above but with ISO enter, currently does not exist)

This has the advantage of all possible layouts being supported whilst reducing the number of layout macros.

This would however cause many/all the DZ60 keymaps to be invalid. I am inexperienced in both qmk and github issues and so would like some advice as to how to go about making these changes.

I have started this with a new branch already.

To do:

• Update dz60.h to only include these 6 layouts.
• Update info.json
• Update all keymap files to use the new layouts (this may be a bit tedious...)
• Update readme to explain changes, and how to make layouts with fewer split keys.

[Micro-Biology]

First 2 changes have been made.

On info.json the legends are not perfect, however I am under the impression as they are just layouts it doesn't matter too much?

[noroadsleft]

The legends in the info.json file do not matter. They're only for people to use when debugging the file.

I'm away for the first part of the day (it's 8 AM here), but this afternoon I can put some commits together to complete Phase 3 (updating the keymaps).

[Micro-Biology]

I'll make a pull request and that way you can see where I am up to, don't want replication of work.

Dz60 layout consolidation #4671

[zvecr]

For people who use config.qmk.fm, this seems like a backwards step. A new user presented with a non matching layout, something like Layout_all, its not obvious which boxes to fill in to get the keymap to work. It relies on an inherit understanding of the PCB schematic.

I added LAYOUT_60_ansi_split for my own keymap, however i know of at least one consumer who also uses that layout with the Configurator.

It seems like the purpose is to improve maintainability, but is this the right way to go about it?

[noroadsleft]

You raise a good point, @zvecr. The need to support Configurator users is not lost on me.

Realistically, I don't know that we're going to be able to strip the layouts down to the six @Micro-Biology has listed, because the Community Layouts feature needs three layouts on its own (and the DZ60 PCB supports others that aren't currently set up in the source code). <edit> And currently, there are 12 layouts in use in the dz60/keymaps folder. </edit>

There are some layouts currently in the source that are just minor tweaks on other layouts. One possible solution I have is to add a default keymap JSON that's a standard 60% ANSI layout, but set to the LAYOUT_all macro, so someone can choose the DZ60 and hit the Load Default button and get something that works. Hopefully that will at least expose what goes where, if a user has extra keys.

[zvecr]

For the Configurator heres some blue sky thinking, its almost like you need to model the options available, and make it a dynamic mapping from user selection to the Layout_all macro. However i understand that mapping the options against which are interdependent would be complicated.

Instead of picking an predefined macro, you would select 2 and 10, and the UI would reflect that suggestion. The user then picks their mapping and the magic translates this to the existing layout. That way its accessible to those who are comfortable with code and those who are not.

[noroadsleft]

For the Configurator heres some blue sky thinking, its almost like you need to model the options available, and make it a dynamic mapping from user selection to the Layout_all macro. However i understand that mapping the options against which are interdependent would be complicated.

That's actually what I'm thinking should be done. In fact, I had half a mind to suggest that be the standard for all boards, because once you figure out the "global" matrix and what positions share locations, you only have to set the matrix once and then point all the layouts at LAYOUT_all.

Instead of picking an predefined macro, you would select 2 and 10, and the UI would reflect that suggestion. The user then picks their mapping and the magic translates this to the existing layout. That way its accessible to those who are comfortable with code and those who are not.

We actually have an issue against the Configurator talking about exactly that, but heck if I can find it right now. But the gist was to figure out a way to tell the Configurator what layout options are available (Split Space/Backspace/Shifts, ANSI/ISO, Standard/Tsangan/Winkeyless, etc.) by nesting JSON objects, similarly to the current structure. Then it's an issue of figuring how to relate them to each other.

[noroadsleft]

@Micro-Biology wasn't sure where to drop this, but:

master...noroadsleft:pull_4671

This incorporates your addition of the LAYOUT_60_c_iso macro, as well as some consolidation of the existing macros. It's branched from 398204b as a base (the live master branch as I write this).

I was able to eliminate LAYOUT_directional by refactoring all the keymaps in the repo that used it. I think I could actually eliminate LAYOUT_60_c_iso, and fork LAYOUT_directional into ANSI and ISO variants. (I don't like either of those names, though.)

The more thought I put into this consolidation exercise, the more I start to think it's actually not a good solution.

As an aside, I'd like for @drashna and @mechmerlin to both weigh in on this, because they're the two people I've had the most discussion with on this topic.

[Micro-Biology]

I didn't think about the configurator tbh, as I have never used it.

Is it possible to use several marcos for one layout? you could have a macro for each row of keys?

[fshek]

I have soldered the DZ60 with this layout (support layout No. 2+3+6). I tried to use Layout_all, Layout, and all ISO layouts to map this key arrangement, but the the last key of row 4 (PgDn in my case) is always not responsive... It feels like the key is not present >.<

I am a beginner of compiling firmware, and hope experts here could provide me some insights...

[Micro-Biology]

How are you programming your board?

• If it is using the configurator, I don't think it is currently possible

• If however you are making your own hex file and flashing, for now you can use my fork of qmk, and edit the iso_fullsplit layout to whatever you want your keys to be.

[fshek]

I am not good at coding and I was using the configurator. Thanks for referring me to your fork. I think I need to boot up my ubuntu, set up the build environment, and try to compile myself during Xmas holiday xDDDD

[noroadsleft]

@fshek This should get you close:

dz60_fshek.json.txt

Save it, remove the .txt, go to Configurator, hit Import Keymap, give it that file. Should get you most of the way there.

The LT() you have next to right Alt, I have it as a MO(1) (same as left Windows key position), because I couldn't tell from your image what function you wanted on the LT().

[fshek]

Wow... Thank you very much. Will try your JSON file when I get back home tonight.

I have a special attempt on lower right hand side:

| PgUp | RSFT_T(kc_up) | PgDn |
| LT(1, kc_left) | RGUI_T(kc_down) | RCTL_T(kc_right) |

Tap will be Up, Dn, Left, Right
Hold will be Shift, OS, Fn & Ctrl

I have tried this with "Layout_all" in the Configurator, and it is very handy for navigation. But the "PgDn" key assignment is not working on Configurator, that's why I throw out my question here.

Hopefully I have some luck tonight with your JSON. Cheers

[noroadsleft]

Your Shift/Up, GUI/Down and Ctrl/Right, are all directly supported in the Configurator, just drag the dual function keys where they go after loading the JSON, and then drag the tap functions (Up, Down and Right) onto the small boxes that appear on the keys. You'll see what I mean once you get to it. They're all under the "Mod key combinations" section.

For the LT(1, KC_LEFT), drag the ANY key from the "QMK specific" section, and then type/paste LT(1, KC_LEFT) into the text box. It's a text input field like the MO() is.

I don't any reason on the QMK end why your Page Down key wouldn't work. That layout hasn't been changed in over three months, and it was confirmed as working at the time. I'm leaning toward that being a hardware issue on your end - bad switch, bad solder job, something like that.

[fshek]

I have done a number of tests...

PgUp is physically soldered in 12th location and PgDn is 14th location

When using LAYOUT_60_b_iso, both 12th (12th in key map) and 14th (14th in key map) keys are inactive.

When using LAYOUT_all, only 14th key (15th in key map) is gone. PgUp and Shift are working.

I assume LAYOUT_all should support maximum number of keys and should accommodate literally everything, but it does not turn out as expected.

Because the physical location of 12th key does not change but it has different behavior under 2 layouts, it drives me to think that it may be firmware issue.

You are right that it could be H/W or soldering issue. Just wanna test all possible HEX before trouble shooting the H/W.

[noroadsleft]

Well, there are keymaps in the repo that use both those switch positions and zero issues have been reported there. One of the QMK Collaborators actually uses LAYOUT_60_b_ansi on his DZ60, and he would definitely report if there were a problem. This is why I'm fairly sure this is a hardware issue.

The key you have as Page Up is on the 12th column (electrically) in LAYOUT_all, and the 13th column in LAYOUT_60_b_iso and _ansi. It working on one spot and not the other definitely points me to hardware.

Have you tried physically swapping the switches to each other's places? You might be dealing with two different issues? (Forgive me if I'm telling you stuff you know; I'm trying to explore all avenues.)

[fshek]

will check the switch and solder accordingly. Thanks for your help ;-)

[stale]

This issue has been automatically marked as resolved because it has not had activity in the last 90 days. It will be closed in the next 30 days unless it is tagged properly or other activity occurs.