ghostbuster wrote: ↑02 Jun 2022, 05:58
Are there any plans to upstream this work to the QMK project?
Yes. It will take time. I have zero time right now, but nothing is abandoned, I just don't have time to work on it due to life circumstances. No, it's not trivial. If it was only 8 hours of work, it would have been done a long time ago. It's more than that.
ghostbuster wrote: ↑02 Jun 2022, 17:00
QMK maintainers have discussed their reservations?
I want to clarify, cause some of the discussions on this thread start sounding like QMK maintainers might have some unreasonable requirements. That is NOT the case. It is absolutely normal for there to be back-and-forth between someone wishing to contribute to an open source project and its maintainers. I haven't even officially started that process. I only asked around on the QMK discord, and the main two things I learned from those conversations was that they would prefer common capsense code as core feature (rather than in the keyboards/xwhatsit sub-tree), and that they don't want auto-bootloader-entry as a feature, because it's technically a security flaw. Even beyond these things I listed, there is
a mountain of work that has to be done to make it ready, so there was no point in even trying to open a pull request, until the codebase is in a state that I'm comfortable trying to present as a PR. Again please let it be clear, it's
not that QMK maintainers are blocking upstreaming,
it's that I don't have the time right now to work on it. I will get to it when I will have time.
ghostbuster wrote: ↑02 Jun 2022, 05:58
I'm assuming pandrew = purdea.ro? Trying to clone that getting less than 1 kbit/sec.
I just tried cloning on a machine from the US (from my romanian server).
The whole repository got cloned in 2 minutes and 45 seconds. The .git subdirectory is about 145 MiB, so the average bandwidth was around 900KiB/s
It is possible there was a transitory problem with the network connection at the time you tried it, please try again.
NathanA wrote: ↑02 Jun 2022, 22:55
This is why I'm as passionate about encouraging Vial adoption as I am.
I agree, and I also want to eventually officially support VIAL. Main issues I will need to solve are: 1) To make the debugging features in util.exe work with it 2) To have it support all the keyboard variants I support. All of these are doable, I just don't have time right now. And waiting might actually solve some problems for me, since XAP is in development upstream (well it was in active development a couple months ago, I did not have time to keep up-to-date with the latest news). Currently I can't support VIAL-specific problems, but I appreciate all the people who have posted their VIAL firmwares.
I'm also toying with the idea of backporting my training algorithm into original xwhatsit firmware. If that comes to pass, there will be two reliable choices for firmware variants that can have their keymaps changed without having to re-flash the firmware.
NathanA wrote: ↑31 May 2022, 12:21
The issue is that pandrew's QMK capsense driver will "pass over" setting a threshold for any keys where the default layer 0 key value is set to "KC_NO" (nothing), and just set that pad to threshold of 0. Which in turn causes that key to not be sensed, period. And it just so happens that literally every key layout in the default firmware distribution other than the JIS and scumyc ones have that extra key to the right of Spacebar set to KC_NO.
Muirium wrote: ↑31 May 2022, 12:29
Well that's a stoater of a bug if so!
In
plain QMK this is a feature, not a bug. Let me explain:
Key positions that don't have a flippers over them will have a lower signal value than key positions that have a flipper over them, but are unpressed. That means that with high likelyhood keys without flippers will make the range of signal levels bigger, and as such will likely affect the binning of these signal levels. For this reason
I explicitly recommend not assigning keys to key positions that don't have flippers over them. This is in order to maximize the chance that the training algorithm will come up with a closer to optimal solution. This is why key positions that are assigned N/A or KC_NO on layer 0,
in plain QMK, are skipped over.
Layer 0 in plain QMK is stored only in flash memory. My code only looks in this flash memory area.
VIAL adds the possibility of EEPROM-stored keymaps, but
my training code is not aware of this.
One potential way to handle this, is for my code to also look in the eeprom, (if running in VIAL), and to make the decision to skip or not to skip a key based on the configuration it finds in the EEPROM. Also there could be some pitfalls with live reconfiguration. Vial may need to re-trigger training on keymap updates, if keys are changed from N/A to having a function on layer 0.
A second option is to have different pre-built vial firmware alternatives for different flipper-placement configurations.
A third option would be to try to quantify the effect of key positions without flippers. I guess it's possible that the effect I'm talking about is small enough that it's not worth fussing about. After all people have been using their keyboard just fine without following this recommendation of mine. I haven't done the work to try and quantify this effect, so I don't know how much it matters.
DMA wrote: ↑02 Jun 2022, 02:52
seriously looks like your RP3 and RP4 are 10-pin while PCB is made for 8-pin ones.
Nice catch!