docs(readme): Personalise the readme + include images

README.md

@@ -1,59 +1,67 @@
 # QMK Userspace
 
-This is a template repository which allows for an external set of QMK keymaps to be defined and compiled. This is useful for users who want to maintain their own keymaps without having to fork the main QMK repository.
+This is a repository which allows for an external set of QMK keymaps to be
+defined and compiled. This is useful to maintain keymaps without having to fork
+the main QMK repository.
 
-## Howto configure your build targets
+## Howto use it
 
-1. Run the normal `qmk setup` procedure if you haven't already done so -- see [QMK Docs](https://docs.qmk.fm/#/newbs) for details.
-1. Fork this repository
-1. Clone your fork to your local machine
-1. Enable userspace in QMK config using `qmk config user.overlay_dir="$(realpath qmk_userspace)"`
-1. Add a new keymap for your board using `qmk new-keymap`
-    * This will create a new keymap in the `keyboards` directory, in the same location that would normally be used in the main QMK repository. For example, if you wanted to add a keymap for the Planck, it will be created in `keyboards/planck/keymaps/<your keymap name>`
-    * You can also create a new keymap using `qmk new-keymap -kb <your_keyboard> -km <your_keymap>`
-    * Alternatively, add your keymap manually by placing it in the location specified above.
-    * `layouts/<layout name>/<your keymap name>/keymap.*` is also supported if you prefer the layout system
-1. Add your keymap(s) to the build by running `qmk userspace-add -kb <your_keyboard> -km <your_keymap>`
-    * This will automatically update your `qmk.json` file
-    * Corresponding `qmk userspace-remove -kb <your_keyboard> -km <your_keymap>` will delete it
-    * Listing the build targets can be done with `qmk userspace-list`
-1. Commit your changes
+This repository contains my somewhat unified configurations for the following
+keyboards:
 
-## Howto build with GitHub
+- Ferris bling 0.2
+- Atreus42 promicro
+- Xbows nature
 
-1. In the GitHub Actions tab, enable workflows
-1. Push your changes above to your forked GitHub repository
-1. Look at the GitHub Actions for a new actions run
-1. Wait for the actions run to complete
-1. Inspect the Releases tab on your repository for the latest firmware build
+Prerequisites:
+1. `qmk` installed in the computer
+2. Userspace configured on the computer
+    - `qmk config user.overlay_dir=$(realpath qmk_userspace)`
 
-## Howto build locally
+The goal of this repo is to store my custom configurations for
+`PERMISSIVE_HOLD_PER_KEY` for instance and timings for mouse emulation and so on
+to simplify further changes and synchronise the qmk configuration on different
+computers.
 
-1. Run the normal `qmk setup` procedure if you haven't already done so -- see [QMK Docs](https://docs.qmk.fm/#/newbs) for details.
-1. Fork this repository
-1. Clone your fork to your local machine
-1. `cd` into this repository's clone directory
-1. Set global userspace path: `qmk config user.overlay_dir="$(realpath .)"` -- you MUST be located in the cloned userspace location for this to work correctly
-    * This will be automatically detected if you've `cd`ed into your userspace repository, but the above makes your userspace available regardless of your shell location.
-1. Compile normally: `qmk compile -kb your_keyboard -km your_keymap` or `make your_keyboard:your_keymap`
+The keyboard configuration can be done on the [online
+configurator](https://config.qmk.fm/) using the [json files](./json).
 
-Alternatively, if you configured your build targets above, you can use `qmk userspace-compile` to build all of your userspace targets at once.
+Then, it can simply be transformed in a C file that can be used as is in the corresponding repository with:
 
-## Extra info
-
-If you wish to point GitHub actions to a different repository, a different branch, or even a different keymap name, you can modify `.github/workflows/build_binaries.yml` to suit your needs.
-
-To override the `build` job, you can change the following parameters to use a different QMK repository or branch:
-```
-    with:
-      qmk_repo: qmk/qmk_firmware
-      qmk_ref: master
+```sh
+qmk json2c <json file location> > keymap.c
 ```
 
-If you wish to manually manage `qmk_firmware` using git within the userspace repository, you can add `qmk_firmware` as a submodule in the userspace directory instead. GitHub Actions will automatically use the submodule at the pinned revision if it exists, otherwise it will use the default latest revision of `qmk_firmware` from the main repository.
+Finally, to flash the firmware:
+```sh
+qmk flash -kb <keyboard type> -km custom
+```
 
-This can also be used to control which fork is used, though only upstream `qmk_firmware` will have support for external userspace until other manufacturers update their forks.
 
-1. (First time only) `git submodule add https://github.com/qmk/qmk_firmware.git`
-1. (To update) `git submodule update --init --recursive`
-1. Commit your changes to your userspace repository
+## The layer description
+
+The main configuration relies on a 34 keys keyboard, let’s say the ferris, as a
+base with GASC homerow mods.
+
+The base layer looks like this:
+
+![Base Layer](./img/Layer-0.png)
+
+The internal thumb keys move to the nav/numpad layer on hold or space/tap on
+tap. This layer is the following:
+
+![Num-Nav Layer](./img/Layer-1.png)
+
+Finally, pressing both internal thumb keys (or left external one) leads to the
+function/mouse nav layer:
+
+![Num-Nav Layer](./img/Layer-2.png)
+
+This layer also allows accessing custom layers, such as here layer 3 that is the
+`qwerty-ergol` compatibility layer or the layer 4 which is a gaming layer (not
+described here).
+
+## Left to do
+
+- [ ] Replace `png` images with `svg`
+- [ ] Automatize the firmware generations