Skip to content

Added power tracking api #12691

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged
merged 11 commits into from
Sep 29, 2021
Merged

Conversation

purdeaandrei
Copy link
Contributor

@purdeaandrei purdeaandrei commented Apr 25, 2021

Description

This has now been tested on chibios, running on an STM32F446, and atmega32u4, and atmega32u2.

Types of Changes

  • Core
  • Bugfix
  • New feature
  • Enhancement/optimization
  • Keyboard (addition or update)
  • Keymap/layout/userspace (addition or update)
  • Documentation

Issues Fixed or Closed by This PR

Checklist

  • My code follows the code style of this project: C, Python
  • I have read the PR Checklist document and have made the appropriate changes.
  • My change requires a change to the documentation.
  • I have updated the documentation accordingly.
  • I have read the CONTRIBUTING document.
  • I have added tests to cover my changes.
  • I have tested the changes and verified that they work and don't break anything (as well as I can manage).

@purdeaandrei
Copy link
Contributor Author

purdeaandrei commented May 1, 2021

Tested on STM32F446, and atmega32u4, and atmega32u2.

@drashna drashna requested review from tzarc, fauxpark and a team May 9, 2021 03:26
@purdeaandrei purdeaandrei force-pushed the f_added_power_tracking_api branch from 7a5fcda to 7667026 Compare June 21, 2021 19:37
@github-actions github-actions bot removed keymap cli qmk cli command via Adds via keymap and/or updates keyboard for via support documentation keyboard python translation labels Jun 21, 2021
@drashna
Copy link
Member

drashna commented Jun 22, 2021

While the code looks good, "power tracking" doesn't sound right to me.

The point is getting the status from USB, correct? Then maybe "USB Power State" would be more accurate, maybe?

That said, I know that naming stuff is hard. I have some truly atrociously named stuff that has made it into core, so I definitely understand that.

@drashna drashna self-requested a review June 22, 2021 02:36
@stale
Copy link

stale bot commented Aug 6, 2021

Thank you for your contribution!
This pull request has been automatically marked as stale because it has not had activity in the last 45 days. It will be closed in 30 days if no further activity occurs. Please feel free to give a status update now, or re-open when it's ready.
For maintainers: Please label with awaiting review, breaking_change, in progress, or on hold to prevent the issue from being re-flagged.

@purdeaandrei purdeaandrei force-pushed the f_added_power_tracking_api branch from 74f3fc8 to c084d5a Compare August 22, 2021 23:08
@stale stale bot removed the awaiting changes label Aug 22, 2021
@purdeaandrei
Copy link
Contributor Author

@drashna
I have rebased the branch on top of latest develop.
I have also renamed power to usb_power. So for example the main .c file is now quantum/usb_power.c, and the main variable holding the usb power state is called "usb_power_state".
The word 'tracking' is not in the source code content, only in some commit messages, the branch name, and the PR description.

Let me know if any further changes are needed.
Note: I have not yet tested this since the rebase. I will test soon, and I will drop another comment here when that happens.

@drashna
Copy link
Member

drashna commented Aug 23, 2021

Honestly, i'm still not too happy with the naming, as it doesn't really reflect what it is.

usb_device_state_* feels much more accurate of a name for this (and is similar to the LUFA and ChibiOS event names, to boot).

@purdeaandrei
Copy link
Contributor Author

@drashna Renamed as you suggested.

@purdeaandrei
Copy link
Contributor Author

purdeaandrei commented Aug 26, 2021

I re-tested the current version of a branch on an STM32F446-based keyboard.
I set the locklights to output the usb_device_state enum every time it changes.
On connection to a linux pc I observed:
USB_DEVICE_STATE_INIT -> USB_DEVICE_STATE_SUSPEND -> USB_DEVICE_STATE_INIT -> USB_DEVICE_STATE_CONFIGURED
I observed the same as above on connection to an Android phone.

On the computer suspending I observed:
USB_DEVICE_STATE_CONFIGURED -> USB_DEVICE_STATE_SUSPEND

On the computer exiting suspend I observed:
USB_DEVICE_STATE_SUSPEND -> USB_DEVICE_STATE_CONFIGURED

On the 1Amp port of a 'powerzilla' power bank I observed: USB_DEVICE_STATE_INIT -> USB_DEVICE_STATE_SUSPEND
On the 2.1Amp port of the same power bank I ovserved the keyboard staying in USB_DEVICE_STATE_INIT forever.

Note: since I didn't analyze this with a logical analyzer, in theory there could be super fast state transitions that I missed with my eyes.

@drashna drashna requested a review from a team September 11, 2021 02:28
@purdeaandrei purdeaandrei force-pushed the f_added_power_tracking_api branch from 7aadee6 to e4e7de9 Compare September 16, 2021 22:30
@purdeaandrei
Copy link
Contributor Author

