If the user has missed the step about setting up their account
with the right group membership, they would get a cryptic failure
from stty, so catch this and explain the problem.
This should never happen, but could if something goes badly wrong
in the device detection code, e.g. someone changing it in a way
which caused extra output on STDOUT.
7bd2e9fbb7/udev/99-hdmi2usb-mm-blacklist.rules (L4)
says:
It should be enough to set ID_MM_DEVICE_IGNORE:="1" but it seems many
versions of modem manager have a bug which makes them ignore that value.
Setting ID_MM_CANDIDATE:="0" has the same effect but is an "internal
implementation detail" of modem manager.
so set both to be safe. Also use := rather than =, in order to prevent
any later rules from overriding the settings.
Several people have reported difficulty flashing firmware on macOS High Sierra because the
device port filename doesn't match the serial number from system_profiler. In particular,
system_profiler would return a string ending in `E` whereas the device filename would have
a `1`. This change adds a check for that filename explictily.
I also corrected the location_id fallback (the substring should have been just 3
characters long, not 4), and it works properly on my system if I make the device shortname
7 characters long, and the filename reverts to using the location id instead.
Last, I added one more check, simply listing the filenames, and searching for a match for
the string `kbio01`, which should be present (although in one case, it wasn't).
It's easier for most people to interpret numbers in decimal than hexadecimal; adding this
option to avr-nm prints out the sizes in the size_map in a more intuitive format.
These macros were copied and pasted, I'm guessing from the USB HID Usage Tables document,
where this keycode is identified with a parenthetical, unlike all of the others around it:
`AC Download (Save Target As)`. When automatically converted into a preprocessor macro, it
gets a trailing underscore and an argument, which is not what we want.
This change won't actually fix anything that's currently broken, but it might matter
someday.
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>
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>
Instead of implementing the HID adaptors within Kaleidoscope, provide an API
only (by marking the symbols `extern`). For the sake of backwards compatibility,
pull in `Kaleidoscope-HIDAdaptor-KeyboardioHID`, a new shim library implementing
the status quo.
Signed-off-by: Gergely Nagy <algernon@keyboard.io>
Instead of using `Keyboard.begin` directly, use
`kaleidoscope::hid::initializeKeyboard`. While there, also initialize
`ConsumerControl` and `SystemControl` the same way.
Signed-off-by: Gergely Nagy <algernon@keyboard.io>
Use `static_assert` instead of `#error` to report an API mismatch, resulting in
a much more informative error message.
Thanks to @cdisselkoen for the request, and @noseglasses for the `static_assert`
idea!
Signed-off-by: Gergely Nagy <algernon@keyboard.io>
As we guarantee backwards compatibility throughout a major version, it helps if
we have that version available, so plugins / sketches can check if they are
compatible, and issue a helpful error if they are not. As further convenience,
defining `KALEIDOSCOPE_REQUIRED_API_VERSION` before including `Kaleidoscope.h`
will result in a check being done by Kaleidoscope, and an error printed if it
does not match the API shipped.
Signed-off-by: Gergely Nagy <algernon@keyboard.io>