Add support for setting up the backlight

[crisidev]

$ dbus-send --system --print-reply --dest=com.tux.Tailor /com/tux/Tailor com.tux.Tailor.Backlight.GetBacklightPercentage
method return time=1681388674.870710 sender=:1.47503 -> destination=:1.47571 serial=8 reply_serial=2
   byte 100

$ dbus-send --system --print-reply --dest=com.tux.Tailor /com/tux/Tailor com.tux.Tailor.Backlight.SetBacklightPercentage uint32:20
method return time=1681388658.398747 sender=:1.47503 -> destination=:1.47560 serial=7 reply_serial=2

$ dbus-send --system --print-reply --dest=com.tux.Tailor /com/tux/Tailor com.tux.Tailor.Backlight.GetBacklightPercentage
method return time=1681388674.870710 sender=:1.47503 -> destination=:1.47571 serial=8 reply_serial=2
   byte 20

[AaronErhardt]

I don't know if that's a common use case, but can't we implement the same heuristics as the LED control detection in tuxedo_sysfs? This would mean we have a Vec of device specific controllers so it can be zero or more than one if that's the case. Also, we should probably get rid of the amdgpu specific filtering, which might be easier if we query all potential files as well.

[AaronErhardt]

Also, similar to the LED controls, there should an options for an empty backlight profile that does nothing. I would prefer to set the brightness through the GNOME quick-settings most of the time.

[crisidev]

What I find convenient is the fact that tuxedo-control-center sets the brighness when the profile switches because of an event like the power cord is connected. This something I would like to make happen with tuxedo-rs as well.

We can for sure implement something more similar to the Led controllers and have the default without a backlight configuration.

[AaronErhardt]

What I find convenient is the fact that tuxedo-control-center sets the brighness when the profile switches because of an event like the power cord is connected. This something I would like to make happen with tuxedo-rs as well.

I think this should only require a connection to some DBUS service. How should we then store profiles? Have one profile for battery power and one for corded connection?

[crisidev]

I do already, I have 2 different profiles, with different fans for performance and battery and switch them in active_profile.json. With this PR I would add a backlight configuration per profile.

[AaronErhardt]

and switch them in active_profile.json

Do you do this manually? Anyway, this is another topic and not part of this PR.

I would like the two things I have already mentioned:

1. A backlight profile for not changing backlights when a profile is loaded.
2. Some sort of optional runtime, either through Vec or Option. Tuxedo also sells regular PCs which don't have backlight support at all (and maybe someone has multiple backlights in which case Vec would be really great).

[crisidev]

Do you do this manually? Anyway, this is another topic and not part of this PR?

So far yes, I still have to set the dbus automation to switch the profile through it.

For the rest I agree, I'll work on the implementation using a Vec.

[crisidev]

I'll be off without my laptop for ~3 weeks and will not have time to work on this for a little :(

[AaronErhardt]

Thanks for letting me know. I've really enjoyed working with you, I'm looking forward to hear from you when you have time again :)

[crisidev]

Likewise.. now it's time to decompress without a laptop!