2018-10-11 09:29:59 +02:00
|
|
|
CIRCUITPYTHON = 'CircuitPython'
|
|
|
|
MICROPYTHON = 'MicroPython'
|
|
|
|
|
|
|
|
|
HID: Support Consumer (media) keys
What a short title for such a massive diff.
This (heavily squashed) commit adds support for Consumer keys such as
volume keys, media play/pause/stop, etc. by exposing four HID devices
over a single USB lane (as opposed to just exposing a keyboard). This
heavily refactors how HIDHelper works due to the new reporting
structure.
Many of the media keys were changed (mostly Keycodes.Media section), but
many (especially anything regarding Application keys) haven't been
touched yet - thus many keycodes may still be wrong. Probably worth
updating those soon, but I didn't get around to it yet. The definitive
list I refered to was
http://www.freebsddiary.org/APC/usb_hid_usages.php, which is basically
copy-pasta from the official USB HID spec at
https://www.usb.org/sites/default/files/documents/hut1_12v2.pdf
(warning: massive PDF, not light reading).
The only known regression this introduces is that instead of 6KRO as the
USB spec usually supports, we can now only have 5KRO (maybe even 4KRO),
for reasons I have yet to fully debug - this seems to be related to the
report having to include the device descriptor _and_ not supporting a
full 8 bytes as it used to. For now I'm willing to accept this, but it
definitely will be great to squash that bug.
This adds descriptor support for MOUSE and SYSCONTROL devices, as of yet
unimplemented.
2018-09-30 00:46:17 +02:00
|
|
|
class HIDReportTypes:
|
|
|
|
KEYBOARD = 1
|
|
|
|
MOUSE = 2
|
|
|
|
CONSUMER = 3
|
|
|
|
SYSCONTROL = 4
|
|
|
|
|
|
|
|
|
2018-10-06 14:59:03 +02:00
|
|
|
class HIDUsage:
|
|
|
|
KEYBOARD = 0x06
|
|
|
|
MOUSE = 0x02
|
|
|
|
CONSUMER = 0x01
|
|
|
|
SYSCONTROL = 0x80
|
|
|
|
|
|
|
|
|
|
|
|
class HIDUsagePage:
|
|
|
|
CONSUMER = 0x0C
|
|
|
|
KEYBOARD = MOUSE = SYSCONTROL = 0x01
|
|
|
|
|
|
|
|
|
|
|
|
# Currently only used by the CircuitPython HIDHelper because CircuitPython
|
|
|
|
# actually enforces these limits with a ValueError. Unused on PyBoard because
|
|
|
|
# we can happily send full reports there and it magically works.
|
|
|
|
HID_REPORT_SIZES = {
|
|
|
|
HIDReportTypes.KEYBOARD: 8,
|
|
|
|
HIDReportTypes.MOUSE: 4,
|
|
|
|
HIDReportTypes.CONSUMER: 2,
|
|
|
|
HIDReportTypes.SYSCONTROL: 8, # TODO find the correct value for this
|
|
|
|
}
|
|
|
|
|
|
|
|
|
HID: Support Consumer (media) keys
What a short title for such a massive diff.
This (heavily squashed) commit adds support for Consumer keys such as
volume keys, media play/pause/stop, etc. by exposing four HID devices
over a single USB lane (as opposed to just exposing a keyboard). This
heavily refactors how HIDHelper works due to the new reporting
structure.
Many of the media keys were changed (mostly Keycodes.Media section), but
many (especially anything regarding Application keys) haven't been
touched yet - thus many keycodes may still be wrong. Probably worth
updating those soon, but I didn't get around to it yet. The definitive
list I refered to was
http://www.freebsddiary.org/APC/usb_hid_usages.php, which is basically
copy-pasta from the official USB HID spec at
https://www.usb.org/sites/default/files/documents/hut1_12v2.pdf
(warning: massive PDF, not light reading).
The only known regression this introduces is that instead of 6KRO as the
USB spec usually supports, we can now only have 5KRO (maybe even 4KRO),
for reasons I have yet to fully debug - this seems to be related to the
report having to include the device descriptor _and_ not supporting a
full 8 bytes as it used to. For now I'm willing to accept this, but it
definitely will be great to squash that bug.
This adds descriptor support for MOUSE and SYSCONTROL devices, as of yet
unimplemented.
2018-09-30 00:46:17 +02:00
|
|
|
HID_REPORT_STRUCTURE = bytes([
|
|
|
|
# Regular keyboard
|
2018-10-06 14:59:03 +02:00
|
|
|
0x05, HIDUsagePage.KEYBOARD, # Usage Page (Generic Desktop)
|
|
|
|
0x09, HIDUsage.KEYBOARD, # Usage (Keyboard)
|
HID: Support Consumer (media) keys
What a short title for such a massive diff.
This (heavily squashed) commit adds support for Consumer keys such as
volume keys, media play/pause/stop, etc. by exposing four HID devices
over a single USB lane (as opposed to just exposing a keyboard). This
heavily refactors how HIDHelper works due to the new reporting
structure.
Many of the media keys were changed (mostly Keycodes.Media section), but
many (especially anything regarding Application keys) haven't been
touched yet - thus many keycodes may still be wrong. Probably worth
updating those soon, but I didn't get around to it yet. The definitive
list I refered to was
http://www.freebsddiary.org/APC/usb_hid_usages.php, which is basically
copy-pasta from the official USB HID spec at
https://www.usb.org/sites/default/files/documents/hut1_12v2.pdf
(warning: massive PDF, not light reading).
The only known regression this introduces is that instead of 6KRO as the
USB spec usually supports, we can now only have 5KRO (maybe even 4KRO),
for reasons I have yet to fully debug - this seems to be related to the
report having to include the device descriptor _and_ not supporting a
full 8 bytes as it used to. For now I'm willing to accept this, but it
definitely will be great to squash that bug.
This adds descriptor support for MOUSE and SYSCONTROL devices, as of yet
unimplemented.
2018-09-30 00:46:17 +02:00
|
|
|
0xA1, 0x01, # Collection (Application)
|
|
|
|
0x85, HIDReportTypes.KEYBOARD, # Report ID (1)
|
|
|
|
0x05, 0x07, # Usage Page (Keyboard)
|
|
|
|
0x19, 224, # Usage Minimum (224)
|
|
|
|
0x29, 231, # Usage Maximum (231)
|
|
|
|
0x15, 0x00, # Logical Minimum (0)
|
|
|
|
0x25, 0x01, # Logical Maximum (1)
|
|
|
|
0x75, 0x01, # Report Size (1)
|
|
|
|
0x95, 0x08, # Report Count (8)
|
|
|
|
0x81, 0x02, # Input (Data, Variable, Absolute)
|
|
|
|
0x81, 0x01, # Input (Constant)
|
|
|
|
0x19, 0x00, # Usage Minimum (0)
|
|
|
|
0x29, 101, # Usage Maximum (101)
|
|
|
|
0x15, 0x00, # Logical Minimum (0)
|
|
|
|
0x25, 101, # Logical Maximum (101)
|
|
|
|
0x75, 0x08, # Report Size (8)
|
|
|
|
0x95, 0x06, # Report Count (6)
|
|
|
|
0x81, 0x00, # Input (Data, Array)
|
|
|
|
0x05, 0x08, # Usage Page (LED)
|
|
|
|
0x19, 0x01, # Usage Minimum (1)
|
|
|
|
0x29, 0x05, # Usage Maximum (5)
|
|
|
|
0x15, 0x00, # Logical Minimum (0)
|
|
|
|
0x25, 0x01, # Logical Maximum (1)
|
|
|
|
0x75, 0x01, # Report Size (1)
|
|
|
|
0x95, 0x05, # Report Count (5)
|
|
|
|
0x91, 0x02, # Output (Data, Variable, Absolute)
|
|
|
|
0x95, 0x03, # Report Count (3)
|
|
|
|
0x91, 0x01, # Output (Constant)
|
|
|
|
0xC0, # End Collection
|
|
|
|
# Regular mouse
|
2018-10-06 14:59:03 +02:00
|
|
|
0x05, HIDUsagePage.MOUSE, # Usage Page (Generic Desktop)
|
|
|
|
0x09, HIDUsage.MOUSE, # Usage (Mouse)
|
HID: Support Consumer (media) keys
What a short title for such a massive diff.
This (heavily squashed) commit adds support for Consumer keys such as
volume keys, media play/pause/stop, etc. by exposing four HID devices
over a single USB lane (as opposed to just exposing a keyboard). This
heavily refactors how HIDHelper works due to the new reporting
structure.
Many of the media keys were changed (mostly Keycodes.Media section), but
many (especially anything regarding Application keys) haven't been
touched yet - thus many keycodes may still be wrong. Probably worth
updating those soon, but I didn't get around to it yet. The definitive
list I refered to was
http://www.freebsddiary.org/APC/usb_hid_usages.php, which is basically
copy-pasta from the official USB HID spec at
https://www.usb.org/sites/default/files/documents/hut1_12v2.pdf
(warning: massive PDF, not light reading).
The only known regression this introduces is that instead of 6KRO as the
USB spec usually supports, we can now only have 5KRO (maybe even 4KRO),
for reasons I have yet to fully debug - this seems to be related to the
report having to include the device descriptor _and_ not supporting a
full 8 bytes as it used to. For now I'm willing to accept this, but it
definitely will be great to squash that bug.
This adds descriptor support for MOUSE and SYSCONTROL devices, as of yet
unimplemented.
2018-09-30 00:46:17 +02:00
|
|
|
0xA1, 0x01, # Collection (Application)
|
|
|
|
0x09, 0x01, # Usage (Pointer)
|
|
|
|
0xA1, 0x00, # Collection (Physical)
|
|
|
|
0x85, HIDReportTypes.MOUSE, # Report ID (n)
|
|
|
|
0x05, 0x09, # Usage Page (Button)
|
|
|
|
0x19, 0x01, # Usage Minimum (0x01)
|
|
|
|
0x29, 0x05, # Usage Maximum (0x05)
|
|
|
|
0x15, 0x00, # Logical Minimum (0)
|
|
|
|
0x25, 0x01, # Logical Maximum (1)
|
|
|
|
0x95, 0x05, # Report Count (5)
|
|
|
|
0x75, 0x01, # Report Size (1)
|
|
|
|
0x81, 0x02, # Input (Data,Var,Abs,No Wrap,Linear,Preferred State,No Null Position)
|
|
|
|
0x95, 0x01, # Report Count (1)
|
|
|
|
0x75, 0x03, # Report Size (3)
|
|
|
|
0x81, 0x01, # Input (Const,Array,Abs,No Wrap,Linear,Preferred State,No Null Position)
|
|
|
|
0x05, 0x01, # Usage Page (Generic Desktop Ctrls)
|
|
|
|
0x09, 0x30, # Usage (X)
|
|
|
|
0x09, 0x31, # Usage (Y)
|
|
|
|
0x15, 0x81, # Logical Minimum (-127)
|
|
|
|
0x25, 0x7F, # Logical Maximum (127)
|
|
|
|
0x75, 0x08, # Report Size (8)
|
|
|
|
0x95, 0x02, # Report Count (2)
|
|
|
|
0x81, 0x06, # Input (Data,Var,Rel,No Wrap,Linear,Preferred State,No Null Position)
|
|
|
|
0x09, 0x38, # Usage (Wheel)
|
|
|
|
0x15, 0x81, # Logical Minimum (-127)
|
|
|
|
0x25, 0x7F, # Logical Maximum (127)
|
|
|
|
0x75, 0x08, # Report Size (8)
|
|
|
|
0x95, 0x01, # Report Count (1)
|
|
|
|
0x81, 0x06, # Input (Data,Var,Rel,No Wrap,Linear,Preferred State,No Null Position)
|
|
|
|
0xC0, # End Collection
|
|
|
|
0xC0, # End Collection
|
|
|
|
# Consumer ("multimedia") keys
|
2018-10-06 14:59:03 +02:00
|
|
|
0x05, HIDUsagePage.CONSUMER, # Usage Page (Consumer)
|
|
|
|
0x09, HIDUsage.CONSUMER, # Usage (Consumer Control)
|
HID: Support Consumer (media) keys
What a short title for such a massive diff.
This (heavily squashed) commit adds support for Consumer keys such as
volume keys, media play/pause/stop, etc. by exposing four HID devices
over a single USB lane (as opposed to just exposing a keyboard). This
heavily refactors how HIDHelper works due to the new reporting
structure.
Many of the media keys were changed (mostly Keycodes.Media section), but
many (especially anything regarding Application keys) haven't been
touched yet - thus many keycodes may still be wrong. Probably worth
updating those soon, but I didn't get around to it yet. The definitive
list I refered to was
http://www.freebsddiary.org/APC/usb_hid_usages.php, which is basically
copy-pasta from the official USB HID spec at
https://www.usb.org/sites/default/files/documents/hut1_12v2.pdf
(warning: massive PDF, not light reading).
The only known regression this introduces is that instead of 6KRO as the
USB spec usually supports, we can now only have 5KRO (maybe even 4KRO),
for reasons I have yet to fully debug - this seems to be related to the
report having to include the device descriptor _and_ not supporting a
full 8 bytes as it used to. For now I'm willing to accept this, but it
definitely will be great to squash that bug.
This adds descriptor support for MOUSE and SYSCONTROL devices, as of yet
unimplemented.
2018-09-30 00:46:17 +02:00
|
|
|
0xA1, 0x01, # Collection (Application)
|
|
|
|
0x85, HIDReportTypes.CONSUMER, # Report ID (n)
|
|
|
|
0x75, 0x10, # Report Size (16)
|
|
|
|
0x95, 0x01, # Report Count (1)
|
|
|
|
0x15, 0x01, # Logical Minimum (1)
|
|
|
|
0x26, 0x8C, 0x02, # Logical Maximum (652)
|
|
|
|
0x19, 0x01, # Usage Minimum (Consumer Control)
|
|
|
|
0x2A, 0x8C, 0x02, # Usage Maximum (AC Send)
|
|
|
|
0x81, 0x00, # Input (Data,Array,Abs,No Wrap,Linear,Preferred State,No Null Position)
|
|
|
|
0xC0, # End Collection
|
|
|
|
# Power controls
|
2018-10-06 14:59:03 +02:00
|
|
|
0x05, HIDUsagePage.SYSCONTROL, # Usage Page (Generic Desktop Ctrls)
|
|
|
|
0x09, HIDUsage.SYSCONTROL, # Usage (Sys Control)
|
HID: Support Consumer (media) keys
What a short title for such a massive diff.
This (heavily squashed) commit adds support for Consumer keys such as
volume keys, media play/pause/stop, etc. by exposing four HID devices
over a single USB lane (as opposed to just exposing a keyboard). This
heavily refactors how HIDHelper works due to the new reporting
structure.
Many of the media keys were changed (mostly Keycodes.Media section), but
many (especially anything regarding Application keys) haven't been
touched yet - thus many keycodes may still be wrong. Probably worth
updating those soon, but I didn't get around to it yet. The definitive
list I refered to was
http://www.freebsddiary.org/APC/usb_hid_usages.php, which is basically
copy-pasta from the official USB HID spec at
https://www.usb.org/sites/default/files/documents/hut1_12v2.pdf
(warning: massive PDF, not light reading).
The only known regression this introduces is that instead of 6KRO as the
USB spec usually supports, we can now only have 5KRO (maybe even 4KRO),
for reasons I have yet to fully debug - this seems to be related to the
report having to include the device descriptor _and_ not supporting a
full 8 bytes as it used to. For now I'm willing to accept this, but it
definitely will be great to squash that bug.
This adds descriptor support for MOUSE and SYSCONTROL devices, as of yet
unimplemented.
2018-09-30 00:46:17 +02:00
|
|
|
0xA1, 0x01, # Collection (Application)
|
|
|
|
0x85, HIDReportTypes.SYSCONTROL, # Report ID (n)
|
|
|
|
0x75, 0x02, # Report Size (2)
|
|
|
|
0x95, 0x01, # Report Count (1)
|
|
|
|
0x15, 0x01, # Logical Minimum (1)
|
|
|
|
0x25, 0x03, # Logical Maximum (3)
|
|
|
|
0x09, 0x82, # Usage (Sys Sleep)
|
|
|
|
0x09, 0x81, # Usage (Sys Power Down)
|
|
|
|
0x09, 0x83, # Usage (Sys Wake Up)
|
|
|
|
0x81, 0x60, # Input (Data,Array,Abs,No Wrap,Linear,No Preferred State,Null State)
|
|
|
|
0x75, 0x06, # Report Size (6)
|
|
|
|
0x81, 0x03, # Input (Const,Var,Abs,No Wrap,Linear,Preferred State,No Null Position)
|
|
|
|
0xC0, # End Collection
|
|
|
|
])
|
|
|
|
|
|
|
|
|
2018-09-03 05:06:53 +02:00
|
|
|
class DiodeOrientation:
|
|
|
|
'''
|
|
|
|
Orientation of diodes on handwired boards. You can think of:
|
|
|
|
COLUMNS = vertical
|
|
|
|
ROWS = horizontal
|
|
|
|
'''
|
|
|
|
|
|
|
|
COLUMNS = 0
|
|
|
|
ROWS = 1
|
Massive refactor largely to support Unicode on Mac
This does a bunch of crazy stuff:
- The ability to set a unicode mode (right now only Linux+ibus or
MacOS-RALT) in the keymap. This will be changeable at runtime soon, to
allow a single keyboard to be able to send table flips and whatever
other crazy stuff on any OS the board is plugged into (something that's
not currently doable on QMK, so yay us?)
- As part of the above, there is now just one user-facing macro for
unicode codepoint submission,
`kmk.common.macros.unicode.unicode_sequence`. Users should never use the
platform-specific macros, partly because they just outright won't work.
There's all sorts of fun stuff in these methods now, thank goodness
MicroPython supports the `yield from` construct.
- Keycode (these should really be renamed Keysym or something) objects
that are intended to not be pressed, or not be released. Right now these
properties are completely ignored if not part of a macro, and it's
probably sane to keep it that way. This was necessary to support MacOS's
"hold RALT while typing the codepoint characters" flow.
- Other refactor-y bits, like moving macro support to `kmk/common`
rather than sitting at the top level of the tree. One day `kmk/common`
may make sense to surface at top level `kmk/`, but that's a discussion
for another day.
2018-10-01 04:33:23 +02:00
|
|
|
|
|
|
|
|
2018-12-05 02:03:13 +01:00
|
|
|
class UnicodeMode:
|
Massive refactor largely to support Unicode on Mac
This does a bunch of crazy stuff:
- The ability to set a unicode mode (right now only Linux+ibus or
MacOS-RALT) in the keymap. This will be changeable at runtime soon, to
allow a single keyboard to be able to send table flips and whatever
other crazy stuff on any OS the board is plugged into (something that's
not currently doable on QMK, so yay us?)
- As part of the above, there is now just one user-facing macro for
unicode codepoint submission,
`kmk.common.macros.unicode.unicode_sequence`. Users should never use the
platform-specific macros, partly because they just outright won't work.
There's all sorts of fun stuff in these methods now, thank goodness
MicroPython supports the `yield from` construct.
- Keycode (these should really be renamed Keysym or something) objects
that are intended to not be pressed, or not be released. Right now these
properties are completely ignored if not part of a macro, and it's
probably sane to keep it that way. This was necessary to support MacOS's
"hold RALT while typing the codepoint characters" flow.
- Other refactor-y bits, like moving macro support to `kmk/common`
rather than sitting at the top level of the tree. One day `kmk/common`
may make sense to surface at top level `kmk/`, but that's a discussion
for another day.
2018-10-01 04:33:23 +02:00
|
|
|
NOOP = 0
|
|
|
|
LINUX = IBUS = 1
|
|
|
|
MACOS = OSX = RALT = 2
|
2018-10-01 05:35:41 +02:00
|
|
|
WINC = 3
|
2018-10-08 11:31:30 +02:00
|
|
|
|
|
|
|
|
|
|
|
class LeaderMode:
|
2018-10-19 10:49:37 +02:00
|
|
|
TIMEOUT = 0
|
|
|
|
TIMEOUT_ACTIVE = 1
|
2018-10-12 04:14:23 +02:00
|
|
|
ENTER = 2
|
|
|
|
ENTER_ACTIVE = 3
|