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

Keyboard backlight handling improvements #404

Open
wants to merge 6 commits into
base: master
Choose a base branch
from
Open

Conversation

cwendling
Copy link
Member

See commit log, but most important bits:

  • Fix toggling backlight back on. When triggering the toggle action, without this it turns off just fine, but never comes back: one has to use the up action enough times to get back the previous brightness. This was a simple one.
  • Persistently save user-set brightness. Currently the brightness was never saved, so one would have had to manually change the "brightness on AC" value to restore a desired value. This seems overly annoying when having up/down/toggle keyboard buttons that the values they set is not remembered. So, I changed this so that user actions (e.g. button triggers) modify the saved value, and is used to restore next time the daemon starts.

The rest is cleanups, and a small change to the handling of some settings combinations because they were just odd in some corner cases, and mostly irrelevant now the user changes are preserved.


I guess that not many people use keyboard backlight under MATE, because it seems really under-loved and especially the toggle bug seems both annoying and simple enough that it would have been spotted and fixed before. I myself just got my hands on a laptop with keyboard backlight with a proper Linux driver for controlling it requiring no hacks, and I couldn't help myself but to fix this 🙂
Hopefully I can still get some review on this, or just rely on street cred ✌️

@lukefromdc
Copy link
Member

You will want to rebase this against master to reflect that the last commit in this PR has been effectivelhy merged separately to fix the Travis problems

Copy link
Member

@lukefromdc lukefromdc left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

On my desktop with no backlit keyboard I've never seen any reference to a keyboard backlight control. Same on my laptops, none of which have ever had a backlit keyboard. Assuming this is shown in the power manager preferences only when the relevent hardware is detected.

That said, the build finished fine and nothing changed in a quick test running both mate-power-manager and mate-control-center with GDK_BACKEND=x11. This generates a ton of warnings in the terminal the power manager is running from but is enough to show the normal GUI in the preferences dialog.

The static value was reset on every call rather than only initially,
resulting in failure to restore the initial value when toggling it
back on.
Try and save the user-set brightness to be able to restore it on next
restart.

This is not perfect because we have complex interaction between
settings which makes it not trivial, if at all possible, to save the
value yet respect the dim settings.

Here we try to save the value in a way that counteract battery dimming
so that restoring the value yields expected results (e.g. a value saved
on battery restores identical on battery again), but it cannot work
when the value to save is larger than the dimmed maximum as at the
moment the maximum value is 100%.

It is however the best I could come up with working with the settings
we currently have, and it's probably good enough at least as a starting
point.

It also switches from `master_percentage` to `brightness_percent` in
the toggle code because the former is only initialized to the actual
current brightness value once brightness changed at least once, while
the former is properly initialized.  It is otherwise quivalent for this
feature, and less confusing as to when the value gets updated.
Now the on-AC value changes following user input, the internal
`master_percentage` was just plain confusing and actually make things a
bit weird at times because it doesn't follow dynamic user choices.

So just get rid of it, replacing it with the on-AC value.
Handling of a disabled battery-reduce setting was too aggressive, which
could reduce in not setting backlight value in unrelated cases,
including initial startup and resume, as well as some cases of IDLE
handling.

Now the user choices are better followed, the whole special-casing
could probably be removed as the internal state should always reflect
the reality, but keep the specific check not to do anything on AC
plug/unplug when this is disabled just in case, although the historical
reasons why it was actually problematic should be gone now.
@cwendling
Copy link
Member Author

I just rebased on top of fixed master.

@lukefromdc thanks for the quick test. However, note that nothing I changed here is related to GUI preferences themselves, but solely to how hardware buttons react and how some settings combination interact.

I'd be best to have others test this with the relevant hardware, but I also believe that it was broken badly enough (IMO) that even if there's some more fine-tuning to do to please everyone it's still way better than the state before.

@lukefromdc
Copy link
Member

lukefromdc commented Dec 11, 2024 via email

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

Successfully merging this pull request may close these issues.

2 participants