qmk-rgb/definitions

Definitions

The VIA definition files built into the binary. embed.go embeds every JSON file in this directory, so that go install delivers them: it copies a binary and creates no data directory, and a board VIA does not carry cannot be fetched.

This is not the directory the tool reads at runtime. That is the per-user definitions/ directory the top-level README names; keyboard fetch writes there, and a file placed there — or passed with --definition — takes precedence over the one built in. To use or correct a definition, put it there, not here.

keyboard fetch does not replace a file that is already in the per-user directory, because that file may be one you have edited and nothing on disk says which it is. It refuses and names the file; --force overwrites. A board's file is recognised by the vendorId/productId it carries, so the check follows a renamed file too, and --force removes the file it replaced rather than leaving two files for one board.

What belongs here

A board's file, only when VIA's own collection does not carry that board, kept as the vendor serves it. A file is matched to a board by the vendorId/productId it carries, so only the .json extension matters, not the name — but it must be that extension in lowercase, because both this directory's embed pattern and the loader that reads it skip anything else. A file added here takes effect after a rebuild.

The files here

Every file here comes from the vendor's own product wiki, which publishes a VIA JSON per model and per connection mode. The names here are the names the vendor serves, so a file can be compared against what the page offers; only the extension was changed, because this directory's embed pattern and the loader both match .json and nothing else.

File	Board	Mode	From
impact80.json	Impact 80	—	Driver & Firmware
Aurora80-RGB.json	PMOKEY Aurora 80	wired	Driver & Firmware
WAVE75wiredonlyRGB.json	PMOKEY Wave 75	wired	Driver & Firmware
ZEN65-RGB.json	ZEN 65	wired	Driver & Firmware
pmo_p75_gaming_keyboard.json	PMOKEY P75	wired	Driver & Firmware
pmo_p75_gaming_keyboard_2p4g.json	PMOKEY P75	2.4G	the same page
Rainy-75-RGB-USB-3.0.json	Rainy 75 RGB	wired	Driver & Firmware
Rainy-75-RGB-2.4G-3.0.json	Rainy 75 RGB	2.4G	the same page
Crush 80 RGB-USB.json	Crush 80 RGB	wired	Driver & Firmware
Crush 80 RGB-2.4G.json	Crush 80 RGB	2.4G	the same page

Those pages carry more files than are here: the Rainy 75 page also has Non-RGB (Lite), DE/UK-ISO and JIS, and the Crush 80 page a Non-RGB pair. A board in one of those modes has no definition at all — lookup matches vendorId and productId, so no file of another mode stands in for it. Such a board is still driven, through raw effect IDs, and keyboard info reports "effects": false for it.

Crush 80 and Rainy 75 share their USB IDs

The vendor issues the same pair of IDs to two different boards:

	wired	2.4G
Rainy 75 RGB	0x320F/0x5055	0x320F/0x5088
Crush 80 RGB	0x320F/0x5055	0x320F/0x5088

Nothing in the USB descriptor tells them apart, so a definition lookup cannot either. Both files for a pair are kept because the vendor publishes both, and FindDefinition takes the first match in the order LoadDefinitionsFS returns, which is sorted by path — Crush 80 RGB-USB.json sorts before Rainy-75-RGB-USB-3.0.json, so a Rainy 75 is reported as a Crush 80. The two catalogs happen to name the same 19 effects at the same IDs, so the effect names are right either way and only the reported model name is wrong. Renaming one file is all it takes to change which board wins.