* Somei70 addition
* Changes made, added VIA keymap, cleaned formatting
* keymap via
* Create rules.mk
* Add files via upload
* Delete keyboards/somei70/keymaps/via directory
* Fixed RGB and matrix
* Layout corrections and LED positions
* removal of rules.mk
* Moved OLED Settings to somei70.c, formatted C removed TABs, removed _LAYERC
* Forgot to include license header
* Further changes as per suggestions, replaced _user for _kb within somei70.c
* Updated keymap 'changes in Nov24'
* Requested changes
* Add Reverie to QMK
* Add backlight to reverie
* Update reverie readme and copyright notices
* Use format json to update keyboard.json formatting
* Update to have solderable and hotswap variants split
* Update copyright noticeS
* JSON formatting updates
* inherit config.h
* fix broken keymap
* Update reverie hs keyboard.json to be accurate
* Update keyboards/cannonkeys/reverie/hotswap/keyboard.json
Co-authored-by: jack <jack@pngu.org>
* Remove VIA keymaps
* Update keymap
---------
Co-authored-by: jack <jack@pngu.org>
A small refactoring of the defines TIMER_DIFF_8, TIMER_DIFF_16, TIMER_DIFF_32, TIMER_DIFF_RAW.
Removing obsolete TIMER_DIFF helper.
Discussion: https://github.com/qmk/qmk_firmware/issues/24652
chibios: usb_main: remove OTG sof workaround
With the update of ChibiOS and ChibiOS-Contrib containing fixes for the
OTGv1 LLD the workaround is not necessarry anymore.
Signed-off-by: Stefan Kerkmann <karlk90@pm.me>
* Added VT-40 keyboard
* Remove commented out code. Oops
Co-authored-by: jack <jack@pngu.org>
* Change name of planck_layers to layers.
Co-authored-by: jack <jack@pngu.org>
* Update keyboards/vt40/keymaps/default/keymap.c
Co-authored-by: jack <jack@pngu.org>
* Removed unused features that I stole from the contra config
* Removed unused features that I stole from the contra config
* fixed lower/raise keys
* make adjust layer accessible
* Added adjust key for real this time
* Update keyboards/vt40/keyboard.json
Co-authored-by: Duncan Sutherland <dunk2k_2000@hotmail.com>
---------
Co-authored-by: jack <jack@pngu.org>
Co-authored-by: Duncan Sutherland <dunk2k_2000@hotmail.com>
* Update keymap.c
enhancement - power down indicator LEDs when host sleeps
* Update keyboards/lostdotfish/rp2040_orbweaver/keymaps/default/keymap.c
Co-authored-by: jack <jack@pngu.org>
* Update keyboards/lostdotfish/rp2040_orbweaver/keymaps/default/keymap.c
Co-authored-by: jack <jack@pngu.org>
---------
Co-authored-by: jack <jack@pngu.org>
* This is a configuration of QMK intended to be used with the [ctrl-M controller](https://github.com/nuess0r/ctrl-M).
* Move USB_MAX_POWER_CONSUMPTION to data driven due to upstream change
* Clean up according to PR checklist
Check the keymaps/nuess0r how you can make better use of your Model M
including Windows, multimedia keys etc.
* Move CAPS_HOLD feature from default build to custom keymap
* More data driven configuration
Move layout definition from ctrl_m.h to info.json
Move has_ghost to info.json -> this makes the config.h file obsolete
* Implement changes suggested by review
* Removing user keymap (nuess0r) to follow current guidelines
The nuess0r keymap which is shipped with the ctrl-M controller is kept here:
https://github.com/nuess0r/qmk_firmware/tree/nuess0r_keymap
* Changed image hosting location to Github
requested in review by drashna
* Changed image hosting location to imgur
* Settings removed from info.json that are disabled by default.
* Change URL as suggested by @dunk2k
Not pointing to the QMK firmware but to the replacement controller electronics
project.
* Migrate build target markers to keyboard.json
* Adding tindie link and implement review suggestions
* Removing via keymap to follow current guidelines
Will be moved to the https://github.com/the-via/qmk_userspace_via repo.
* Add LAYOUT_all to support ANSI and ISO keyboards with the same firmware
Add a LAYOUT_all similar to other keyboards that defines all available keys.
Change the default keymap to use the _all layout so both ANSI and ISO Model M
variants work out of the box.
* Remove unnecessary enum from default keymap
Co-authored-by: Less/Rikki <86894501+lesshonor@users.noreply.github.com>
---------
Co-authored-by: Less/Rikki <86894501+lesshonor@users.noreply.github.com>
* adding keymaps for krado industries
* Modified default keymap.c files to be the same as via.
* Changing vendor ID for Krado Industries
* Suggested changes made
Making changes suggested by zvecr.
Removed dynamic_layer indicator, updated copyright year, deleted unused layers in keymaps.
Co-authored-by: Joel Challis <git@zvecr.com>
* rgbpin for ws2812 changed in info.json
* Added encoder mapping rule file for default keymaps; added Fn layer shortcuts to Promenade layouts
* Added rules.mk with encoder mapping for encoder boards at keymaps level.
* Deleted extra key in LAYOUT
* Update keyboards/kradoindustries/kousa/rules.mk
Move WS2812 Driver from rules.mk to info.json
Co-authored-by: jack <jack@pngu.org>
* Update keyboards/kradoindustries/kousa/info.json
Move WS2812 Driver from rules.mk to info.json
Co-authored-by: jack <jack@pngu.org>
* Update keyboards/kradoindustries/kousa/keymaps/default/keymap.c
Move WS2812 Driver from rules.mk to info.json
Co-authored-by: jack <jack@pngu.org>
* Reverting settings.json
* Encoder map code change [2]>[NUM_DIRECTIONS]
* Adding Promenade RP24S
Adding Promenade RP24S keyboard.json, default keymap, and readme
* Adding layer access to Promenade RP24S
Adding layer access to layers 1 and 2
---------
Co-authored-by: Joel Challis <git@zvecr.com>
Co-authored-by: jack <jack@pngu.org>
* Add Cerberus to QMK
* Update readme to add hotswap callouts
* Update readme formatting
* Use format json to update keyboard.json formatting
* Split Cerberus HS and Solderable into separate folders
* Update JSON formatting
* make solderable keymaps a bit more useful
* Backlight fix on solderable
* Update keyboards/cannonkeys/cerberus/hotswap/keyboard.json
Co-authored-by: jack <jack@pngu.org>
* Remove cerberus VIA keymaps
* Apply suggestions from code review
Change some whitespace
Co-authored-by: Drashna Jaelre <drashna@live.com>
* Add RGB control keycodes to cerberus keymap
* Add backlight controls to default keymap on solderable version
* Update keyboards/cannonkeys/cerberus/readme.md
---------
Co-authored-by: jack <jack@pngu.org>
Co-authored-by: Drashna Jaelre <drashna@live.com>
* Add Binepad BNK8 keyboard
* Moved keymap.c to keymap.json
* Fix product page URL
* RGB_ -> RM_ keycodes after this round of breaking changes
Co-authored-by: Ryan <fauxpark@gmail.com>
---------
Co-authored-by: Ryan <fauxpark@gmail.com>
Corrected a typo in the phrase "iOS device need lessthan 100" to "iOS devices need less than 100."
This was to improve clarity and professionalism of the doc.
QMK Firmware has seen its fair share of license violations, which hurts the community and frustrates the QMK maintainers.
Typical non-compliance includes:
* Not providing any source code
* Providing "crippled" source code, such as a wired-only firmware for a wireless-capable board
Boards from vendors who don't provide source code are proving to be a significant time sink as the QMK team and other support helpers volunteer their time trying to determine which board someone has before they can help -- and in these cases they can't help. Occasionally this is followed by abuse; something that QMK and its volunteers should not be subjected to, rather redirected to the vendor in question.
The QMK team now actively directs support requests back to each vendor - vendors must provide their own product support for their boards. The QMK team are volunteers, the vendor must not expect the team to act as their support staff.
## Offending Vendors
The QMK team cannot tell you which boards you should or should not purchase, but please consider the lack of license compliance from the following vendors before making your decision. If you wish to look at the boards upstream QMK Firmware currently supports, you can search [here](https://browse.qmk.fm/).
If you own a board from one of the following vendors already, consider asking them for the equivalent QMK source code if it's not already available. With enough customers demanding corresponding source code, vendors may start to change their policies.
| BBB Keyboard | Selling tri-mode boards based on QMK without sources, attempted upstreaming crippled firmware without wireless. |
| Chillkey | |
| CIDOO | Selling wired boards based on QMK without sources, just `via.json` provided. |
| Darmoshark | Selling wired boards based on QMK without sources, just `via.json` provided. |
| Epomaker | Lots of historical keyboards with `via.json` but no corresponding sources. Wireless code for a small handful provided, pending core cleanup for QMK upstreaming. Most other boards have source nowhere to be seen. |
| Ergokbd (IFKB) | At least their crkbd clone ships with QMK+Vial, seemingly refuses to disclose sources despite multiple customers requesting them. |
| iLovBee | Official 30-day copyright source code request issued Sep 11 2024 due to deception on PR, no response received. Ambiguity on PRs -- marketing says wireless, PR author said wired-only, then included wireless code anyway. Seemingly intentionally deceptive. |
| KiiBOOM | Seems to use the same OEM as Epomaker, same problems. |
| Luminkey | Selling tri-mode boards based on QMK without sources, just `via.json` provided. |
| Meletrix | Selling tri-mode boards based on QMK without sources, just `via.json` provided. |
| mmd / Smartmmd / i-game.tech | Ambiguity on PRs -- marketing says wireless, PR author said wired-only, then included wireless code anyway. Seemingly intentionally deceptive. |
| MyKeyClub | Community-supported JRIS75, vendor was contacted by community members and refused to cooperate. |
| owlab | Selling wired based on QMK without sources, just `via.json` provided. Ambiguous as to whether or not wireless firmware is based on QMK, given that their configuration tool looks very similar to VIA. |
| qwertykeys | Selling wired and tri-mode boards based on QMK without sources, just `via.json` provided. |
| Redragon | Selling tri-mode boards based on QMK without sources, attempted upstreaming crippled firmware without wireless. |
| Royal Kludge | PRs for fake boards in order to attain VIA compatibility identified. Lots of other keyboards with `via.json` but no corresponding sources, attempted upstreaming crippled firmware without wireless. Wireless code for some provided, pending core cleanup for QMK upstreaming. PRs including different manufacturer names as well. |
| Shenzhen Hangsheng | PR submissions with crippled firmware, debating with maintainers about wireless despite marketing material clearly stating tri-mode. |
| Shortcut Studio | Selling tri-mode boards based on QMK without sources, just `via.json` provided. |
| Tacworks | Selling tri-mode boards based on QMK, crippled firmware already merged into QMK without wireless without QMK team realising. |
| TKD / Vertex | Selling tri-mode boards based on QMK without sources, attempted upstreaming crippled firmware without wireless. |
| WOBKEY | Selling tri-mode boards based on QMK without sources, attempted upstreaming crippled firmware without wireless. |
| Weikav | Selling tri-mode boards based on QMK without sources, just `via.json` provided. |
| Womier | Selling tri-mode boards based on QMK without sources, attempted upstreaming crippled firmware without wireless. |
| Wuque Studio | Selling wired and tri-mode boards based on QMK without sources, just `via.json` provided. |
| Zuoya | Selling tri-mode boards based on QMK without sources, just `via.json` provided. |
::: danger Violations
Links are not provided above as the QMK team does not wish to inadvertently promote purchases of boards in violation of QMK's license.
:::
## Licensing
QMK Firmware's license requires full disclosure of source code for any firmware which is based on QMK. This includes any of the following scenarios:
* Use of public QMK Firmware, but with "closed source" privately-held board definitions
* Vendor-customised QMK Firmware, which the vendor keeps private for building their own boards
* Any other non-QMK firmware which includes portions of QMK Firmware, such as adaptation of `via.c` into any other non-QMK firmware, even if used as a reference when translated to another programming language.
As per the GPL license requirements, vendors must provide entire source code for the as-shipped firmware.
QMK has traditionally been lenient with this clause -- providing source code to the QMK community is necessary but reproducing the exact build may not be possible. QMK has required functionally-equivalent source code to be made available. In rare cases exact code may be requested; vendors must keep copies regardless.
At minimum, vendors must provide the source code through some distribution mechanism. This could potentially be an clearly available downloadable copy of the code online, a fork of QMK Firmware, or even a DVD accompanying the product in the box.
If sources are unable to be provided in a timely fashion, QMK may revoke the vendor's license, effectively rendering them unable to leverage QMK.
Vendors choosing to keep things closed-source because of a desire to have a "competitive edge" compared to other vendors is unacceptable to both QMK and the community, and is a breach of the QMK license. There's no reason to do so; any new or interesting vendor-specific feature will be quickly replicated by other vendors or the community anyway.
## QMK PR Considerations
Vendors who submit PRs to QMK Firmware whilst not providing full sources for all of their license-violating boards will be put on hold until source code for all violating boards is provided. Intentional deception may result in boards being removed from QMK and all future PRs for that manufacturer being denied outright.
Submitting crippled source code in order to attain a merge into QMK Firmware to pave the way for VIA support is unacceptable. This includes submitting a wired-only firmware for a wireless-capable board, or any other PR which does not include key features as-advertised.
Reusing the `VID` and `PID` for multiple boards (such as for two variants, wired and wireless) is an unacceptable scenario as this creates confusion for support. Many customers have flashed boards with the wrong firmware, which could have been avoided if vendors were obvious about their board identification mechanisms.
If there is sufficient ambiguity about a board, supporting evidence will need to be presented to the QMK team. This may include impartial third parties who can demonstrate a board's existence and can confirm its feature set, such as well-known content producers; popular review sites or notable video creators may be leveraged. If such evidence is unavailable, as a last resort the vendor may be required to ship a fully functional board in full retail packaging to QMK maintainers for verification. Engineering samples will not be accepted, as one-off boards have been deceptively used in the past.
PRs submitted to upstream QMK should not expect an instant merge just because source code has been provided -- code from OEMs has historically been of a quality lower than QMK standards, so as per the [PR checklist](https://docs.qmk.fm/pr_checklist) submitters should make the changes as small as possible and be prepared to change their implementation.
## Detection
If the QMK team identifies or is informed of a license violation from a vendor:
* Any current and future PRs for that vendor will be indefinitely put on hold, preventing merge into QMK Firmware, thus preventing any out-of-the-box VIA support
* Any existing keyboards from the vendor may be removed from QMK Firmware
* Vendors will be added to the _offending vendors_ list above
Repeated violations may result in that vendor being disallowed from contributing the QMK in its entirety. In the worst case, the QMK team may choose to revoke a vendor's license to use QMK Firmware outright.
## Remediation
Vendors must provide fully-featured source code for each of their identified violations, matching the feature capabilities of their as-shipped products. This will usually be in their own fork of QMK Firmware while awaiting a merge into upstream.
Once all identified violations have been remediated, current and future PRs will no longer be on hold and the vendor will be removed from the offending vendors list above.
@ -42,7 +42,7 @@ Look at the output from that command, you should see something like this:
Ψ Created a new keymap called <github_username> in: /home/me/qmk_firmware/keyboards/clueboard/66/rev3/keymaps/<github_username>.
```
This is the location of your new `keymap.c` file.
This is the location of your new keymap file. Your keyboards default keymap file may be a `.json` file or a `.c` file. If your keymap is a `.json` file it can be converted to a `.c` file using QMK's [`json2c`](cli_commands#qmk-json2c) utility.
Make example for this keyboard (after setting up your build environment):
make binepad/bnk8:default
Flashing example for this keyboard:
make binepad/bnk8:default:flash
See the [build environment setup](https://docs.qmk.fm/#/getting_started_build_tools) and the [make instructions](https://docs.qmk.fm/#/getting_started_make_guide) for more information. Brand new to QMK? Start with our [Complete Newbs Guide](https://docs.qmk.fm/#/newbs).
## Bootloader
Enter the bootloader in 2 ways:
* **Bootmagic reset**: Hold down the key at (0,0) in the matrix (usually the top left key) and plug in the keyboard
* **Keycode in layout**: Press the key mapped to `QK_BOOT` if it is available
Make example for this keyboard (after setting up your build environment):
make cannonkeys/cerberus/hotswap:default
make cannonkeys/cerberus/solderable:default
Flashing example for this keyboard:
make cannonkeys/cerberus/hotswap:default:flash
make cannonkeys/cerberus/solderable:default:flash
See the [build environment setup](https://docs.qmk.fm/#/getting_started_build_tools) and the [make instructions](https://docs.qmk.fm/#/getting_started_make_guide) for more information. Brand new to QMK? Start with our [Complete Newbs Guide](https://docs.qmk.fm/#/newbs).
## Bootloader
Enter the bootloader in 3 ways:
* **Bootmagic reset**: Hold down the key at (0,0) in the matrix (usually the top left key or Escape) and plug in the keyboard
* **Physical reset button**: Toggle the switch on the back of the pcb to "1" and briefly press the button on the back of the PCB
* **Keycode in layout**: Press the key mapped to `QK_BOOT` if it is available
File diff suppressed because it is too large
Load Diff
Some files were not shown because too many files have changed in this diff
Show More
Reference in New Issue
Block a user
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.
