Backlight change on idle effectively broken?

[Alanon202]

Context

I’m building out a Wayland system and slowly migrating from Openbox, so Labwc and some LXQt utilities were the natural way to go. LXQt Power Manager seems like the most robust solution currently available on Wayland, so I opted to use it in my laptop setup. I was trying to configure the system to decrease brightness after 3 minutes of inactivity, after which the system would suspend or lock after 15 minutes of inactivity, when I encountered this issue. It may not be a bug per se, but I was unable to find any information about the intended usage so I decided to write it out.

Current Behavior

The option is called "Backlight Change on Idle", but a polkit prompt is always initiated for any brightness change to happen? Presumably, if the computer is idle, it makes no sense that the user would suddenly enter their password to elevate privileges and decrease the screen brightness, because doing so would simultaneously break the idle state?

Alternatively, if the system is indeed idle, and the user is not there to enter the password, we’re left with a system password prompt in the middle of the screen? This then seems to break all subsequent events in the chain until the password prompts are cancelled or satisfied.

Steps to Reproduce

For example, I set the backlight to change to something like 5% after 30 seconds of inactivity, and the system to suspend after 50 seconds in idle state.

The password prompt will appear after 30 seconds and inhibit the suspend timer presumably forever. Only after canceling the password prompt will the system immediately suspend.

Alternatively, when you disable the backlight and leave the suspend after 50 seconds engaged, it will work every time.

This makes the backlight feature as-is practically unusable alongide any other configuration option, and it isn’t particularly useful by itself due to constant password prompting.

(I’ve tried the same thing in both a labwc session and with lxqt-wayland-session set up for use with labwc and the behaviour is the same.)

Expected Behavior

I would expect there to not to be a password prompt, i.e. the program should figure out how to not ask the user for elevated privileges to access brightness settings and simply change them as per the user setting, not breaking any idle states in the process.

If I’m correct, for all intents and purposes this setting makes no sense unless the user is not prompted for their password? However, I could find no way to achieve this?

Possible Solution

I already use udev rules that assign special permissions to the video usergroup and related brightness files. They enable the likes of waybar and some bash scripts to write brightness values with no elevated privileges for any user in the video group. I’m currently using acpilight, which is an xbacklight compatible ACPI-based solution, which works fine on X11 and Wayland alike, but lxqt-powermanagement seems to ignore this no matter what I try.

I’ve tried chgrp video and chmod g+x on all of the lxqt-backlight_backend files hoping that this would eliminate the prompt and also exeprimented with some polkit settings to no avail. No matter what I do, the polkit authentication is triggered.

Is there a different way to achieve this, or is something misconfigured on my end?

System Information

I’m using a fully up-to-date Arch Linux with the latest kernel, all the latest updates in a Wayland session with labwc as my compositor. As far as LXQt components are concerned, I use only lxqt-powermanagement and its dependencies from the extra repository and log into labwc using ly.

• Distribution & Version: ArcoLinux
• Kernel: 6.12.1-arch1-1
• Qt Version: qt6-base 6.8.0-1
• liblxqt Version: 2.1.0-1
• lxqt-build-tools Version: 2.1.0-1
• Package version: 2.1.0-1

[tsujan]

No password should be needed.

I vaguely remember a similar report on X11, but I don't remember how it was resolved by the user.

[stefonarch]

Maybe it needs lxqt-config-brightness installed, provided by lxqt-config?

[tsujan]

No, it doesn't need lxqt-config.

[tsujan]

We have <allow_active>yes</allow_active> in /usr/share/polkit-1/actions/org.lxqt.backlight.pkexec.policy; so, the user is authorized. Something contradicts that in the system of this user.

[Alanon202]

I tried an X11 (Openbox) session and the behaviour is the same, which would suggest that @tsujan is correct. I never messed with polkit policies so I’m not sure what could have gone wrong there.

I poked around some more and can confirm that running pkexec /usr/bin/lxqt-backlight_backend --inc for example requires no authorisation and works right away.

As best I can tell, the issue seems to be that when the backlight backend is started from lxqt-powermanagement, whether by pressing the check backlight button or when the setting is triggered by a timer, the pkexec policy is not invoked.

Indeed, the authorisation widow information shows org.freedesktop.policykit.exec as the one in charge, and not org.lxqt.backlight.pkexec. Now what exactly causes this behaviour, I have no idea.

[tsujan]

@Alanon202
To which package does org.freedesktop.policykit.exec belong? I don't have it here.

[Alanon202]

@tsujan Pacman says /usr/share/polkit-1/actions/org.freedesktop.policykit.policy is owned by polkit 125-1

Looking inside, it looks like a default policy file with a bunch of descriptions in different languages, <allow_any>auth_admin</allow_any>, <allow_inactive>auth_admin</allow_inactive>, <allow_active>auth_admin</allow_active> and nothing else.

[tsujan]

Yes, sorry, I searched the wrong string. Never mind.

Do you have /usr/share/polkit-1/actions/org.lxqt.backlight.pkexec.policy?

[tsujan]

To be certain, I enabled backlight changing with idleness under LXQt+kwin_wayland, and it worked flawlessly. Since it doesn't depend on X11 or Wayland, it should work everywhere.

My guesses about the cause of your problem are

• A distro issue (in packaging, for example);
• An installation issue; or
• A problem in EVs.

That being said, like it's usually the case with such problems, there may be a missing info somewhere.

[Alanon202]

Yes, sorry, I searched the wrong string. Never mind.

Do you have /usr/share/polkit-1/actions/org.lxqt.backlight.pkexec.policy?

Yes, the file is there:

<?xml version="1.0" encoding="UTF-8"?> <!DOCTYPE policyconfig PUBLIC
 "-//freedesktop//DTD PolicyKit Policy Configuration 1.0//EN"
 "http://www.freedesktop.org/standards/PolicyKit/1/policyconfig.dtd"> 
<policyconfig>
  <action id="org.lxqt.backlight.pkexec">
    <message>Authentication is required to Change Brightness</message>
    <icon_name>battery</icon_name>
    <defaults>
      <allow_any>no</allow_any>
      <allow_inactive>no</allow_inactive>
      <allow_active>yes</allow_active>
    </defaults>
    <annotate key="org.freedesktop.policykit.exec.path">/usr/bin/lxqt-backlight_backend</annotate>
  </action>
</policyconfig>

[tsujan]

I can also add this to the above list:

• A permission issue.

These 4 cases were all that I could guess. I really think that the problem cannot be in LXQt — especially because it isn't reproducible, but I also checked the code and found nothing suspicious in it.

[Alanon202]

After all the digging around I was able to do, I agree that the issue is not likely to be with LXQt. What I’m most confused about is how I hadn’t encountered this issue before if it’s such a big misconfiguration issue?

I also tried building the git version of lxqt-powermanagement to see if maybe something would be different, no dice. The same for adding some custom rules in etc/polkit-1/rules.d.

I guess I could try to reinstall polkit, or even switch polkit agents, and see if that might change things around?

@tsujan Do you perhaps have any advice how to begin testing some of these things?

[tsujan]

I have no advice. But strange problems that I've encountered were mostly caused by my changing something and then forgetting about it. I don't think re-installation or radical changes can really solve any problem.