NathanA provided a a good summary of the major reasons why the F77 is not in the official QMK code base.
Why no F77 support? The QMK maintainer want a small set of files to review. I decided to first attempt to get my refactor build of the F62 firmware with two keymaps into the official QMK code base.
After around 6 months of back and forth with the volunteer QMK maintainers. My F62 refactored build pull request has passed the pr_checklist review. I merged the official QMK code base into the git branch for the pull request and the firmware compiles the the test environment. I have asked what is the next step for the pull request.
My plan for getting the refactored build into the official QMK code base. There will be only one active git pull request at a time.
1. Pull request for F62 with default and VIA keymaps. Contains my lightly refactored pandrew xwhatsit C code. I made significant changes to build system. (ON GOING)
https://github.com/qmk/qmk_firmware/pull/21193
2. Pull request for F77 with default and VIA keymaps.
3. Pull request for remaining F62 keymaps.
4. 5. .... Multiple pull requests for the F77 keymaps.
At times I am frustrated with QMK. There has been more than 5 times in which the QMK core developers and or the build maintainers have make changes. Some of the changes have required me to make what i feel are significant code or build system updates.
Github for Link the GIT branch i am using for the pull requests. The link is to the keyboards/model_f_labs directory.
https://github.com/matthew-wolf-n4mtt/q ... del_f_labs
I have been using a different GIT branch for developing the pull requests. The changes I have made for F62 pull request have been duplicated for the F77 in the branch. The link is to the keyboards/model_f_labs directory.
https://github.com/matthew-wolf-n4mtt/q ... del_f_labs
I have VIA 3.0 definition design files for my refactor build of the F62 and F77. I have been using the files for testing. They are derived from the VIA definition design files provided by Darkcruix. The files are required to have the VIA GUI application to work with VIA firmware that is not included in the official QMK / VIA code base. They are JSON formatted files that Deskthority will not allow be to attach. I will figure someway to share them and provide where to get them.
My refactored build changed the location of the keyboards files in the QMK source tree. The VIA firmware requires unique USB IDs. I had to hack the pandrew utility for the different location of the source files and the USB IDs. Link to the source of my hacked pandrew utility.
https://github.com/matthew-wolf-n4mtt/p ... it-utility
My refactored F62 and F77 VIA firmware does not work with the pandrew utility. Only my non-VIA firmware should work with the pandrew utility. I can not guarantee that all the features of the pandrew utility will work with my version of the firmware. I only do very basic testing of my "hacked" pandrew utility
NathanA wrote: 07 Nov 2023, 22:38
AlpsComeback wrote: 07 Nov 2023, 17:36
I've been wanting to use my F77 lately, but I've noticed that the QMK support still hasn't been merged into the official QMK github repo. Does anyone know why it's taking so long and when it will be in the official repo?
*sigh*
Like any software project -- open source or not -- the project owner / maintainer has certain standards to uphold. This includes things like the way your code is factored, how it interfaces with existing modules / calls into existing code, whether memory allocation/efficiency/safety+security standards are being upheld, even down to code formatting being consistent with what's already in the repo, etc.
They aren't simply going to accept outside contributions blindly, lest average code quality in the project slowly erode over time. No open source project worth its salt would. It's also not their job, nor responsibility, to clean up your code for you. So if somebody wants their code to be accepted badly enough, they need to take whatever feedback they get from the maintainers, and try to bring that code up to the project's standards first.
Projects like this are also something of a moving target, so the longer you wait to make your code conform to their requirements, the more likely it is that something will have changed in the meantime. If you submit a contribution & get some feedback about things that must be changed before it is accepted, and then you only get around to it, say, six months later, core parts of the project that your contribution heavily depends on may now be different...existing functions/APIs may have been deprecated and new ones added in their place, etc. So now you have to basically "port" your contribution to the latest version, on top of everything else. And once you have finished with that and re-submit, you'll more than likely receive even more feedback about things in your code that need to be changed, etc.
It's been well-established that the original author of the code for the xwhatsit/capsense support in QMK has not had the time to dedicate to this. There have been other volunteers who have said they've taken up the gauntlet, but it's not clear to me what the current status of those efforts is.
On top of that, there is some debate about whether the goal of using a more current version of QMK on these keyboards is juice that's even worth the squeeze, given the limitations of the ATmega micro platform that the controller board is using at its core. The QMK codebase has only been getting larger (some might even say more bloated?) over time. Some of the newer features are nice, to be sure, but it's seemingly not possible (at least without a LOT of creative re-optimization) to get all of them to simultaneously fit within the tiny ATmega's memory space. This either results in instability, or in the worst case, a firmware file that's too large to even fit into flash to begin with.
All that said...how is the lack of support from the official QMK repo somehow "preventing" you from using your keyboard? My F77 somehow works just fine in spite of this; after all, I'm typing this response on it. Sarcasm aside, is there a particular newer QMK feature that you are hoping to use that the capsense fork doesn't have?
IBM Keyboard Photos by Model F Keyboards, on Flickr
I knew this going in, so no harm done. I just couldn't pass up the opportunity for an ergo buckling spring keyboard.
