Fix backlight control for XFCE with non-Intel xorg video driver

[Douglas R. Reno]

On some laptops with Intel GPUs, moving to the modesetting driver broke the ability for the xbacklight utility to work. This is because the modesetting driver does not provide the XRANDR Backlight Output property, which the old xf86-video-intel driver did.

GNOME and Plasma both carry their own backlight handlers that take care of this for the user, but most other DEs do not. On affected systems, you'll have no control over the screen backlight, power settings for dimming the screen will not function, and using the keys on your keyboard to adjust the backlight will not work.

I have an affected Dell Latitude E6540 (which I use as my primary laptop) which I can use for testing.

acpilight has no dependencies other than Python3, and we'll need to remove xbacklight from Xorg Apps. I propose putting acpilight after Xorg Apps though.

[Xi Ruoyao]

It should be a better solution than adding xf86-intel back because the latter won't solve the issue with latest Intel GPUs (those come with 12 or 13-th gen Core processors) or NVIDIA/AMD GPUs.

Setting severity to blocker because we'd definitely want to solve it out before 12.0. If not we need to add xf86-intel back for now as an imperfect solution.

[Douglas R. Reno]

Replying to Xi Ruoyao:

It should be a better solution than adding xf86-intel back because the latter won't solve the issue with latest Intel GPUs (those come with 12 or 13-th gen Core processors) or NVIDIA/AMD GPUs.

Setting severity to blocker because we'd definitely want to solve it out before 12.0. If not we need to add xf86-intel back for now as an imperfect solution.

I definitely agree with putting it as a blocker. I'll try to have this done and tested over the weekend. Just adding back xf86-video-intel is definitely not an ideal solution

[Xi Ruoyao]

One challenge here is we need to figure out which packages use xbacklight.

[Bruce Dubbs]

I have commented out xbacklight from the xorg applications page.

[Xi Ruoyao]

I'm wondering if we are misdiagnosing the issue. It looks like xfce-power-manager directly writes into /sys/class/backlight, instead of calling the xbacklight executable:

​https://gitlab.xfce.org/xfce/xfce4-power-manager/-/blob/master/src/xfpm-backlight-helper.c

So why wouldn't it work w/o xf86-video-intel? Maybe a permission issue (and we just need a udev rule to set the permission properly)?

[Xi Ruoyao]

Replying to Xi Ruoyao:

I'm wondering if we are misdiagnosing the issue. It looks like xfce-power-manager directly writes into /sys/class/backlight, instead of calling the xbacklight executable:

​https://gitlab.xfce.org/xfce/xfce4-power-manager/-/blob/master/src/xfpm-backlight-helper.c

So why wouldn't it work w/o xf86-video-intel? Maybe a permission issue (and we just need a udev rule to set the permission properly)?

Hmm, it looks like xfce-power-manager invokes xfpm-backlight-helper if XrandR does not work, and xfpm-backlight-helper is ran with pkexec so polkit is needed. There is a build time check so it's not a simple runtime dependency.

And I'm not sure if using polkit will cause a password prompt to show up for each time pressing the brightness up/down hotkey (it will be very stupid).

[Xi Ruoyao]

There's a shipped polkit rule so the password prompt should not pump up for each brightness adjust:

​https://gitlab.xfce.org/xfce/xfce4-power-manager/-/blob/master/src/org.xfce.power.policy.in.in

So perhaps we just need to prompt polkit from optional to recommended for xfce-power-manager.

[Douglas R. Reno]

Polkit is recommended for elogind on SysV and systemd. It should already be present.

[Xi Ruoyao]

Do we need to --enable-polkit or --with-polkit manually? I'm not sure.

[Xi Ruoyao]

Replying to Douglas R. Reno:

Polkit is recommended for elogind on SysV and systemd. It should already be present.

For logind polkit is a runtime dependency, but xfce-power-manager checks it at build time. If polkit does not exist the routine controlling /sys/class/backlight will not be built.

[Rahul Chandra]

Can confirm, building xfce4-power-manager without polkit kills the backlight keys in xfce4 (Testing with UHD 620 under modesetting). Curiously it also starts tearing under the normal compositor, which didn't happen with the intel driver, but that can be solved using the patch we have for Xorg and adding 20-intel.conf with the

Section "Device"
   Identifier "Graphics Adapter" 
   Driver "modesetting"
   Option "TearFree" "true"
EndSection

[Douglas R. Reno]

UPower requires polkit, and UPower is a required dependency for xfce4-power-manager

[Xi Ruoyao]

Replying to Douglas R. Reno:

UPower requires polkit, and UPower is a required dependency for xfce4-power-manager

But the fact seems not. In upower NEWS:

Version 0.99.1 (Released: 2014-08-18)

New Features:

• Remove unused polkit dependency (Eric Koegel, Martin Pitt)

[Xi Ruoyao]

I've made the following change:

• r11.3-1403-ga8163a4fc9 Drop polkit dependency for power
• r11.3-1404-geeb0e37817 Promote polkit dependency to recommended for xfce4-power-manager
• ​SA 11.0-059 No longer suggest unsetting suid bit of pkexec as a workaround

Leaving this open until a confirmation from Tim.

[Xi Ruoyao]

Replying to Xi Ruoyao:

Replying to Douglas R. Reno:

Polkit is recommended for elogind on SysV and systemd. It should already be present.

For logind polkit is a runtime dependency, but xfce-power-manager checks it at build time. If polkit does not exist the routine controlling /sys/class/backlight will not be built.

Nope. It is a runtime dependency. Even if polkit does not exist at build time, polkit-based backlight control is still built (unless explicitly --disable-polkit). See d5a105a. But in current BLFS polkit is no longer a runtime dependency of logind, and I'm inclined to demote it to optional for systemd too (it's only used when you run "systemctl" or "shutdown" etc. as a non-root user).

In XFCE polkit should be pick up by xfce4-session (it lists polkit-gnome as a recommended dependency) but my XFCE build works perfectly fine (including the backlight control) even though I deviated from the book (with polkit built after XFCE, and polkit-gnome not built at all). So maybe Tim has deviated from the book like I do, and the other people just FBBG so they cannot reproduce the issue at all.

[Xi Ruoyao]

To me it seems like xfce4-session only need polkit at build time for system shutdown without elogind. But I really don't want to test a "no-logind" system.

[Xi Ruoyao]

I'm inclined to close this as fixed if no objection?

[Douglas R. Reno]

As part of this ticket, I decided to test backlight control in all of the desktop environments that we carry.

These were the results...

• LXQt: Needs to be done via panel applet, but works perfectly
• XFCE4: Needs to have handling of the brightness key turned on, but works great
• LXDE: No backlight control whatsoever. Note about that added at eecfba74b64b811b51830b05362f0411c6df9684
• GNOME: Works great
• Plasma: Works great

Last night I built all of GNOME, and today I built all of the other DEs with the exception of LXDE.

This ticket can now be safely closed.

For context, the reason why I originally objected is that the brightness keys are handled differently on Dell Latitude laptops in comparison to most other brands, and the original report from Tim did involve a similar Dell Latitude to the one that I have.

[Xi Ruoyao]

Replying to Douglas R. Reno:

As part of this ticket, I decided to test backlight control in all of the desktop environments that we carry.

These were the results...

• LXQt: Needs to be done via panel applet, but works perfectly
• XFCE4: Needs to have handling of the brightness key turned on, but works great

For the record:

1. If we don't turn on it we can still adjust brightness by using the mouse to drag the setting slide bar.
2. If D-Bus is not (re)built with Xorg libraries support, XFCE4 will hang if handling of the brightness key turned on and we press a brightness key.