08bbda7111
* Fix dirtying in oled_write_pixel() Set the dirty bit for the block only if oled_write_pixel() actually changed the buffer state. Without this check oled_write_pixel() could not be used inside the oled_task_user() code using the “redraw always” style, because the blocks touched by oled_write_pixel() would always appear dirty, and oled_render() would not proceed beyond the first such dirty block. * Fix oled_write_pixel() with 90/270 degree rotation Use oled_rotation_width instead of OLED_DISPLAY_WIDTH, so that a rotated display would be handled correctly. * Fix compilation with custom OLED_BLOCK_COUNT and OLED_BLOCK_SIZE Some OLED sizes (e.g., 64×48) may require a nonstandard value of OLED_BLOCK_COUNT. The documentation says that this value may be redefined in config.h, but actually trying to redefine it caused a compile error, because the macro was redefined in oled_driver.c. Make the OLED_BLOCK_COUNT definition in oled_driver.c respect any user override, and do the same for OLED_BLOCK_SIZE just in case. * Fix handling of out-of-range bits in oled_dirty If a custom OLED_BLOCK_COUNT value is specified, some bits in oled_dirty may not correspond to existing blocks; however, if those bits are set somewhere (e.g., by code with sets oled_dirty to ~0 or even -1), oled_render() would try to handle them and could access memory beyond oled_buffer and perform hardware operations with out of range values. Prevent this by masking off unused bits in oled_render(), and also avoid setting those bits in other functions. * Fix potentially wrong dirtying in oled_write_char() oled_write_char() tried to mark the position just beyond the written character as dirty; use (OLED_FONT_WIDTH - 1) to dirty the last position still belonging to the character instead. * Fix `#define OLED_BLOCK_TYPE uint32_t` on AVR Using uint32_t as OLED_BLOCK_TYPE did not work properly on AVR, because some bit shifts were performed using 16-bit int. Add explicit casts to OLED_BLOCK_TYPE to those shifts.
ZSA's fork of QMK Firmware
This purpose of this fork is maintain a clean repo that only contains the keyboard code that we need, and as little else as possible. This is to keep it lightweight, since we only need a couple of keyboards. This is the repo that the EZ Configurator will pull from.
Supported Keyboards
Maintainers
QMK is developed and maintained by Jack Humbert of OLKB with contributions from the community, and of course, Hasu. The ZSA branch is maintained by Drashna, ZSA's official QMK Liaison, and by Florian Didron, ZSA's lead developer, with input from Erez Zukerman (ZSA CEO).
Update Process
- Check out branch from ZSA's master branch:
git remote add zsa https://github.com/zsa/qmk_firmware.gitgit fetch --allgit checkout -B branchname zsa/mastergit push -u zsa branchname
- Check for core changes:
- https://github.com/qmk/qmk_firmware/commits/master/quantum
- https://github.com/qmk/qmk_firmware/commits/master/tmk_core
- https://github.com/qmk/qmk_firmware/commits/master/util
- https://github.com/qmk/qmk_firmware/commits/master/drivers
- https://github.com/qmk/qmk_firmware/commits/master/lib
- These folders are the important ones for maintaining the repo and keeping it properly up to date. Most, but not all, changes on this list should be pulled into our repo.
git cherry-pickthe commits we wantgit rm docs/* -rto remove the document updates when cherry picking. Repeat for any keyboard/keymap/etc that have changes that we aren't interested in
- Commit update
- Include commit info in
[changelog.md](http://changelog.md)
- Include commit info in
- Open Pull request, and include information about the commit
Strategy
To keep PRs small and easier to test, they should ideally be 1:1 with commits from QMK Firmware master. They should only group commits if/when it makes sense. Such as multiple commits for a specific feature (split RGB support, for instance)
Merging
Pull Requests should be merged/rebased, not squashed, so we can maintain a commit history that is close to QMK Firmware's, for ease of reference.