Add keyboard Lily58 Koca

[Hardware7253]

Description

Add keyboard Lily58 Koca to the keyboards folder. This is placed in a seperate folder to the other Lily58's because I am not the original maintainer.

Types of Changes

• Core
• Bugfix
• New feature
• Enhancement/optimization
• Keyboard (addition or update)
• Keymap/layout (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).

[filterpaper]

Can you consider not using the lily58 prefix name? Duplicating names of popular boards will oftentimes lead users to an incorrect firmware and generate unnecessary support questions on the QMK Discord server.

[Hardware7253]

Can you consider not using the lily58 prefix name? Duplicating names of popular boards will oftentimes lead users to an incorrect firmware and generate unnecessary support questions on the QMK Discord server.

The name is sort of set in stone having been already printed on circuit boards. Instead I'll compromise and add something to the readme redirecting users of the original Lily58 and it's various versions.

[filterpaper]

Can you consider not using the lily58 prefix name? Duplicating names of popular boards will oftentimes lead users to an incorrect firmware and generate unnecessary support questions on the QMK Discord server.

The name is sort of set in stone having been already printed on circuit boards. Instead I'll compromise and add something to the readme redirecting users of the original Lily58 and it's various versions.

QMK readme is not the first reference point for users unfortunately. A prominent firmware guide about these duplicate names on vendor(s) product pages will be more useful.

[Hardware7253]

Can you consider not using the lily58 prefix name? Duplicating names of popular boards will oftentimes lead users to an incorrect firmware and generate unnecessary support questions on the QMK Discord server.

The name is sort of set in stone having been already printed on circuit boards. Instead I'll compromise and add something to the readme redirecting users of the original Lily58 and it's various versions.

QMK readme is not the first reference point for users unfortunately. A prominent firmware guide about these duplicate names on vendor(s) product pages will be more useful.

I did add something to readme but I think you're right, users will definitely not read it and wonder why the firmware wont upload. I'll change the directory name to koca. It'll be slightly more confusing for users of my design but save original Lily58 users some trouble.

[filterpaper]

It'll be slightly more confusing for users of my design but save original Lily58 users some trouble.

Such user confusion happens both ways based on support questions in Discord—vendor board users trying to use the open source version and vice versa.

[Hardware7253]

It'll be slightly more confusing for users of my design but save original Lily58 users some trouble.

Such user confusion happens both ways based on support questions in Discord—vendor board users trying to use the open source version and vice versa.

I've seen this comment sitting for a while. Is there anything else I can do to prevent users from trying to flash the wrong firmware though? I really don't think original Lily58 users will stumble across this firmware in the QMK repo due to it's new name. On my side I can make sure my vendor directs my users to the koca firwmare.

Or are you suggesting that I change the name entirely so that it has nothing to do with the Lily58?

[drashna]

This is .... unfortunate. A direct pin matrix would have been better here (and faster), and wouldn't have needed the C12 pin (just ground).

[Hardware7253]

Yeah. I have no idea how this oversight made it so far. I'm keeping it at this point so my v1 PCBs will work.

[sigprof]

You may be able to declare the matrix as direct pin, and then initialize the C12 pin to output low in matrix_init_kb():

void matrix_init_kb(void) {
    // Activate the only row pin so that the matrix can be handled as direct pins.
    gpio_set_pin_output(C12);
    gpio_write_pin_low(C12);

    matrix_init_user();
}

In the V2 PCB you can just leave the C12 pin unconnected and keep the rest of pin assignments the same, so that the firmware would be compatible with both PCB versions.

[Hardware7253]

Good idea, I'll start testing this now.

[Hardware7253]

You may be able to declare the matrix as direct pin, and then initialize the C12 pin to output low in matrix_init_kb():

void matrix_init_kb(void) {
    // Activate the only row pin so that the matrix can be handled as direct pins.
    gpio_set_pin_output(C12);
    gpio_write_pin_low(C12);

    matrix_init_user();
}

In the V2 PCB you can just leave the C12 pin unconnected and keep the rest of pin assignments the same, so that the firmware would be compatible with both PCB versions.

I ended up switching entirely to a direct matrix and will change the PCB. Users will never get my first PCB, I just ordered 5 for prototyping.

[Hardware7253]

It's been a little while since the switch to a proper direct matrix. Would someone consider reviewing this please?

[Hardware7253]

Would somebody mind reviewing this? I've addressed all previous issues.