This mode is entered by default after about ~30 seconds of no touches,
and this results in the mouse freezing for a bit on the next touch as
the sensor wakes back up.
According to the datasheet, the sensor typically consumes 2.8mA in
normal idle state, and typical 1uA in the LP1 power state, so we will be
consuming a bit more power.

Instead of skipping first 4 readings, which incurs a slight latency
penalty at the start of a touch event, we clear lastx/lasty values as
touch events end, and check them before computing deltas. This way, at
the start of every touch event, we only lose one potential delta, and
then start tracking right away after that.
It should be noted, that manual delta computation is only used for
multi-finger gesture tracking at the moment, as the Azoteq sensor
provides smooth relative delta values for us in the case that only one
finger is active.

Removing the averaging makes the cursor and scrolling motion feel much
more precise and responsive. There is no longer a 'latency' to it.

The Azoteq sensor gives us a nice delta we can use in the case that
sensor.num_fingers == 1.

No functional changes. Just cleaning up some of the copypasted stuff,
like the register definitions for the trackball sensor. Also made
indentation consistent (2 spaces)

No functional changes. Trackpad motion logic was left as is here, and I
just introduce the new azoteq structs + the function to populate them.
Readability of input processing code benefits greatly from this
structured approach, as there are no longer any magical data shuffling
from a raw byte buffer in there.
Downside is, that we have to swap bytes for 16-bit quantities in the
structs, but that's not too much overhead on a 16MHz MCU.

Here, I actually adjust the hardware parameters, these settings work the
best based on my understanding of Atmel docs, and experimentation.

The key change is to set the clock select parameters to choose a
prescale that divides the IO clock by 8.
In the original implementation, a comment implied that the intent was to
set the prescale to /256, but the actual code just sets the first CS00
bit of TCCR0B, which selects no prescaling.
Now, we explicitly choose a prescale of clock_io/8, which seems to
result in the desired behaviour. The brightness increases and decreases
in equal increments, with no jumps with dead keypresses in between.
There are now 1+8 brightness levels, that is, 'off' + 8 levels of
brightness.
Going any higher than a pwmval of 8 with these settings causes the
backlight to blink, I believe due to overcurrent protection.

This first commit just aims to make the keyboard backlight pwm setup
code a bit more obvious, it's now broken up into sections, but the
original behaviour is intact.
The only functional change is, that each bit is now explicitly set to
the intended value. It's my understanding that clearing a bit like
this:
value = (0 << offset);
does not work. Instead, bitwise AND must be used, along with NOT, like
so:
value &= ~(1 << offset);

It may be possible that this functional change affects behaviour, as
those bits are now explicitly set to the intended value, but the
behaviour observed is unchanged.

Enable USB HID commands to address all 128 display columns

See merge request reform/reform!47

This was clearing the display using the multiple of 6 font width
assumption of the firmware text drawing code, so it didn't clear the
rightmost 2 columns of pixels. Using the direct clear command resolves
this.

The 'xWBIT' now supports addressing the full width, so update the demo
to match it.

The ColumnAddr (0x21) command in matrix_render_direct() was erroneously
setting the column end address to 125 instead of 127, which made it
impossible to address the rightmost two columns of pixels on the display
from USB HID 'WBIT' commands.

The 126 pixel limit exists for text and graphics drawn by the keyboard
firmware to simplify text drawing, since the firmware font width is 6px
per character, and 126 / 6 == 21, a nice round number.
I see no reason to impose this limit on arbitrary bitmap content drawn
by commands from the operating system.

Create all the keyboard V3 layouts (SVG)

See merge request reform/reform!46

release version 2023-07-03

See merge request reform/reform!43

allow setting preprocessor variables from the outside

See merge request reform/reform!42

 - one no longer has to edit files to build different variants of the
   firmwares
 - set SOURCE_DATE_EPOCH to the date of the latest git commit for
   reproducibility
 - allow setting KBD_VARIANT_* from the outside
 - KBD_VARIANT_3_US and KBD_VARIANT_2_US set KBD_VARIANT_QWERTY_US
 - rename KBD_VARIANT_STANDALONE to KBD_MODE_STANDALONE
 - allow setting KBD_VARIANT_STANDALONE from the outside
 - build KBD_VARIANT_2 and KBD_VARIANT_3 with and without KBD_MODE_STANDALONE
   in the gitlab CI
 - allow setting KBD_FW_VERSION from the outside
 - set KBD_FW_REV to R2 for all variants and to R3 for KBD_VARIANT_3
 - rename REFORM_MBREV_R3 to REFORM_MBREV_20_R3
 - rename REFORM_MBREV_25_R1 to REFORM_MBREV_25_R2
 - allow setting REFORM_MOTHERBOARD_REV from the outside
 - pick FW_STRING2 depending on REFORM_MOTHERBOARD_REV
 - allow setting FW_STRING3 from the outside
 - build firmware on CI with git tag name in the version or commit hash

add .gitlab-ci.yml

See merge request reform/reform!41