Durgod keyboard refactor in preparation for adding additional durgod keyboards

[dkjer]

In preparation for adding additional Durgod keyboards, performing some clean up:

• Moving Durgod board configuration into a common location
• Reformatting layout macro whitespace
• Moving TGUI key functionality to the keyboard level
• Replacing default keymap.c with keymap.json
• Changing default and default_toggle_mac_windows keymaps to LAYOUT_all
• Increasing EEPROM size to support more VIA layers
• Fixing media keys; KC_MRWD/KC_MFFD => KC_MPRV/KC_NXT
• Fixing KC_ENT position on LAYOUT_tkl_iso

Description

Types of Changes

• Core
• Bugfix
• New feature
• Enhancement/optimization
• Keyboard (addition or update)
• Keymap/layout/userspace (addition or update)
• Documentation

Issues Fixed or Closed by This PR

Checklist

• My code follows the code style of this project: C, Python
• I have read the PR Checklist document and have made the appropriate changes.
• My change requires a change to the documentation.
• I have updated the documentation accordingly.
• I have read the CONTRIBUTING document.
• I have added tests to cover my changes.
• I have tested the changes and verified that they work and don't break anything (as well as I can manage).

[mcoirault]

I was able to build and flash the via keymap on my K320 ISO. Works like a charm with all 4 layers. I'm glad you know your way around memory much better than I do.

Feel free to reach out if you need to test stuff on the K320 ISO hardware.

[dkjer]

Thank you @mcoirault, glad to hear the via keymap still works! Could you test that the new default keymap based on LAYOUT_all works correctly on your iso k320? It works for me on my ansi k320.

@AlCutter, @nomis, @mcoirault Regarding the default_iso and default_iso_mac layouts; are these still needed if we switch default to LAYOUT_all and create a default_mac based on LAYOUT_all?

[mcoirault]

