qmk
[Feature Request] Add filesystem examples or a note on Raw QGF files
Feature Request Type
- [ ] Core functionality
- [x] Add-on hardware support (eg. audio, RGB, OLED screen, etc.)
- [x] Alteration (enhancement/optimization) of existing feature(s)
- [ ] New behavior
Description
I found the Raw option for generating images from the command line that produces a binary, but I have not found any examples of actually using these raw files, what their purposes are, and if it's anything but a concept. I saw that the quantum painter code includes something for a file stream instead of a memory stream, with no exposed implementations. I have also tried for a day on and off to try to have file loading for .qgf files in firmware, but I can't figure out FATfs and what quantum painter actually needs to load images from files. Is there any developer notes on the raw image option and how to use it?
None, because no APIs are implemented for it yet. There is work for filesystems ongoing, but there's no established method to read/write to these from the host either.
It's purely to enable future work at this point, and likely has zero value to most people at this stage.
I see. In my project, for example, I want to dynamically load images per layer and have the option to put the keyboard in file system mode so I can load completely new icons without recompiling. I was trying to implement something for images like VIA handles key code changes. I can see your point, though, there probably aren't enough high-powered keyboards with GUI's to make it a priority to have anything but hard coded media.
I'd had the same view, and was intending to provide such functionality through XAP. Themes for displays and the like.
Time is always the problem!
If you feel like having a play, I have an experimental filesystem community module here, leveraging littlefs. Any discussion specific to that should probably be on Discord, in the QMK server's #help-modules channel. I've had it functioning on my Djinn for a bit over a year, but still need to iron out some issues when using it as a replacement for EEPROM. For generalised filesystem use, it should work okay.