Skip to content
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

[Bug] Slave half RGB keeps on after computer was powered off #22269

Open
2 tasks
klesh opened this issue Oct 14, 2023 · 9 comments
Open
2 tasks

[Bug] Slave half RGB keeps on after computer was powered off #22269

klesh opened this issue Oct 14, 2023 · 9 comments

Comments

@klesh
Copy link
Contributor

klesh commented Oct 14, 2023

Describe the Bug

The left half is the slave while the right half is mater.

  • when the computer (win11) is suspended, both halves would turn off with RGB_DISABLE_WHEN_USB_SUSPENDED enabled
  • when the computer is turned off, the left/slave half keeps on
  • the blue screen from the background indicates the monitor had no input signal and the computer was turned off completely

image

Keyboard Used

https://github.com/klesh/vial-qmk/tree/vial/keyboards/pskeeb3_cherry_hotswap

Link to product page (if applicable)

No response

Operating System

Window11

qmk doctor Output

Ψ QMK Doctor is checking your environment.
Ψ CLI version: 1.1.1
Ψ QMK home: /home/klesh/Projects/klesh/vial-qmk
Ψ Detected Linux (WSL, Ubuntu 22.04.3 LTS).
Ψ Git branch: vial
Ψ Repo version: 0.22.10
⚠ Git has unstashed/uncommitted changes.
Ψ - Latest vial: 2023-10-12 22:33:58 +0800 (3cc2b6392b) -- refactor: rename all pids and names
Ψ - Latest upstream/master: 2023-10-04 03:17:01 -0700 (6e93b59f61) -- Monstargear XO87 Soldered: correct layout data (#22199)
Ψ - Latest upstream/develop: 2023-10-04 10:17:45 +0000 (a0805eda18) -- Merge remote-tracking branch 'origin/master' into develop
Ψ - Common ancestor with upstream/master: 2023-10-04 03:17:01 -0700 (6e93b59f61) -- Monstargear XO87 Soldered: correct layout data (#22199)
Ψ - Common ancestor with upstream/develop: 2023-10-04 03:17:01 -0700 (6e93b59f61) -- Monstargear XO87 Soldered: correct layout data (#22199)
Ψ All dependencies are installed.
Ψ Found arm-none-eabi-gcc version 10.3.1
Ψ Found avr-gcc version 5.4.0
Ψ Found avrdude version 6.3-20171130
Ψ Found dfu-programmer version 0.6.1
Ψ Found dfu-util version 0.9
Ψ Submodules are up to date.
Ψ Submodule status:
Ψ - lib/chibios: 2023-04-15 13:48:04 +0000 --  (11edb16109)
Ψ - lib/chibios-contrib: 2023-07-17 11:39:05 +0200 --  (da78eb37)
Ψ - lib/googletest: 2021-06-11 06:37:43 -0700 --  (e2239ee6)
Ψ - lib/lufa: 2022-08-26 12:09:55 +1000 --  (549b97320)
Ψ - lib/vusb: 2022-06-13 09:18:17 +1000 --  (819dbc1)
Ψ - lib/printf: 2022-06-29 23:59:58 +0300 --  (c2e3b4e)
Ψ - lib/pico-sdk: 2023-02-12 20:19:37 +0100 --  (a3398d8)
Ψ - lib/lvgl: 2022-04-11 04:44:53 -0600 --  (e19410f)
Ψ QMK is ready to go, but minor problems were found

Is AutoHotKey / Karabiner installed

  • AutoHotKey (Windows)
  • Karabiner (macOS)

Other keyboard-related software installed

No response

Additional Context

I would like some input, and pointers to help me debug the problem.

@klesh klesh changed the title [Bug] Slave half RGB keeps on after power off [Bug] Slave half RGB keeps on after computer was powered off Oct 14, 2023
@drashna
Copy link
Member

drashna commented Nov 10, 2023

Use the QMK repo, not the vial repo.

Can't reporduce this locally with similarly specced board (bastardkb dilemma), so high chance that this is a vial specific bug.

@BionicRiddle
Copy link

BionicRiddle commented Nov 10, 2023

May not be related but i have the same issue with my Sofle. A couple of days ago i update merged master into my personal repo witout changing anything major. The issue arose somewhere between end of July and 3 days ago, or if the cause is the same, 1 month ago. Will probably look into it this weekend. Using a RP2040

@BionicRiddle
Copy link

Hmm, so far i have not found the cause the issue. The OLED sleep sync appears to be broken aswell. Will probably look into what the RT-OS does when suspending and look into if the Aug 27 Breaking Change was the cause.

@klesh
Copy link
Contributor Author

klesh commented Nov 11, 2023

@drashna @BionicRiddle Thanks for taking a look. Will try the qmk repo.

@BionicRiddle
Copy link

BionicRiddle commented Nov 11, 2023

Soo... After messing around a few hours i found the offending commit/issue ( #21287 ).

Go into tmk_core/protocol/chibios/chibios.c and change this line:

if ((USB_DRIVER.status & USB_GETSTATUS_REMOTE_WAKEUP_ENABLED) && suspend_wakeup_condition()) {

to this:

if (suspend_wakeup_condition()) {

See if that changes anything for you. I won't bother looking into why that was causing the issue as i would like to avoid messing with the USB standard. Perhaps @purdeaandrei knows?

@drashna
Copy link
Member

drashna commented Nov 11, 2023

In theory, that shouldn't matter, as suspend is never called on the slave side, and rgb matrix syncs the suspend state, so it should be turning off the rgb.

Though, I think I did miss this part:

when the computer is turned off, the left/slave half keeps on

Unfortunately, this just causes issues for split boards, in general. Especially if you're not using VBUS detection for master/slave detection (the default is split usb detect, not vbus detection on ARM). And if you're using a blackpill, you'd have to mod the controller to add support for this.

Enabling SPLIT_WATCHDOG_ENABLE may help with this, though.

@sigprof
Copy link
Contributor

sigprof commented Nov 12, 2023

Go into tmk_core/protocol/chibios/chibios.c and change this line:

if ((USB_DRIVER.status & USB_GETSTATUS_REMOTE_WAKEUP_ENABLED) && suspend_wakeup_condition()) {

to this:

if (suspend_wakeup_condition()) {

What if you change that line to this instead:

            if (suspend_wakeup_condition() && (USB_DRIVER.status & USB_GETSTATUS_REMOTE_WAKEUP_ENABLED)) {

The issue is that suspend_wakeup_condition() calls matrix_scan(), and this is where the communication between halves is handled, therefore the RGB matrix suspend state might not be reaching the slave half if the master half goes into the USB suspend state with the remote wakeup disabled. Changing the order of conditions would ensure that the master half would continue to call matrix_scan() even in that state (even though the result of the wakeup check would be useless).

@BionicRiddle
Copy link

Yea, that dit it... It feels a bit like a curse, to be honest. I've submitted a new #22457 and will go throught it and check, then submitt a PR.

@skylupin03
Copy link

Even when the PC was turned off, I got a key input and controlled the other circuit such as the LED light.
From ver0.22.0(8/29)..
I had a hard time because the matrix didn't work when the PC turned off.
I don't know in depth, but I've got a rough idea why.
Thank you.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

5 participants