Notify in CLI if system is incompatible

[13r0ck]

Print out a error message if the system is not supported. Behaviour before this is a success that looks like the power profile was changed, which is incorrect.

[13r0ck]

Do we want rustfmt to pass? It looks like other PRs have merged without that, so if I cargo fmt here it is going to change a lot of stuff

[jacobgkau]

That's up to you/engineering. That check not passing isn't a regression from a QA standpoint since it's already not passing on master.

[jacobgkau]

Before, I did already get an error message that somewhat explained what the problem was if I tried to switch graphics profiles on a non-switchable system.

system76@pop-os:~$ system76-power graphics nvidia
setting graphics to nvidia
daemon returned an error message: "does not have switchable graphics"
system76@pop-os:~$

Now, I get a longer message that may be more human-readable.

system76@pop-os:~$ system76-power graphics nvidia

System76 Power is not supported on this device.
This means that your device is either a desktop or doesn't have both an iGPU and dGPU.
System76 Power's daemon automatically stops on systems like this. There is no need
to uninstall nor any need for further configuration.

system76@pop-os:~$ 

However, this new message is also showing up if I try to switch power profiles (testing on lemp10.) All laptops should work with power profiles, not just the graphics-switchable ones. This change also breaks setting charging profiles (displaying the same message.)

[13r0ck]

I force pushed a change, hows it look now?

[jacobgkau]

Power profiles and charging profiles now work again on non-switchable laptops.

For desktops, do we want to consider also using the get_desktop method/message for charging profiles? Currently, it still returns Not running System76 firmware with charge threshold support.

[jacobgkau]

The "not switchable" string still seems pointless since it will never be displayed, but that's more engineering's discretion.

Desktop:

• system76-power graphics returns a new message instead of functioning like a laptop.
• system76-power profile returns a new message instead of functioning like a laptop.
• system76-power charge-thresholds returns an existing daemon error message.

I noticed in the logs that the GNOME Shell extension still thinks the "balanced" profile is being loaded when it first starts. The top-right menu doesn't include the battery/power drop-down, so not sure what its behavior would be now.

Laptop (switchable):

• system76-power graphics still works.
• system76-power profile still works.
• system76-power charge-thresholds still works.

Laptop (non-switchable):

• system76-power graphics returns a new message instead of the old daemon error message.
• system76-power profile still works.
• system76-power charge-thresholds still works.

[13r0ck]

@jacobgkau

system76-power charge-thresholds returns an existing daemon error message.

That is a good point. I pushed a fix for that. Thank you

[jacobgkau]

Desktop:

• system76-power graphics returns a new message instead of functioning like a laptop.
• system76-power profile returns a new message instead of functioning like a laptop.
• system76-power charge-thresholds returns a new message instead of the old daemon error message.

Laptop (switchable):

• system76-power graphics still works.
• system76-power profile still works.
• system76-power charge-thresholds still works.

Laptop (non-switchable):

• system76-power graphics returns a new message instead of the old daemon error message.
• system76-power profile still works.
• system76-power charge-thresholds still works.

[jacobgkau]

I gave this a quick sanity check since it's been a while.

This is still working as expected on switchable and non-switchable laptops.

Testing in a virtual machine attempting to simulate a desktop, I found that by default, /sys/class/dmi/id/chassis_type was 1 (while the host laptop was 9), which doesn't match the 3 the code is looking for to detect desktops. Looking at DMI documentation, it appears 1 is "other" and 3 is indeed "desktop." In the virtual machine set to 1, I was visually able to switch between power profiles using the GNOME extension, but I got errors doing it on the CLI, which is not a regression.

In order to properly simulate running this on a desktop, I cloned this branch and modified the is_desktop check in graphics.rs to look for 1 instead of 3. After doing that, I saw similar behavior: the power profile was visually able to switch in the GUI, but attempting to switch in the CLI (or check what mode I'm in) now gives the notice that it's not supported. I do think the only reason the menu was showing up in the GUI was because VirtualBox is passing my laptop's battery info through to the VM.

We might be able to better hide the options in the GUI on desktops, but this isn't going to cause any crashes in the GUI (and it sounds like profiles weren't properly functioning on desktops anyway, from this PR's initial description).

Edit: @XV-02 did confirm that the GUI menu doesn't show up at all on desktops by default.

[CodeMan99]

Behaviour before this is a success that looks like the power profile was changed, which is incorrect.

Is the "success" actually incorrect? I'm currently trying to debug what seems to be a hardware issue. Compiling a personal project caused hardware instability if I ran sudo system76-power profile performance. Compiling the same project after sudo system76-power profile battery was much slower, but stable.

OS: Pop!_OS 22.04 LTS x86_64
Host: Thelio Mira thelio-mira-b4.1
Kernel: 6.6.10-76060610-generic
Uptime: 8 mins
Packages: 1883 (dpkg), 33 (flatpak)
Shell: bash 5.1.16
Resolution: 1920x1200, 1920x1200
DE: GNOME 42.5
WM: Mutter
WM Theme: Pop
Theme: Pop-dark [GTK2/3]
Icons: Pop [GTK2/3]
Terminal: alacritty
CPU: Intel i9-14900K (32) @ 5.700GHz
GPU: Intel Device a780
GPU: AMD ATI 03:00.0 Device 7480
Memory: 3255MiB / 64063MiB

I'm now unsure what profile is active on my machine.

[mmstick]

Power profiles do work on desktops, yes.