@dkjer default works properly on iso k320, including the winlock functionality and its led (I'm typing this with durgod/k320:default).

Regarding default_iso and default_iso_mac, these seem to use the same matrix/keymap (minus the KC_BSLS). Redundant now that default supports both ISO and ANSI.

[nomis]

This is using KC_MRWD and KC_MFFD when the keys should be KC_MPRV and KC_MNXT to match the original firmware.

[dkjer]

This is using KC_MRWD and KC_MFFD when the keys should be KC_MPRV and KC_MNXT to match the original firmware.

Thanks @nomis ; PR updated.

Regarding default_iso and default_iso_mac, these seem to use the same matrix/keymap (minus the KC_BSLS). Redundant now that default supports both ISO and ANSI.

Thanks for checking @mcoirault . @AlCutter I have removed the default_iso keymap in favor of a single LAYOUT_all default that supports both ansi and iso. I also moved default_iso_mac to default_mac and based it on LAYOUT_all. If someone has some time to sanity check that default_mac works on an ISO keyboard that would be great.

[tzarc]

Sorry about that, GitHub decided to delete the develop branch from upstream when we merged it, despite being told otherwise. Reopened.

[nomis]

I think KC_ENT is in the wrong place for the tkl_iso layout?

According to layouts/default/tkl_iso/default_tkl_iso/keymap.c it should be in row 4, not row 3.

[tylert]

I'll be eagerly-awaiting this PR to get merged before I post the Durgod Taurus K310 non-backlit stuff currently located at https://github.com/tylert/qmk_firmware/tree/durgod_k310.

Having just spent nearly two whole days tracing both a K320 ANSI keyboard and a K310 ANSI keyboard side-by-side, I'm reasonably confident we could combine the non-backlit K310 and the non-backlit K320 work into a single "keyboard".

I'm going to try out a K310 firmware on a K320 board when I get a chance. Anybody with a K310 ISO keyboard willing to test a load for me?

[dkjer]

I think KC_ENT is in the wrong place for the tkl_iso layout?

According to layouts/default/tkl_iso/default_tkl_iso/keymap.c it should be in row 4, not row 3.

@nomis I'm not sure which KC_ENT you are referring to? It looks like KC_ENT is immediately to the right of KC_NUHS, and just above KC_RSFT in the default and default_mac layouts. Is that not the correct iso position?

[dkjer]

Having just spent nearly two whole days tracing both a K320 ANSI keyboard and a K310 ANSI keyboard side-by-side, I'm reasonably confident we could combine the non-backlit K310 and the non-backlit K320 work into a single "keyboard".

@tylert I was just thinking the same thing, after seeing your changes. We could rename this keyboard durgod/k3x0, but that might break things for folks already using the k320.

I think having a separate durgod/k310 is probably easiest from a user standpoint, even though it means duplicating code in a few files. Not sure if @tzarc or other QMK devs have a suggestion here on what the cleanest path would be?

[nomis]

I think KC_ENT is in the wrong place for the tkl_iso layout?
According to layouts/default/tkl_iso/default_tkl_iso/keymap.c it should be in row 4, not row 3.

@nomis I'm not sure which KC_ENT you are referring to? It looks like KC_ENT is immediately to the right of KC_NUHS, and just above KC_RSFT in the default and default_mac layouts. Is that not the correct iso position?

The key spans two physical rows. It can only be in one row in the #define but it's currently in the wrong one.

[tylert]

The ANSI Durgod keyboards I've looked at so far (two K310 boards and four K320 boards) all have holes for both the ANSI and ISO variants so I'm pretty sure they'd both use the same PCB. The 2 alternate holes for Enter on the PCB are electrically-connected on both switch pins meaning you could insert a switch at either the ANSI location or the ISO one. Regardless, the switch must sit at position K4E (Enter; row 5, column 15) in the matrix in order for it to be connected to the microcontroller correctly--right between K4F (Up; row 5, column 16) and K4D (Right Shift; row 5, column 14).

Seems like @mcoirault also has an ISO keyboard so perhaps they would be willing to test again with the latest HEAD of this branch.

I'm going to check some other examples of ISO Enter keys in the other keyboards to confirm though for the physical layouts. I suspect all the height: 2 keys need to start on the higher row.

[nomis]

I am not debating the physical position of the key or where it is in in the matrix.

For the LAYOUT_tkl_iso macro to be of any use across keyboards it must have all the keys in the same order on all keyboards.

I've made a PR to fix this: dkjer#2

[dkjer]

@nomis Ah, you meant the LAYOUT_tkl_iso macro; I hadn't really inspected that. I have included your fix PR into this PR, thank you.

@tylert I also included your whitespace fixes

Thanks folks!

[nomis]

We could rename this keyboard durgod/k3x0, but that might break things for folks already using the k320.

The k310 is full size so they're not the same keyboard.

You're making an assumption that there will never be a k300, k330, k340, etc. with different behaviour.

Yes there may be ways to share files between the two keyboards but they are not a "k3x0" model.

[tguinan]

Any chance of backlight support for the k320? The regular version of the board has solder points for LEDs, so I've always assumed that it used the same PCB as the corona variant, just with different firmware. It'd be great to have those enabled at some point

[nomis]

I think the stock firmware is actually the same on the backlight version because the key presses for increasing/decreasing the brightness work because it flashes all the status LEDs when you reach the minimum/maximum.

There's an unpopulated "U3" chip header on my board along with some capacitors and resistors that might be required for the backlight?

[tguinan]

I think the stock firmware is actually the same on the backlight version because the key presses for increasing/decreasing the brightness work because it flashes all the status LEDs when you reach the minimum/maximum.

There's an unpopulated "U3" chip header on my board along with some capacitors and resistors that might be required for the backlight?

Ah, you might be right. It's right underneath that thin plastic card in most teardown pics that I could find so I didn't notice it

[tylert]

I was thinking at the time that the unpopulated U3 chip might be a serial EEPROM or some additional flash. The traces are connected to a few of the B3-B7 or C0-C3 pins. Unfortunately, I didn't write down which pins these were as this wasn't a priority for me on the weekend. I might be convinced to open up one of my K320s again if folks want help confirming how similar the non-backlit K320 is to a backlit K320 by having me trace any additional data pins on the STM32F070 that aren't used for the key matrix or LEDs.

Edit: I only have non-backlit boards at the moment.

In case it helps others, all the pins that I did trace on the K310/K320 non-backlit boards I captured in a "ditaa" diagram at https://github.com/tylert/tylert.github.io/blob/master/source/hardware_stuff/schematic_durgod_k3x0_keyboard.txt (use "ditaa -r foo.txt -o foo.png" to turn it into a bitmap). The pin numbers are listed in the document at https://www.st.com/resource/en/datasheet/stm32f070c6.pdf (page 24, the LQFP64 package). Technically, the config.h file already contains most of this info for the K320 but I find the schematic a bit easier to visualize.

After this PR gets merged, I'm going to put my https://github.com/tylert/qmk_firmware/tree/durgod_k310 PR up which should have all the recommended changes made by @nomis for ISO support (Canada is stuck with ANSI boards). I've only done the bare essential keymaps "default" and "via" initially just to keep my first PR smaller... and my only K310 "customer" says she doesn't care about all those fancy-schmancy programmable features... yet :)

[nomis]

@dkjer is there a reason why DEBOUNCE is set to 7ms? The default (and most other keyboards) have this set to 5.

I've changed it to 0 and haven't noticed any problems yet, but that might not work for everyone.

I've also set USB_POLLING_INTERVAL_MS to 1. This is marketed as a 1000Hz polling rate keyboard, although I'm only getting around 620Hz matrix scan rate.

[dkjer]

@nomis No particular reason it was set to 7ms DEBOUNCE as far as I know; that was the setting used in the original PR to add K320 support. I would be ok with defaulting that back to 5.

Perhaps we should have an e-mail or discord discussion for non-PR related questions? As far as I can tell, this PR is ready to be merged, and the questions posed here are more about future incoming changes, or general tweaks to configuration.

[dkjer]

Rebased after pulling develop branch