-
-
Notifications
You must be signed in to change notification settings - Fork 117
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
LED does not turn on when turning off PC #792
Comments
Hi |
I see no sign that the signal was sent to HyperHDR so that it could cleanly close the LED drivers. The log ends abruptly. And we have handlers for SIGINT, SIGTERM, SIGPIPE etc. Are the LEDs not turned off in these 2 cases, also when you run HyperHDR from the menu and not from the console? |
The console was used to create a log files. But I checked right now, the leds do not turn off if the application is launched from the start menu or from autorun |
Without signals that are not sent to HyperHDR, we are unable to ensure proper driver shutdown. There is no such problem on Debian (e.g. Raspberry Pi OS). You can try a workaround and run HyperHDR as a user service, maybe at least it closes properly. |
okay. if i run it like this, there is no icon in the tray and there is no system screen capture in the dashboard upd: |
This log is from journalctl after you close the system or logged out the user? |
from web (http://localhost:8090/#logs) the leds don't work at all now |
Inside service you may need --verbose --desktop flags and reload it later. Pipewire wont work if console app (daemon) is detected as in your logs. I don't know if it makes sense to continue debugging it. Signals such as SIGINT or SIGTERM are the basis without which the application cannot function properly and it is not visible that they are sent to it. And it works on other systems. What I could have improved, I did (response to Pipewire's stream pause event which previously generated an exception) |
Compare logs to Kubuntu: There is a clean exit on user log out action. Which is missing on Fedora in your logs. I run it something like that: /usr/bin/hyperhdr > /home/...log.txt So I guess it's Fedora specific behaviuor unless I'm missing something. |
okay. my /usr/bin/hyperhdr > hdr.log looks like the same thing |
LED was powered off in this case? |
yes, if I kill the program myself, it turns off the LED |
journalctl -xe | grep hyperhdr - https://pastebin.com/vEwLxPL5 idk how the daemon doesn't want to work it seems |
I didnt kill the program but I simply logged-out. Try to repeat the same procedure ('/usr/bin/hyperhdr > hdr.log') for user log-out and power off. BTW do you have 'restore apps' enabled in the KDE configurations ( https://askubuntu.com/questions/428805/prevent-kubuntu-from-remembering-previous-session ) ? Disable it. |
https://pastebin.com/TnzZaUDp |
Maybe there is still a crash? Nothing in the journalctl? Could you disable Pipewire capturing (in the grabber configuration), set a background effect instead and repeat it. |
(leds not disabled) |
Thank you. So it seems Fedore doesn't close the app on the user logout. |
The patch for crash on Pipewire stream pause is included in #800 The problem of not properly closing the app by your configuration of Fedora is not an HyperHDR issue. |
So, does that mean I should wait for the LED to be forced to turn off on the controller’s side ? Btw, the problem seems to have gotten worse and it seems to happen sometimes even if shutdown via the start menu 😟 |
To proper shutdown HyperHDR needs to be notified about closing. If it doesn't happen as in your logs then probably it is killed just like that so LEDs remain on last colors that were sent. I suspect OS encounters some problem maybe even crash during shutdown/logout and that prevents it from properly apps closing. I could not repeat that behaviour on KUbuntu which uses KDE/plasma as in your configuration. |
Bug report, debug log and your config file (FULL LOGS ARE MANDATORY)
hdr.log
config.json
Steps to reproduce
use ctrl+shift+del menu to turn off/restart pc
What is expected?
turn off all leds
What is actually happening?
The app crashes and doesn't turn off the LED properly
System
HyperHDR Server:
note
reference to: awawa-dev/HyperSerialEsp8266#39 (reply in thread)
The text was updated successfully, but these errors were encountered: