We are moving towards including the Adaptor from the Hardware library, so we
need not pull them in from user sketches (or from core).
Signed-off-by: Gergely Nagy <algernon@keyboard.io>
With this change, Qukeys reads DualUse key defs from the keymap, and treats them as
Qukeys, within the limitations of normal DualUse keys. Primary keycodes can only be
unmodified, basic keys, and alternate keycodes can only be modifiers or layer-switch
keys.
At some point, we want to remove the default include, so start including the
extra library in the examples.
Signed-off-by: Gergely Nagy <algernon@keyboard.io>
As this is a generic plugin, for keyboards that do not have LEDs, don't tie it
to LEDControl, and don't provide a `toggleLEDs` method. Instead, show an example
how to achieve the same thing from the sketch.
Signed-off-by: Gergely Nagy <algernon@keyboard.io>
At least on Linux, for a device to be considered capable of waking the host up,
it must be a boot keyboard. As we do not (yet) support a boot keyboard, we fake
one. An USB node that does nothing else than report itself as a boot keyboard,
and does the minimum amount of work to get recognised as such.
Because of this, Linux - and hopefully the other OSes too - will consider the
whole device capable of waking up the host.
This addresses keyboardio/Kaleidoscope#237, if all goes well.
Signed-off-by: Gergely Nagy <algernon@keyboard.io>
This macro allows the definition of the LayerCount variable and the
keymaps[] array together. It shouldn't break old sketches, but this is
probably not all that's necessary; LayerCount still doesn't get
initialized outside the macro.
This file is meant to be included in sketch files in order to make
data available to Kaleidoscope functions. In particular, the size of
the keymaps[] array (i.e. the number of defined layers), which is
needed in order to prevent reading uninitialized memory past the end
of that array due to Key_KeymapNext_Momentary.
This took some trial and error to figure out, but once I determined
that the example sketches were being built, I made this change to keep
the build working. Hopefully this will satisfy Travis-CI.
Use `Kaleidoscope.use` and `Kaleidoscope.useEventHandlerHook` instead of the
deprecated `USE_PLUGINS` and `event_handler_hook_use` interfaces.
Signed-off-by: Gergely Nagy <kaleidoscope@gergo.csillger.hu>
Use `Kaleidoscope.use` and `Kaleidoscope.useEventHandlerHook` instead of the
deprecated `USE_PLUGINS` and `event_handler_hook_use` interfaces.
Signed-off-by: Gergely Nagy <kaleidoscope@gergo.csillger.hu>
Use `Kaleidoscope.use`, `Kaleidoscope.useEventHandlerHook`, and
`Kaleidoscope.useLoopHook` instead of the deprecated `USE_PLUGINS`,
`event_handler_hook_use` and `loop_hook_use` interfaces.
Signed-off-by: Gergely Nagy <kaleidoscope@gergo.csillger.hu>
Use `Kaleidoscope.use` and `Kaleidoscope.useEventHandlerHook` instead of the
deprecated `USE_PLUGINS` and `event_handler_hook_use` interfaces.
Signed-off-by: Gergely Nagy <kaleidoscope@gergo.csillger.hu>
Use `Kaleidoscope.use` and `Kaleidoscope.useEventHandlerHook` instead of the
deprecated `USE_PLUGINS` and `event_handler_hook_use` interfaces.
Signed-off-by: Gergely Nagy <kaleidoscope@gergo.csillger.hu>
Use `Kaleidoscope.use`, `Kaleidoscope.useEventHandlerHook`, and
`Kaleidoscope.useLoopHook` instead of the deprecated `USE_PLUGINS`,
`event_handler_hook_use`, and `loop_hook_use` interfaces.
Signed-off-by: Gergely Nagy <kaleidoscope@gergo.csillger.hu>
As `USE_PLUGINS` and `loop_hook_use` are getting deprecated, use the newer APIs:
`Kaleidoscope.use` and `Kaleidoscope.useLoopHook`.
Signed-off-by: Gergely Nagy <kaleidoscope@gergo.csillger.hu>
Use `Kaleidoscope.use`, `Kaleidoscope.useEventHandlerHook`, and
`Kaleidoscope.useLoopHook` instead of `USE_PLUGINS`, `event_handler_hook_use`,
and `loop_hook_use`, which are getting deprecated.
Signed-off-by: Gergely Nagy <kaleidoscope@gergo.csillger.hu>
`USE_PLUGINS` and `loop_hook_use` are deprecated, use `Kaleidoscope.use` and
`Kaleidoscope.useLoopHook` instead.
Signed-off-by: Gergely Nagy <kaleidoscope@gergo.csillger.hu>
Use `Kaleidoscope.use` and `Kaleidoscope.useEventHandlerHook` instead of the
obsolete `USE_PLUGINS` and `event_handler_hook_use` interfaces.
Signed-off-by: Gergely Nagy <kaleidoscope@gergo.csillger.hu>
Use `Kaleiodscope.use` instead of `USE_PLUGINS` in both README and the example.
Also create a separate "Plugin properties" section in the former.
Signed-off-by: Gergely Nagy <algernon@madhouse-project.org>
Make it clear that layer keys are considered modifiers by the plugin.
While in that area, use `Kaleidoscope.use` instead of the now deprecated
`USE_PLUGINS` macro.
Signed-off-by: Gergely Nagy <algernon@madhouse-project.org>
This is a little bit user-friendlier, more efficient (both space- and
performance-wise).
Fixes#2.
Signed-off-by: Gergely Nagy <algernon@madhouse-project.org>
To make things friendlier to the end-user, add an `.activate()` alias to
`.nextState()`, and document that.
Fixes#3.
Signed-off-by: Gergely Nagy <algernon@madhouse-project.org>
Updated the code to conform to the latest style guide. And added a bit of
documentation too, while there.
Signed-off-by: Gergely Nagy <algernon@madhouse-project.org>
Use astyle 3.0 (included in Kaleidoscope-Plugin) to apply styling, instead of
whatever came with Debian Stretch.
Signed-off-by: Gergely Nagy <algernon@madhouse-project.org>
Rearranged both in style, and in naming conventions to match the Kaleidoscope
Style Guide, and please the linter too.
Signed-off-by: Gergely Nagy <algernon@madhouse-project.org>
There are some issues here and there, and this saw minimal testing only. But it
is okay-ish for an initial attempt.
Signed-off-by: Gergely Nagy <algernon@madhouse-project.org>
This method uses the EEPROM only to augment the PROGMEM keymap: if EEPROM is
transparent, then PROGMEM is used. As such, the keymap in EEPROM is only an
overlay in this case.
Signed-off-by: Gergely Nagy <algernon@madhouse-project.org>
The keymap.transfer command is only useful if we have both PROGMEM & EEPROM
keymaps, which will rarely be a case, and likely only temporarily, too. As such,
lift that out of the `focusKeymap` function, into its own. This makes the
command optional, and can save us some 140 bytes of program space (even more if
documentation is enabled).
Signed-off-by: Gergely Nagy <algernon@madhouse-project.org>
This adds the Kaleidoscope::AlphaSquareSymbols namespace, for symbols that fall
outside of the normal alphanumerics. The first such symbol is `λ`.
Fixes#3.
Signed-off-by: Gergely Nagy <algernon@madhouse-project.org>
Allows other plugins to request a slice of EEPROM, and returns the starting
location of their area. Makes a CRC out of the slice sizes, so that it can
detect when the EEPROM and the Sketch become out of sync. Handling that case is
left up to the user.
As a consequence, we no longer reserve a big chunk of EEPROM for the keymap,
that just becomes another slice of it, which can be anywhere. This makes it a
bit harder to adjust the size of it, but as far as this plugin goes, playing
with the EEPROM layout will usually mean having to update its contents from
scratch, anyway.
Signed-off-by: Gergely Nagy <algernon@madhouse-project.org>
There are - and will be - better ways to turn a plugin on and off, than
having to implement on/off methods on the plugin itself. As such, remove
them.
Fixes#3.
Signed-off-by: Gergely Nagy <algernon@madhouse-project.org>
The on/off functions were meant to make it easier to experiment, but
there are - and will be - better ways to achieve the same thing. So
remove them, lest anyone ends up using them.
Fixes#2.
Signed-off-by: Gergely Nagy <algernon@madhouse-project.org>
The new singleton objects implements a LED mode where each pressed key
will light up the appropriate symbol on the LEDs, on the side it was
pressed on. We use different timers for each half.
Signed-off-by: Gergely Nagy <algernon@madhouse-project.org>
If we want to allow plugins to implement EEPROM storage, it is best if we don't
do anything with EEPROM in the core firmware. As such, remove the
`Layer.defaultLayer` call from `Kaleidoscope.setup`.
With that gone, the `keymap_count` argument is obsolete, so drop it from
`Kaleidoscope.setup()` - but we keep an temporary `setup()` with the old arity,
so that plugins can be updated at a slower pace.
Signed-off-by: Gergely Nagy <algernon@madhouse-project.org>
Renamed the library to Kaleidoscope-LED-ActiveModColor, and followed up with
other renames.
Signed-off-by: Gergely Nagy <algernon@madhouse-project.org>
Renamed the library to Kaleidoscope-GhostInTheFirmware, and followed up with
other renames.
Signed-off-by: Gergely Nagy <algernon@madhouse-project.org>
Instead of just switching to a layer, make it a macro. The macro will toggle the
layer and the LED effect.
Signed-off-by: Gergely Nagy <algernon@madhouse-project.org>
The example does not use LEDs, drop the key, lest we'd need to pull in the
Keyboardio-LEDControl plugin, too.
Signed-off-by: Gergely Nagy <algernon@madhouse-project.org>
Moves the LED control code, along with the built-in effects into the
Keyboardio-LEDControl plugin.
Signed-off-by: Gergely Nagy <algernon@madhouse-project.org>
This function registers the layer handler, move it up, before Keyboardio.use, so
it will have a chance to run before the other handlers.
Signed-off-by: Gergely Nagy <algernon@madhouse-project.org>
To make keymaps look nicer, easier to read, introduce the `___` and `XXX`
aliases. The former is an alias to `Key_Transparent`, the latter to `Key_NoKey`.
The `genetare_keymaps.pl` tool was updated to support these, too, with the
additional functionality, that all strings that are made up entirely of
underscore or Xes, and are two or more characters long, will be treated as
`___`/`XXX`, respectively. This makes it possible to space keys in a nicer way
in the source layout files.
Signed-off-by: Gergely Nagy <algernon@madhouse-project.org>
Instead of having a primary and a temporary layer, store the state of at
most 32 layers in a bitfield. These can be individually turned on and
off, and key lookup starts from the top, and goes downwards until the
default layer to find a non-transparent key.
This allows one to reuse a partially transparent layer: set the default,
and the transparent parts will be reused. The numpad layer was updated
accordingly.
Having an interface to the layer switching things also makes it easier
to build other behaviour on top of these.
As part of the rework, layer handling was moved to a separate file, and into its
own, full-blown handler. Furthermore, we now use a single bit for all keymap
events.
Signed-off-by: Gergely Nagy <algernon@madhouse-project.org>
We can't register hooks from constructors, because there is no guaranteed order
in which the objects will be created. So it may well happen that the Keyboardio
object gets created later, and zeroes out everything. Or it gets created first,
and registers the default handler as the first one, making all the others
pointless.
Instead, we create a KeyboardioPlugin class, that has a `begin` method. This is
responsible for setting up the hooks and whatnot. To make things simpler (for
some values of simple), a `Keyboardio.use` method is introduced, which, when
given a NULL-terminated list of plugin object pointers, will call the begin
method of each.
All LED effects and other plugins that used to register a static object now use
an extern, and had their initialization moved to the `begin` method.
The end result is not the nicest thing, but it works. We can try figuring out
something nicer later.
Signed-off-by: Gergely Nagy <algernon@madhouse-project.org>
The main thing here is `Macros_::play`, which takes a list of bytes from
PROGMEM, and plays a macro. The array is always a command, followed by
arguments, and the size of the argument depends on the command: key presses and
releases take a 16-bit argument, and the event is injected into the event
handler flow. Waiting and interval change take a 8-bit time. Helpers are
provided to make it a little bit easier to construct a macro.
Of course, the `macroAction` method may do any other side effects, and is not
restricted to returning a sequence of commands.
Fixes#5.
Signed-off-by: Gergely Nagy <algernon@madhouse-project.org>
Instead of hardcoding the macro actions into the core firmware, use a
`macroAction` function that is marked weak. This makes it possible to override
the function from Sketches, and implement the handlers there.
While there, also made sure that the `macroAction` is always called, with
`keyState` argument appropriately set. With this, macro actions can trigger on
keyup, or while held, or anytime the implementor wants, not just on keypress.
Signed-off-by: Gergely Nagy <algernon@madhouse-project.org>
Because the animation saves if it has been run, it may do so during
factory testing. But running it every time is annoying, too. So as per
@obra's request, the code for the animation is kept, but removed from
the default sketch.
Signed-off-by: Gergely Nagy <algernon@madhouse-project.org>
When one adds or removes a layer from a keymap, the keymap size has to
be adjusted in the call to `Keyboardio.setup()`. This is easy to forget,
so as a helper, introduce `KEYMAP_SIZE`, a macro that automatically
computes the size at compile time.
This way, one does not need to remember to update the size anywhere.
Signed-off-by: Gergely Nagy <algernon@madhouse-project.org>
The mousekeys are not specific to the Model01, name it after Keyboardio
instead, as suggested by @obra.
Signed-off-by: Gergely Nagy <algernon@madhouse-project.org>
The primary reason for the move is to be able to disable mouse keys
completely, and not even compile them in. For this to work, it needs to
be in a separate library, otherwise it will always be included, even if
not active.
So, this patch turns mouse-keys into a simple plugin, included with the
core firmware! This makes the default event handler a bit simpler, the
code marginally smaller, and the feature completely optional.
Signed-off-by: Gergely Nagy <algernon@madhouse-project.org>
With the BootAnimation not functioning as a LED effect anymore, ship a
dedicated off effect.
Signed-off-by: Gergely Nagy <algernon@madhouse-project.org>
Having the boot animation as a LED effect, making it function as an
"off" state, while a novel idea, is confusing. For this reason, make it
just a simple function we can call from the Sketch's `setup()` method.
Signed-off-by: Gergely Nagy <algernon@madhouse-project.org>
Recreate LEDControl as a class with pluggable parts, similar in vein to
the event handler and loop hooks. Except in this case, only the current
effect runs at any one time, the current one.
All existing effects were separated out into plugins, and the default
firmware example was updated too. All of them were pretty trivial, save
the special NumLock effect: that one also installs a loop hook, and
switches the LED mode if need be. Its setup function also skips to the
next effect, if the mode was selected manually.
Behaviour should be the same as before, but LED effects are now
pluggable, at the cost of some code and data size increase.
Signed-off-by: Gergely Nagy <algernon@madhouse-project.org>
This moves the layouts to the sketch directory, so that other sketches
can easily use a different keymap. In the process, not much had to be
changed, and a number of things still remain in the core that assume the
default keymap (such as the NUMPAD_KEYMAP thing in LEDControl.cpp), but
this is a first step.
The downside is that the keymap is no longer static, because that would
conflict with the extern declaration, and the NUMPAD_KEYMAP is a byte,
instead of a compile-time define.
Alltogether, the difference is small enough to be acceptable.
Signed-off-by: Gergely Nagy <algernon@madhouse-project.org>
Moved the library sources into src/, and the sketch into examples/. This
makes it easier to use the project as a library, and the default
firmware sketch shows up in Arduino IDE's Files/Examples menu. This in
turn, has a very neat side effect: an end user can start from this
example, and when they save it, it will be saved to their Sketchbook,
and the library can be updated independently, without having to worry
about conflicts.
Having the Sketch separate from the sources also paves the way for
moving the keymap there.
As far as Arduino IDE dependencies go: this requires Arduino IDE 1.6.7+,
the same minimum version required previously.
Signed-off-by: Gergely Nagy <algernon@madhouse-project.org>
Gergely Nagy
Michael Richters
Simon Lydell
Gergely Nagy
Jesse Vincent
Ben Gemperline
Gergely Nagy
Selene Scriven
Craig Disselkoen
Jesse Vincent