Tecware Phantom RGB TKL- Keymapping doesn't seem to work.

[rootexpression]

If you accept the risk of permanent damage to the keyboard, type YES and press enter to continue.
Anything else will cancel this process.
At this point the keyboard is completely non-responsive, so I used another keyboard to enter "YES" and hit enter.
After that the keyboard works as normal, without any remapping of the keys.

I'm trying to swap the menu key out for a key in the F13-F24 range (I need a key for push-to-talk that doesn't conflict with anything else, so modifiers are a no-go) so I ran a custom.keymap with this in it:
[keymap]
menu=f13

Not sure if I'm doing something wrong, if it is confused by the second keyboard (issue happened with or without, I just couldn't type anything without it), or if its just not compatible with this model.

Edit:
I tried the config using the case sensitive names originally, and then moved to lowercase to see if it was case-sensitive. The above is the last variation I tried.

[dokutan]

I just tried it with my own Tecware Phantom TKL (ANSI layout), and the following works without any problems:

[keymap]
Menu=F13

There a few things i'd like to confirm:

1. What layout does your keyboard have?
2. I assume that after typing YES no further output occured.
3. If the above doesn't work for you, could you please post your config as a file.

[rootexpression]

Mine is also an ANSI layout.
I renamed the config to .txt because github didn't care for custom.keymap
custom.keymap.txt
I based it off the example config, and gutted all the comments just in case since starting trying things.

Edit: and you are correct, after typing YES there was no further output.

[dokutan]

I'm honestly pretty confused, i thought that maybe your config contained some form of control characters (e.g. weird line endings). But that is not the case, additionally i can run rgb_keyboard -M custom.keymap.txt and it works just fine. To make certain that github wasn't changing the file somehow, here is the sha256sum of the file i downloaded: aa00bb253f77bdde4b607ef9d51323e2a597bbe2474332a2431b5518f0c13086.

The other reasons i could think of are a different firmware version, does remapping any other buttons work? And to make sure that you are building from the latest git commit, try

git pull
git log | head -n1 # should output: commit e49492e68125e252eccb55390041d78694612266
make clean
make
sudo make install
rgb_keyboard -M custom.keymap

[rootexpression]

The hash you listed there matches custom.keymap without the .txt I'd added for github's benefit.
I'd been using what was in AUR but I did grab it from the repo myself and give that a run just in case.
So far, no other keys have taken to a remapping.

A difference in firmware seems a possible candidate. I wouldn't know how to confirm that outside of sniffing the commands sent from a working key remapping solution.

[dokutan]

Considering all of these details i would strongly assume that the different firmware is to blame. This opens a new question, have you tried any other features (changing profiles and led related settings) and what were the results?

I wouldn't know how to confirm that outside of sniffing the commands sent from a working key remapping solution.

Indeed that is the most (only?) practical way of getting the required information to confirm a different firmware and add support.
Here is a brief explanation of the process if you are interested. I think it would be best to individually capture the remapping of a few keys (and note the physical keys and mappings) to test if at least the keycodes are identical, if not that would have to be repeated for every key.

[rootexpression]

I think I played with the macros side when it was a separate program.
I use this for my RGB profiles and have had zero issues. Switches profiles and creates them just fine.

I've used the interface0 option to create animated profiles as well for notification, which I stopped doing when I took a moment to consider that it was probably wearing out the flash storage and maybe not such a good idea.

I doubt this is a rgb_keyboard quirk, I think its just a poor LED quality or imbalanced RGB handling in the firmware thing, but it struggles to replicate certain colors like yellow, which always has a green tint.. It has a green tint if I remove green all the way up until it shifts toward orange.

The RGB thing is the closest thing I've found to a "bug" (and again, I think its just the keyboard being a low dollar item with limitations of imperfect parts), aside from not being able to modify the keymap.

I just tried it on another machine and I get the same result there.

I used the software Techware ships (its a rebranded old version of some GMMK software if I remember right) way way back but I don't remember it offering remapping, just a terrible macro feature. That software allows remapping? Or would I need something else for that?

[dokutan]

I used the software Techware ships (its a rebranded old version of some GMMK software if I remember right) way way back but I don't remember it offering remapping, just a terrible macro feature. That software allows remapping? Or would I need something else for that?

Yes, remapping is possible with the Tecware software, there are multiple versions for different layouts, because apparently it was too difficult to implement getting the layout from the keyboard, you need the correct one or wrong keys get remapped. Indeed it is basically identical with the GMMK software (only different branding), it is even possible to use the Tecware keyboard with the GMMK software and vice-versa.

On the version i have installed, click on "disabled" below "led editing mode" and then the key you want to remap to open a menu.