# tz's QMK todo list
## High-level list
In no particular order or priority.
* Encoder driver abstraction
* XAP firmware consolidation
* XAP client
* SPI/I2C multi-bus abstractions
* SPI/I2C threadsafety
* More introspection pre-work for adapting more stuff in flash (key overrides, etc.)
* Community modules
* Optional RAM write-through cache for SPI/I2C EEPROM reads
* Rewrite NOR Flash driver to use SFDP, DDR/QDR
* littlefs / fatfs etc.
* SDcard support
* QP region support
* QP transparency
* QP RGB/BGR switch
* Ghoul rev2 / PCBA / QMK devkit
* Lich rev0
* Add `_pre` and `_post` hooks for all `_task` functions
## Optimisation
* `-O3` causes issues. Diff some `*.lst` files and see what's being removed.
## Split comms
* FDCAN STM32 driver?
## Bus safety
* **I2C/SPI mutual exclusion** required
* Multi-bus instances - I2C1, I2C2 etc.
* Rework Djinn/Ghoul rendering to secondary thread
* Add DMA MEM2MEM `memcpy()` for image data for framebuffers etc.
## Community modules
* `<qmk_firmware>/modules/xxxxxx` (format TBD)
* `info.json` and `keymap.json` gets support for `"modules": [ "drongocat" ]`
* Ordering of modules defines which order they're executed
* Codegen to add:
* `keyboard_pre_init_<module>`
* `keyboard_post_init_<module>`
* `process_record_<module>`
* `matrix_scan_<module>`
* `housekeeping_task_<module>`
* etc.
* Codegen also adds equivalent `xxxx_modules()` which invokes the above in order specified, the wrapper is added to normal location of original API hook
## Quantum Painter follow-up merges
* Optimise decoder etc. to do batching instead of doing one pixel at a time
* Image region support
* Add SSD1306 to match current `oled_driver`
* Allow for "transparent colour" embedded in images when working with framebuffers
* Multi-framebuffer manipulation to compose parallax scenes
* Render image to fbuf, rotate in-memory, render to next fbuf on top of bg, then stream final image to display at one point
## XAP
* See [XAP MVP](https://github.com/qmk/qmk_firmware/projects/4) project
* See [qmk/qmk_xap](https://github.com/qmk/qmk_xap)
* See [issue #11567](https://github.com/qmk/qmk_firmware/issues/11567)
* See [PR #13733](https://github.com/qmk/qmk_firmware/pull/13733)
## EEPROM changes
* Need threadsafe bus work done!
* QMK erases as `0x00`, see if we can `^0xFF` to minimise writes
* Confirm what the `erase()` methodology is across drivers and platforms
* AVR doesn't do a full erase? Does it reset VIA keymaps?
* Add `nvram` frontend for all eeprom APIs that use `uint32_t` instead of `void*`
* Add ring fence so that we can swap out the lower-level APIs
* Wrap existing APIs where required (AVR)
* Update existing APIs where possible (external EEPROM, emulated etc.)
* May need different access pattern in order to deal with littlefs below -- bare bytewise offsets aren't the best
* optional RAM write-through cache for external EEPROM to minimise read latency
* depends on the size of the EEPROM
* already present on wear-leveling drivers
* ldscripts changes to preallocate an area of flash for emulated eeprom
* automatic assignment of different ldscript if using "vendor" driver?
* or validation of ldscript using known suffix like `__eeprom`?
* check if we should add wear-leveling driver for external I2C/SPI eeprom
* see if we can integrate [littlefs](https://github.com/littlefs-project/littlefs) for eeprom on flash
* partial file writes rewrite the whole file contents
* perhaps due to size -- 36 bytes of EEPROM possibly too small to "chunk" anyway
* needed for lua scripts and other dynamically uploadable stuff (QP images?)