Rebased (not cause this PR needed it, but because the dependent 12692 PR had a conflict)

@tzarc
Copy link
Member

tzarc commented Sep 18, 2021

Can you explain the unused configurationNumber parameters?

@purdeaandrei
Copy link
Contributor Author

purdeaandrei commented Sep 18, 2021

@tzarc In general, the configuration number matters to how much power the USB device is allowed to consume, because each USB device could have multiple configurations, only one of which is selected at any point in time (or none if not configured).
Each configuration descriptor has its own ".MaxPowerConsumption", so you could have in theory one configuration that consumes 500mA, and one that consumes only 100mA. At the moment everything is using just one configuration in QMK, so that's why it's unused for now.

One possible usecase in the future would be, if a keyboard has a 500mA-using solenoid driver, it could have one configuration to select 500mA, and another one to select 100mA, and disable the solenoid driver automatically, or set it into a 100mA current-limited mode. So when you plug the keyboard into a normal USB port, or powered hub, you get full solenoid operation, but in an unpowered usb hub, the solenoid is automatically disabled, or in slower current-limited mode.

Or in case of keyboards with high current-consumption backlights, it could throttle the backlight intensity when plugged into a 100mA-only port.

I'm not 100% sure if default HID operating system drivers are smart enough to select the alternative 100mA configuration, when they can't enable the 500mA one, or if they will just disable the USB device, so my specific example may not be a good one, but it's still worth keeping the interface, even if my example doesn't actually work in the real world, just in case we will add multiple-configuration support in the future for other reasons.

@tzarc tzarc merged commit b02a539 into qmk:develop Sep 29, 2021
cadusk pushed a commit to cadusk/qmk_firmware that referenced this pull request Sep 29, 2021
* qmk/develop: (21 commits)
  massdrop alt/ctrl: support saving into nvm (qmk#6068)
  Added power tracking api (qmk#12691)
  Mechlovin Hannah60RGB touch-up (qmk#14646)
  [Core] Fix "6kro enable" and clarify naming (qmk#14563)
  [Keymap] Update to Drashna Code (qmk#14644)
  [Keyboard] add support for Quark_LP (qmk#14552)
  [Keyboard] Update Grandiceps to Rev2 (qmk#14618)
  [Keymap] Jonavin murphpad keymap update (qmk#14637)
  [Keyboard] Updates for Tractyl Manuform config (qmk#14641)
  [Keyboard] Fix end of file issue for Owlab suit80 (qmk#14640)
  [Keyboard] Add support for PaladinPad, Arya pcb and move keyboards by KapCave into their own directory (qmk#14194)
  [Keymap] Keychron Q1 user keymap (qmk#14636)
  Fix for mechlovin/adelais/standard_led/arm/rev4 (qmk#14639)
  convert checkerboards/quark_squared:via rules.mk to Unix line endings (qmk#14638)
  Mechlovin Delphine: add LAYOUT_numpad_6x4 (qmk#14635)
  Move "firmware size check skipped" note to message.mk (qmk#14632)
  [Keymap] fix NKRO - switch to get_mods() and refactor encoder action code (qmk#14278)
  [Keyboard] Yampad VIA support (qmk#14397)
  [Keyboard] Add OwLab Suit80 (qmk#14362)
  [Keymap] arkag userspace/keymap -- new macro and minor preonic keymap change (qmk#14623)
  ...
ptrxyz pushed a commit to ptrxyz/qmk_firmware that referenced this pull request Apr 9, 2022
* Add power tracking API to lufa and chibios targets

* power.c: Pass through power state to the notify function

* power: added notify_power_state_change_user too.

* making it pass the PR linter

* Add a POWER_STATE_NO_INIT state, that we start in before calling power_init();

* Rename *power* to *usb_power*

* removing stray newline

* Rename usb_power* to usb_device_state*

* Update quantum/usb_device_state.h

Co-authored-by: Drashna Jaelre <[email protected]>

* Fix comment

* usb_device_state.h: Don't include quantum.h, only the necessary headers.

Co-authored-by: Drashna Jaelre <[email protected]>
@purdeaandrei purdeaandrei deleted the f_added_power_tracking_api branch September 10, 2022 09:29
BorisTestov pushed a commit to BorisTestov/qmk_firmware that referenced this pull request May 23, 2024
* Add power tracking API to lufa and chibios targets

* power.c: Pass through power state to the notify function

* power: added notify_power_state_change_user too.

* making it pass the PR linter

* Add a POWER_STATE_NO_INIT state, that we start in before calling power_init();

* Rename *power* to *usb_power*

* removing stray newline

* Rename usb_power* to usb_device_state*

* Update quantum/usb_device_state.h

Co-authored-by: Drashna Jaelre <[email protected]>

* Fix comment

* usb_device_state.h: Don't include quantum.h, only the necessary headers.

Co-authored-by: Drashna Jaelre <[email protected]>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants