Pictured: current TKL below, split ergomech above
Background
So I recently got my first ergomech keyboard: a used BastardKB TBKMini, 3x6+3 layout.
It came with the default keymap.
I have been crafting my own initial keymap, using some vim-based heuristics and Callum style one-shot mods.
Followed BastardKB's instructions and got my keymap to compile.
Then onto flashing. This is where the problem is.
The problem: flashing the board
Instructions: https://docs.bastardkb.com/fw/flashing.html
I managed to put the device into bootloader mode with both layer keys and the top-left key. Verified that it is in bootloader mode by checking that typing has no effect. Also lsusb
shows "Atmega32u4 bootloader" instead of "BastardKB TBKMini keyboard".
But I don't get a disk device.
Things I tried
udev
I tried adding the udev rules that QMK docs recommend: https://docs.qmk.fm/faq_build#can-t-program-on-linux
But it still won't work.
OS
I even tried another pc with other OSes: same behavior on
- Fedora
- CachyOS
- and even Windows 10
Help me please! 😥
Any ideas on what is going wrong here or what I could try to work around this? I really want to start using my split ergomech with a proper keymap.
Looking forward to reading your suggestions tomorrow morning (in about 9 hours for me, I'm in Europe). I wanted to post this now because I hope the Americans will be able to help me.
EDIT: Thanks, with your help and the help of some kind volunteers on the bastardkb discord I figured out that I have the old v1 elitec version and I managed to flash it with an old version of the bastardkb firmware. I got the layers working, as well as the combo, but callum’s oneshot modifiers aren’t working yet: https://github.com/fhoekstra/bastardkb-qmk/tree/main/keyboards/bastardkb/tbkmini/keymaps/fhoekstra
EDIT2: I finally listened and just followed the upstream QMK instructions, and it all just works, with Callum-style modifiers, combos, and a custom caps word:
I don't agree with /u/red-crayon-scribbles ' approach to memory safety, but what you're saying isn't entirely true either.
It is possible to manipulate memory in ways that do not conform to Rust's lifecycle/ownership model. In theory, this can even be done correctly.
The problem is that in practice, this leads to the following, many of which were committed by some of the most highly skilled C developers alive, including major kernel contributors:
https://xeiaso.net/blog/series/no-way-to-prevent-this/