[GB] F104+SSK+122+62+77+50+Ergo orders now open! Kishsaver+Industrial Model F

[Ellipse]

Bluetooth wireless Model F update:

Is anyone interested in making their Model F wireless?

I recently saw a post on this, for the Model M:  https://deskthority.net/viewtopic.php?t=29368

Maybe it can be an update or add-on PCB to Rico's Leyden Jar controller or the xwhatsit controller, or a new controller entirely (less convenient as it would require everyone to desolder their current controller). 

The Leyden Jar RP2040-based controller does accept power and signal on its header extension, so something like the Supermini NRF52840 used for the above project may be able to work with a battery.  Ideally, if a PCB is needed it could be designed to be manufacturable by JLCPCB.  If it is powered off the header extension, it might also be helpful to have an extension header on the add-on PCB for a solenoid driver and solenoid (though the battery won't last as long).  The Leyden Jar currently allows one controller to communicate with and power another:  https://github.com/mymakercorner/Leyden_Jar

There are other projects not specific to the Model F that may work but are currently not tested with the Model F:

https://handheldsci.com/kb/
https://sterling-key.com/

https://www.wscome.com/product/wired-keyboard-converted-to-wireless-keyboard-diy-kit/
https://www.wscome.com/product/convert-a-wired-keyboard-to-wireless-keyboard-wbt-v2-wbt2-v4/
https://git.kkozai.com/kenji/pico_ble_hid/
https://www.reddit.com/r/MechanicalKeyboards/comments/1d7c5dc/sterlingkey_a_bluetooth_adapter_to_turn_your/
https://www.reddit.com/r/olkb/comments/sby7k6/diy_bluetooth_qmk_microcontroller/


My guess is that the Model F would require a much larger battery to be able to run for several weeks (15000mah?).  Maybe one of those Lithium iron phosphate batteries of that size could be used. 

[callllll]

Hey all! Recieved my model F122, it's wonderful. Super well built and it looks stunning.

I do have one small issue - compared to either of my model M's, the keys are a bit scratchy, and even the 1U keys can be inconsistent/bind slightly with off-center key presses. I did not find any information in the manual regarding this behavior. I believe this is caused by the keycaps, as I do not have this issue if I install an original Model M key.

Any advice would be appreciated!

[Ellipse]

No, I would not characterize Model F keys as scratchier than Model M keys.  Your old keyboard is probably decades old and may be quite smooth after so much usage.

[callllll]

No, I would not characterize Model F keys as scratchier than Model M keys.  Your old keyboard is probably decades old and may be quite smooth after so much usage.

That makes sense. Primary concern is binding with off-center presses. It isn't major, and I'll see if that resolves with continued use!

[Ellipse]

For those who have received and started using the new F122 keyboards:

Please email me with feedback on how things are going.  As always, make sure you're running the latest firmware (I think 5/19/25 is the latest?) which fixes potential issues with key ghosting, etc.

Is the F122's RP2040-based Leyden Jar controller better able to handle KVM switches, USB hubs, USB extension cables, etc.?  I recall that these caused issues for some xwhatsit controller-powered keyboards.

[Ellipse]

Here's a nice article on the 40th anniversary of the Model M keyboard this year:  https://www.pcgamer.com/hardware/gaming-keyboards/the-keyboard-that-all-other-keyboards-copied-turns-40-this-year-heres-how-the-ibm-model-ms-legacy-lives-on-today/

And here is the latest update from someone who got Bluetooth working with their new Model F keyboard, which uses Rico's RP2040-based Leyden Jar controller:

"I was able to get this https://www.amazon.com/Ruitutedianzi-Bluetooth-Converter-Keyboard-Wireless/dp/B0DP6WTZY4/ Bluetooth adapter to work on this Leyden Jar board, whereas my xwhatsit based restored IBM F122 does not register any keypresses with it. The Handheld Scientific BT-500 does not work with either controller, but does at least register double keypresses with the Leyden Jar. I don’t have their updated BT-600 to test with.  According to my in-line USB meter, the BT adapter and keyboard idles at 26mA (with all LEDs on, each consuming ~1mA). With the solenoid at factory settings, I’ve seen it peak at 189mA – but the ~1s sampling rate makes this a very rough estimate.

Using an average 2000mAh 18650 Li-ion cell, I would guess we’d get ~76 hours (or as little as 10 with the solenoid and constant firing)."  In other words, one month of battery life with a 20000mah battery.

[Ellipse]

Now that the backlog of F122's is done and we are just waiting on boards with orders in August and Everything After (!) (as well as the Round 2 beam spring boards), I will be proceeding with the pad printed Model F PBT keycap project.  Due to poor quality I had to switch factories.  Below is the new factory sample.  This company is one of the largest keyboard manufacturers in the world.

Based on feedback with a focus on durability instead of authenticity to original standards, these keycaps will be using the highest quality abrasion-resistant inks offered by a major manufacturer, as well as a protective coating on top of each legend, with a slight margin of safety.  The original IBM M13 boards were known to wear more quickly as they had no protective coating.  While this reduces originality it should greatly increase durability.

Please disregard the lack of alignment for these test prints; the production keys will have normal alignment.


Below is a photo from the first batch of combined Apple/Mac Text and Icon keys, which are now in stock and available to order. 


Apologies that both photos are slightly out of focus for parts of the image. 

As always please sign the following interest forms if interested and if you have not done so already:

Pad Printed keys interest form:  https://forms.gle/Md7p5oA8zySy6pkG7

2025 Model F Project Interest Form for new designs:  https://forms.gle/c9cSCCmsDhZk4ZDR6

ISO Black, Industrial SSK Blue, Dark Gray Key Sets, Big Enter Keys, Code Keys Interest Form:  https://forms.gle/cDDypmZii6ihxgDY8

And with permission I am sharing a nice image of the Quebec CSA key set:

[ploxiln]

Hi @ellipse ... I'm new to these forums, but I ordered an F77 way back in 2017 (received in 2019). Anyway, to my professional-software-developer sensibilities, the firmware situation has always been a bit of a mess. Don't get me wrong, what you've accomplished with finding overseas manufacturers, communicating with them, quality control, etc, is truly amazing and far beyond my abilities. But, software, firmware ... I have some notes I really hope you consider.

First, the QMK-layout-files.zip you currently host is nested (surely that's not intended):

Code: [Select]

$ unzip -Z QMK-layout-files.zip
Archive:  QMK-layout-files.zip
Zip file size: 21286345 bytes, number of entries: 1
-rw-a--     6.3 fat 21560059 bx defN 25-May-20 21:56 QMK-layout-files.zip
1 file, 21560059 bytes uncompressed, 21286171 bytes compressed:  1.3%

$ mkdir tmp
$ unzip QMK-layout-files.zip -d tmp/
Archive:  QMK-layout-files.zip
  inflating: tmp/QMK-layout-files.zip 

$ unzip -Z tmp/QMK-layout-files.zip
Archive:  tmp/QMK-layout-files.zip
Zip file size: 21560059 bytes, number of entries: 767
-rwxa--     2.0 fat     1801 t- defN 24-Feb-12 17:12 QMK-layout-files/b104 r1 ansi.bat
-rwxa--     2.0 fat     1808 t- defN 24-Feb-12 17:12 QMK-layout-files/b62 ansi HHKB 2U Backspace.bat
-rwxa--     2.0 fat     1805 t- defN 24-Feb-12 17:12 QMK-layout-files/b62 ansi HHKB Split Backspace.bat
-rwxa--     2.0 fat     1801 t- defN 24-Feb-12 17:12 QMK-layout-files/bssk r1 ansi.bat
-rwxa--     2.0 fat     1804 t- defN 24-Feb-12 17:12 QMK-layout-files/bssk r2 ansi.bat
-rwxa--     2.0 fat     1803 t- defN 24-Feb-12 17:12 QMK-layout-files/bssk r2 iso.bat
-rw-a--     2.0 fat     4929 t- defN 23-Nov-07 05:00 QMK-layout-files/build.sh
-rwxa--     2.0 fat     1804 t- defN 24-Feb-12 17:12 QMK-layout-files/f104 r1 non-shrunk ansi.bat
... lots of files ...
767 files, 38218027 bytes uncompressed, 21387443 bytes compressed:  44.0%

Instead of always updating /wp-content/uploads/2020/07/QMK-layout-files.zip it really would be better to give each version a different dated name, and have a directory with all dated archives ever released available. This is very rare for commercial software, but very common for well-run open-source software projects. It just makes things less confusing for anyone trying to come in and figure out what's really changed, or confirm whether something used to work, etc.

On that note, you really should have separate manual pages for the firmware stuff (and other sections too). Having a huge rambling firmware section that covers different controllers and different firmware lines and different OSes, in the middle of a truly gigantic single-page manual, with misc links sprinkled throughout, is really not great. The manual is quite verbose, but pretty good, after the first part which spends 12+ paragraphs saying you really need to read the whole damn manual, and up until the firmware section, which is truly a mess. (BTW you've got some older instructions for the pandrew utility in Action step 7, bullet 7. Ideally that would just link to a common up-to-date page about the utility.)

More importantly, you should host mirrors of all the source code yourself (or on your own GitHub account, or GitLab, or SourceHut, or Codeberg, or anywhere reliable). This is quite evident since pandrew's git host has been down for a couple months. But even back in 2019 this bothered me (along with the web QMK configurator hosted at some ip address, presumably by some other third party). I think you mentioned back in 2019 that you merged pandrew's wip branch with later QMK and made some more builds and updated the "one zip file" ... you really should have your own git repo and branches to support the keyboards you sell (with tags for every build you ever released, ideally).

Continuing with @NathanA's nice Vial port/fork/whatever ... which is distributed as an archive (7z is fine), and by following the gist to build pandrew-util for linux (linked in the middle of the firmware section of the manual), I figured out that build.sh constructs a source tree by checking out an old commit from vial-qmk and then applying a bunch of patches. This is what git is actually for! By the way, that build.sh is broken, and thus the gist instructions for compiling the linux pandrew-util are broken, because http://purdea.ro/qmk_firmware is offline. Luckily I do have all needed commits/branches from pandrew's git host, due to customizing my layout in QMK source back in 2019/2020. Anyway... I suggest using git hosting and git branches, and link to reliable git mirrors from a dedicated firmware page on modelfkeyboards.com ... so my mild OCD doesn't turn me into the crazy guy in front of a corkboard unraveling the tangled web of where all the builds and patches are 

FWIW I've mirrored pandrew's branches here: https://github.com/ploxiln/qmk_firmware

and I've constructed nicer branch of commits version of NathanA's `build.sh` here: https://github.com/ploxiln/vial-qmk
(enough to build pandrew-util with all proper sources, but not quite including the actual final Vial layouts build part, maybe a TODO)

@NathanA while working on that I noticed the old upstream Vial CI found VIAL_KEYBOARD_UID re-used across f104_round_1_nonshrunk and f104_round_1_shrunk, I'm not sure how much that really matters for these 2 boards, or if it's tricky to fix now that some people already flashed these? But here was my guess at a fix:

Code: [Select]

--- a/keyboards/xwhatsit/brand_new_model_f/f104_round_1_nonshrunk/wcass/config.h
+++ b/keyboards/xwhatsit/brand_new_model_f/f104_round_1_nonshrunk/wcass/config.h
@@ -19,7 +19,7 @@ along with this program.  If not, see <http://www.gnu.org/licenses/>.
 
 #include "config_common.h"
 
-#define VIAL_KEYBOARD_UID {0x01, 0x41, 0x46, 0x4D, 0x04, 0x47, 0x09, 0x12}
+#define VIAL_KEYBOARD_UID {0x01, 0x40, 0x46, 0x4D, 0x04, 0x47, 0x09, 0x12}
 /* USB Device descriptor parameter */
 #define VENDOR_ID 0x1209
 #define PRODUCT_ID 0x4704

All that said ... the Vial firmware and local utility is actually quite nice, thanks @NathanA

[ploxiln]

Oh, one more thing ... the way you rename the flash scripts, actually makes it really not obvious which is appropriate for my F77 with split right shift and non-split backspace:

Code: [Select]

... lots of files ...
'UNIX - f77 ansi block1 Ins Del etc.sh'
'UNIX - f77 ansi block2 0-9.sh'
'UNIX - f77 ansi HHKB 2U Backspace block1 Ins Del etc.sh'
'UNIX - f77 ansi HHKB 2U Backspace block2 0-9.sh'
'UNIX - f77 ansi HHKB 2U Backspace, Regular position Caps Ctrl block1 Ins Del etc.sh'
'UNIX - f77 ansi HHKB 2U Backspace, Regular position Caps Ctrl block2 0-9.sh'
... lots of files ...

But in NathanA's r5 archive, it's much more clear:

Code: [Select]

$ ls newfxx-vial-package/flash-scripts/f77/ | cat
flash-f77-allpads_opt1.sh
flash-f77-allpads_opt2.sh
flash-f77-ansi_fn_opt1.sh
flash-f77-ansi_fn_opt2.sh
flash-f77-ansi_fn_opt3_nlock.sh
flash-f77-ansi_fn_opt3.sh
flash-f77-ansi_fn_opt3_simulock.sh
flash-f77-ansi_fn_opt4_nlock.sh
flash-f77-ansi_fn_opt4_simulock.sh
...

... it's the ansi_fn_opt1 which was clear from the readme.txt / "NathanA's notes.docx"

(Obviously we have some differences of preferences and comfort, due to working mostly with hardware and windows, vs software and other OSes. Again, I'm really impressed and grateful for your work on the hardware manufacturing and QC side, managing the whole project for so many years, dealing with analog gremlins, etc. But on the software side, there's really some very "low hanging fruit" for organizational improvement. I hope these comments can help somewhat in the future.)

[Ellipse]

Thanks for your feedback and for your help organizing and updating the various sources of code.  This is most helpful so that we can have everything in one place, at least as a copy of the original sources.  One main request would be to make sure compiling the pandrew utility works (without needing pandrew's offline source) on Win, Mac, and Linux (it has to be recompiled whenever there is an update of a new keyboard).  And my second request would be to combine Rico and NathanA's various branches into one combined fork if possible, while keeping each branch separate (more details below).  Kindly see my replies in-line:

Hi @ellipse ... I'm new to these forums, but I ordered an F77 way back in 2017 (received in 2019). Anyway, to my professional-software-developer sensibilities, the firmware situation has always been a bit of a mess. Don't get me wrong, what you've accomplished with finding overseas manufacturers, communicating with them, quality control, etc, is truly amazing and far beyond my abilities. But, software, firmware ... I have some notes I really hope you consider.

First, the QMK-layout-files.zip you currently host is nested (surely that's not intended):
----This is intentional due to false positive virus reports from some folks, unless it is zipped twice.

Instead of always updating /wp-content/uploads/2020/07/QMK-layout-files.zip it really would be better to give each version a different dated name, and have a directory with all dated archives ever released available. This is very rare for commercial software, but very common for well-run open-source software projects. It just makes things less confusing for anyone trying to come in and figure out what's really changed, or confirm whether something used to work, etc.

----If you could set things up in your github account for how you describe they should be organized, then I can fork them into the project's github account, if possible (https://github.com/ModelFKeyboard).  I have just added forks of the various projects as you have recommended from Rico's account and from your account (more details below).  I see that there is a new github feature to press a button to auto sync from the place you forked from, but I am not sure what is the easiest way to get updates as the Rico and NathanA projects are updated on github.  However I like the one file for most users who are not as technical and at most will just be flashing whatever is the latest set of firmware files.  In my experience folks look all over online and mistakenly flash various files, some of which are years out of date and do not work well.  The one constant link allows you to find all needed files in one place, where you know there are no extraneous files to choose from.

On that note, you really should have separate manual pages for the firmware stuff (and other sections too). Having a huge rambling firmware section that covers different controllers and different firmware lines and different OSes, in the middle of a truly gigantic single-page manual, with misc links sprinkled throughout, is really not great. The manual is quite verbose, but pretty good, after the first part which spends 12+ paragraphs saying you really need to read the whole damn manual, and up until the firmware section, which is truly a mess. (BTW you've got some older instructions for the pandrew utility in Action step 7, bullet 7. Ideally that would just link to a common up-to-date page about the utility.)

----Any further improvements would require someone such as yourself to kindly update the section with a Microsoft Word style track changes option so I can see what is being changed.  Each section is in the correct sequence and the beginning of the paragraphs include a bolded statement which helps determine if the paragraph is applicable to someone's specific setup. 

More importantly, you should host mirrors of all the source code yourself (or on your own GitHub account, or GitLab, or SourceHut, or Codeberg, or anywhere reliable). This is quite evident since pandrew's git host has been down for a couple months. But even back in 2019 this bothered me (along with the web QMK configurator hosted at some ip address, presumably by some other third party). I think you mentioned back in 2019 that you merged pandrew's wip branch with later QMK and made some more builds and updated the "one zip file" ... you really should have your own git repo and branches to support the keyboards you sell (with tags for every build you ever released, ideally).

----Yes, I hope to be able to do this if the NathanA and Rico repos can be combined into one while still being able to auto sync (maybe with different branches?  I don't know git too well. Also they use different QMK versions and may update them at different times in the future, so I don't know how that will affect the ability to combine them).  However it is done, they should maintain their ability to both be automatically synced with that sync button that I can press in my github account to sync things in the future.

Continuing with @NathanA's nice Vial port/fork/whatever ... which is distributed as an archive (7z is fine), and by following the gist to build pandrew-util for linux (linked in the middle of the firmware section of the manual), I figured out that build.sh constructs a source tree by checking out an old commit from vial-qmk and then applying a bunch of patches. This is what git is actually for! By the way, that build.sh is broken, and thus the gist instructions for compiling the linux pandrew-util are broken, because http://purdea.ro/qmk_firmware is offline. Luckily I do have all needed commits/branches from pandrew's git host, due to customizing my layout in QMK source back in 2019/2020. Anyway... I suggest using git hosting and git branches, and link to reliable git mirrors from a dedicated firmware page on modelfkeyboards.com ... so my mild OCD doesn't turn me into the crazy guy in front of a corkboard unraveling the tangled web of where all the builds and patches are 

FWIW I've mirrored pandrew's branches here: https://github.com/ploxiln/qmk_firmware

and I've constructed nicer branch of commits version of NathanA's `build.sh` here: https://github.com/ploxiln/vial-qmk
(enough to build pandrew-util with all proper sources, but not quite including the actual final Vial layouts build part, maybe a TODO)

----Thanks!  Is there a way for you to combine the vial forks of Rico's various branches and NathanA's various branches?  Since github doesn't want two of the same forked projects (qmk) in one user's account.  Can you explain pandrew's various branches and when you last synced with pandrew's github?  I wonder if it is fully up to date.  May need to compare against pandrew's site when it is put back up, hopefully soon.  Maybe NathanA's future update can link to my github after I fork pandrew's latest files, if possible.

@NathanA while working on that I noticed the old upstream Vial CI found VIAL_KEYBOARD_UID re-used across f104_round_1_nonshrunk and f104_round_1_shrunk, I'm not sure how much that really matters for these 2 boards, or if it's tricky to fix now that some people already flashed these? But here was my guess at a fix:

Code: [Select]

--- a/keyboards/xwhatsit/brand_new_model_f/f104_round_1_nonshrunk/wcass/config.h
+++ b/keyboards/xwhatsit/brand_new_model_f/f104_round_1_nonshrunk/wcass/config.h
@@ -19,7 +19,7 @@ along with this program.  If not, see <http://www.gnu.org/licenses/>.
 
 #include "config_common.h"
 
-#define VIAL_KEYBOARD_UID {0x01, 0x41, 0x46, 0x4D, 0x04, 0x47, 0x09, 0x12}
+#define VIAL_KEYBOARD_UID {0x01, 0x40, 0x46, 0x4D, 0x04, 0x47, 0x09, 0x12}
 /* USB Device descriptor parameter */
 #define VENDOR_ID 0x1209
 #define PRODUCT_ID 0x4704

All that said ... the Vial firmware and local utility is actually quite nice, thanks @NathanA

Regarding your subsequent post, I renamed the original files to match the names per the web site configuration tools.  For example, you described your keyboard as an "F77 with split right shift and non-split backspace" and the firmware name is "f77 ansi HHKB Split Backspace" plus a descriptor for the two right side block options; this is a shorthand for how it is described on the keyboard product page.  Those who prefer the original names can delete all the bat and sh files and then extract the "flash-scripts with original names.7z" file within the QMK layout files.zip file.

[Ellipse]

(double post)

[ploxiln]

This is intentional due to false positive virus reports from some folks, unless it is zipped twice.

Ah, freakin' anti-virus, I guess this is why some people put silly encryption passwords on zip files (e.g. "password"). Whatever works I guess.

One main request would be to make sure compiling the pandrew utility works (without needing pandrew's offline source) on Win, Mac, and Linux (it has to be recompiled whenever there is an update of a new keyboard).

Sure, I can work on this. I'm not as familiar with compiling stuff on windows, but I'll figure it out.

I hope to be able to do this if the NathanA and Rico repos can be combined into one while still being able to auto sync (maybe with different branches?  I don't know git too well. Also they use different QMK versions and may update them at different times in the future, so I don't know how that will affect the ability to combine them).  However it is done, they should maintain their ability to both be automatically synced with that sync button that I can press in my github account to sync things in the future.
...
Is there a way for you to combine the vial forks of Rico's various branches and NathanA's various branches?  Since github doesn't want two of the same forked projects (qmk) in one user's account.

Git is very flexible, and the way GitHub associates "forks" of repos in different accounts, doesn't really limit what you can do. On GitHub if you want to do branch comparisons (on the web) and create pull-requests across repos, they need to be in the same "fork network". I haven't really used the "sync" button, but it appears to only merge the default branch from the "forked-from" repo. I don't think it will do multiple branches and it definitely won't do multiple source repos.

But with a local git repo, you can add a bunch of "remote" repos, and work with all branches across all repos.The local git command doesn't care how GitHub associates the forks. You can pull branches from a bunch of different remote repos to your local system, and then push them to your own github repo. It doesn't have to be too complicated (but I don't have a great idea for how you can best automate it). I'll try to avoid churning out a full git tutorial which will bore many, but hopefully here's a useful taste of what's possible, and reasonably simple.

Even though I have ploxiln/qmk_firmware repo which I "forked" from qmk/qmk_firmware, and also ploxiln/vial-qmk repo forked from vial-kb/vial-qmk, these all share ancient qmk_firmware commit history, and I've added them all as remotes to my local qmk_firmware repo on my laptop:

Code: [Select]

$ git remote -v
darkcruix     https://github.com/darkcruix/qmk_firmware.git (fetch)
darkcruix     https://github.com/darkcruix/qmk_firmware.git (push)
pandrew       http://purdea.ro/qmk_firmware/ (fetch)
pandrew       http://purdea.ro/qmk_firmware/ (push)
ploxiln-qmk   git@github.com:ploxiln/qmk_firmware.git (fetch)
ploxiln-qmk   git@github.com:ploxiln/qmk_firmware.git (push)
ploxiln-vial  git@github.com:ploxiln/vial-qmk.git (fetch)
ploxiln-vial  git@github.com:ploxiln/vial-qmk.git (push)
upstream      https://github.com/qmk/qmk_firmware.git (fetch)
upstream      https://github.com/qmk/qmk_firmware.git (push)
vial          https://github.com/vial-kb/vial-qmk/ (fetch)
vial          https://github.com/vial-kb/vial-qmk/ (push)

$ git branch -a
  f77_layout_ploxiln
  latest
  master
* nathana_vial_xwhatsit
  pandrew_wip
  pandrew_wip2
  pandrew_wip_newqmk_2023
  pandrew_wip_old
  vial
  remotes/darkcruix/HEAD -> darkcruix/master
  remotes/darkcruix/arm-dac-work
  remotes/darkcruix/arm_rgb
  ...
  remotes/ploxiln-qmk/HEAD -> ploxiln-qmk/master
  remotes/ploxiln-qmk/f77_layout_ploxiln
  remotes/ploxiln-qmk/master
  remotes/ploxiln-qmk/pandrew_wip
  remotes/ploxiln-qmk/pandrew_wip2
  remotes/ploxiln-qmk/pandrew_wip_newqmk_2023
  remotes/ploxiln-qmk/pandrew_wip_old
  remotes/ploxiln-vial/HEAD -> ploxiln-vial/vial
  remotes/ploxiln-vial/latest
  remotes/ploxiln-vial/nathana_vial_xwhatsit
  remotes/ploxiln-vial/vial
  remotes/upstream/HEAD -> upstream/master
  remotes/upstream/arm-dac-work
  remotes/upstream/audio_out
  ...
  remotes/vial/HEAD -> vial/vial
  remotes/vial/merge-2025-06-21
  remotes/vial/old-sekigon-gonnoc-rp2040
  remotes/vial/tap-dance-tap-hold-fix
  remotes/vial/vial

That way I could "cherry-pick" commits (or files or directories from commits) on other branches on other repos, while "reconstructing" the NathanA source tree. (I didn't really need to make a new ploxiln/vial-qmk fork on github, I could have just used my existing ploxiln/qmk_firmware, but I thought it might be a cleaner way to present the branches publicly.)

So if I want to update my "master" branch from qmk/qmk_firmware, and my "vial" branch from vial-kb/vial-qmk, I would do:

Code: [Select]

git fetch --all       # update local cache of all remote repos/branches
git checkout master
git merge --ff-only upstream/master
git push ploxiln-qmk master
git checkout vial
git merge --ff-only vial/vial
git push ploxiln-vial vial

What I call the remote repos is arbitrary, you can see the mapping in the output of "git remote -v" above. The --ff-only means "fast-forward only" which means to abort if what is being "merged" does not exactly include the current branch's  entire history already, i.e. if this is not strictly a forward update. That's unexpected, and needs to be investigated/handled. Whatever I'm doing, I very often use "git status" and "git log" to confirm state of the current branch, and "gitk" or another graphical tool to see how branches intersect.

Can you explain pandrew's various branches and when you last synced with pandrew's github?  I wonder if it is fully up to date.  May need to compare against pandrew's site when it is put back up, hopefully soon.  Maybe NathanA's future update can link to my github after I fork pandrew's latest files, if possible.

The latest I have from pandrew is April 26, 2023 (though you see author dates of April 15, or in commits on the "wip2" branch from 2021, the commiter date is how I know this is due to rebase/squash). If pandrew's host comes back, it's no problem to sync (assuming I'm paying attention).



I think that might be the latest he published though, because NathanA's build.sh script references that commit "758febb" at the head of the "wip" branch (and "6ebae72" is the "change SOLENOID_DEFAULT_DWELL ..." commit a few below, the build.sh script effectively skips over the "util++" commits which appear add support for Vial and original non-qmk firmwares to the util, but probably conflict with NathanA's work on the util).

Code: [Select]

git clone http://purdea.ro/qmk_firmware "$(dirname "$0")"/tmp/pandrew-qmk
git -C "$(dirname "$0")"/tmp/pandrew-qmk show 758febb > "$(dirname "$0")"/tmp/f104r1-zeropads-fix.diff
git -C "$(dirname "$0")"/tmp/pandrew-qmk reset --hard 6ebae72

So I've pushed "pandrew_wip" which is pandrew's "wip" branch, which I think is his main branch. It starts from upstream QMK at tag 0.8.72 from 2020. It looks like the "wip2" branch (which I've pushed as "pandrew_wip2") is a rework of the xwhatsit calibration code, but maybe it never got to a state that is always clearly better? And finally he had a "wip_newqmk_2023" which I pushed as "pandrew_wip_newqmk_2023" which starts off somewhere between upstream QMK tag 0.20.5 and 0.20.6, adds support for more old IBM keyboards, and ends with some stack-debugging commits which suggest it wasn't stable yet?

[Ellipse]

Major project milestone:

Today the keyboard projects passed $4 million in total orders! 

Thanks for your notes and update ploxiln!