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

[feature request] Detect and filter power features in selection #271

Open
antis81 opened this issue Jul 12, 2021 · 6 comments
Open

[feature request] Detect and filter power features in selection #271

antis81 opened this issue Jul 12, 2021 · 6 comments

Comments

@antis81
Copy link

antis81 commented Jul 12, 2021

A power feature should only be selectable/visible in the lxqt-powermanaget tool if the hardware/driver supports it.

Expected Behavior

Feature is not selectable/visible in GUI if hardware/driver doesn't support it.

Current Behavior

All features are selectable regardless of their availability.

Possible Solution

Seems implemented in lxqt-leave (via QDbus request?) - the hibernate button is "greyed out". If most/all features can be queried this way it would be great!

Steps to Reproduce (for bugs)

If possible - disable the feature under test. (For "hibernate" -> remove the resume HOOK in /etc/mkinitcpio.conf and reload/reboot).

Context

No action is taken on low battery after 30s timeout info box - battery management is correctly configured. Further investigation revealed that my setup has no hibernation feature. Selecting such feature in lxqt-powermanagement tool leads to no effect (silent error in the background) -> user confusion.

@tsujan FYI: Some time ago I disabled my swap partition (because SSD). Only a guess, but it makes sense hibernation would use that partition by default does it?

System Information

Not relevant here -> LXQt 0.17

@stefonarch
Copy link
Member

stefonarch commented Jul 12, 2021

I just checked my PC with swap partition, hibernation is not greyed out but fails, probably because no resume= parameter is set for the kernel.

lxqt-leave 
systemd: "CanSuspend" = "yes"
systemd: "CanHibernate" = "yes"

Debian (and probably ubuntu) do not use the kernel parameter but a config file for the ramdisk (have to look it up on my laptop), fedora no clue.
Ubuntu has probably still disabled hibernation by default as it often fails, depending on the hardware.
Hibernate can also usa a swapfile.

EDIT: Debian uses this (followed by a sudo update-initramfs -u)

$ cat /etc/initramfs-tools/conf.d/resume 
RESUME=UUID=f7d899f0-86dd-4b50-9a0c-10a818bb4d02


So just rely on systemd statements is probably non enough, checking for resume= parameters is required too.

@tsujan
Copy link
Member

tsujan commented Jul 12, 2021

probably because no resume= parameter is set for the kernel

Yes, with Arch and its derivatives, resume=... is needed in /etc/default/grub and resume hook should be added to /etc/mkinitcpio.conf. Then, GRUB config and initramfs image should be regenerated and a reboot should be done.

So just rely on systemd statements is probably non enough

Probably. But the feature request is valid.

@tsujan
Copy link
Member

tsujan commented Jul 12, 2021

If there's no reliable method for all distros, at least a warning can be added about hibernation somewhere, e.g. as a tooltip: "If you select hibernation, make sure that your system can really hibernate!"

@antis81
Copy link
Author

antis81 commented Jul 12, 2021

@tsujan A reliable method requires a combination to check that ALL preconditions/crieria for hibernation are met. That is:

  1. The interrupt listener is enabled (systemd or some common bus to query the flag).
  2. The permanent storage (not a ramdisk!) is writable.

Now if hibernation is detected available (CanHIbernate=yes) I suggest to error out with a visual message when the write fails. This way it would guide the user to configure their system correectly for hibernation.

@tsujan
Copy link
Member

tsujan commented Jul 12, 2021

@antis81
I'm certain that there are LXQt devs with the required know-how. It isn't my area of coding.

I try to make sure that valid bug reports and feature requests are open and invalid ones are closed. Our bug tracker needs to be organized; otherwise, it'll lose its functionality.

@antis81
Copy link
Author

antis81 commented Jul 12, 2021

@tsujan No need to say mate! :)

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

No branches or pull requests

3 participants