Skip to content

[ryoku] shell: keep the backlight fader off non-backlight devices - #761

Open
techapostle wants to merge 1 commit into
Ryoku-dev:unstable-devfrom
techapostle:fix/backlight-class-only
Open

techapostle wants to merge 1 commit into
Ryoku-dev:unstable-devfrom
techapostle:fix/backlight-class-only

Conversation

@techapostle

Copy link
Copy Markdown

What changed

On a desktop with no built-in screen, Controls shows a "Built-in display" brightness fader in the Brightness drawer, and the bar brightness widget and the Kairos and Orpheus display pages count it as a display. Dragging it writes to a keyboard LED.

Cause. services/Devices.qml resolves the panel with ryoku-hw-backlight, which exits 1 and prints nothing when /sys/class/backlight is empty. ${BL:+-d "$BL"} then drops -d, and brightnessctl falls back to its first device of any class:

$ ryoku-hw-backlight
ryoku-hw-backlight: no backlight device under /sys/class/backlight
$ brightnessctl -m
input16::compose,leds,0,0%,1

The read parses 0, so backlightPct becomes 0 and backlightAvailable turns true. The comment on backlightPct says the reader should never set it on such a machine.

Fix. The read and the write in Devices.qml both pass -c backlight. With no backlight, brightnessctl exits 1 with no output (Failed to read any devices of class 'backlight'.), so backlightPct stays -1 and every consumer of backlightAvailable hides the fader. On a laptop the selector's device is already a backlight-class device, so -c backlight -d <it> resolves the same device as before. If the selector is missing, the class still keeps brightnessctl on a backlight.

Area

ryoku

How it was tested

Arch, Hyprland 0.57.0, desktop with no /sys/class/backlight device and two DDC monitors.

  • The blRead command before the change prints 0; after it prints nothing.
  • brightnessctl -c backlight -p set 50% exits 1 and leaves the LED untouched.
  • -c and -d combine as expected: brightnessctl -c leds -d input16::compose -m finds the device.
  • Live shell with the changed Devices.qml: before the change, Controls > Brightness drawer listed Built-in display, DP-1 and HDMI-A-1. After it, the drawer lists only DP-1 and HDMI-A-1, and the main Brightness slider still follows DP-1.
  • The pre-commit QML binding check passes.

Not tested: a laptop with a real backlight. The argument rests on brightnessctl's class filter: -c backlight -d <name> resolves a device whose class is backlight, and ryoku-hw-backlight only ever prints entries from /sys/class/backlight.

Checklist

  • One logical change, with a clear [area] scope: summary commit subject.
  • Matching CHANGELOG.md updated in the area I touched.
  • The git hooks pass locally; I did not use --no-verify.
  • Lua parses (luac -p), shell scripts pass bash -n, and QML passes
    qmllint where applicable.
  • No duplicated config, no dead code, no commented-out code, no em-dash.
  • Docs updated if behavior or layout changed.

On a desktop with no /sys/class/backlight device, ryoku-hw-backlight
prints nothing, so `${BL:+-d "$BL"}` drops -d and brightnessctl falls
back to its first device of any class. Here that was a keyboard LED
(input16::compose,leds,0,0%,1): the read parsed 0, backlightAvailable
went true, and Controls, the bar brightness widget and the Kairos and
Orpheus display pages offered a "Built-in display" fader that wrote to
the LED.

Both the read and the write now pass `-c backlight`. With no backlight
brightnessctl exits 1 with no output, backlightPct stays -1 and the
fader hides, as the comment on backlightPct already says it should. On
a laptop the selector's device is in the backlight class, so the call is
unchanged.

Note: Fixed: desktops without a built-in screen no longer show a fake Built-in display brightness slider

This branch has not been deployed

No deployments
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.

1 participant