Fixing the MATE backlight applet

SteveM

The Power Manager Brightness Applet in MATE is unable to talk to my laptop's backlight so I've been using /usr/bin/backlight to control it with keyboard shortcuts redirected to use it. I finally got around to looking under the hood and found that /usr/bin/backlight uses ioctl to directly control /dev/backlight/backlight0 whereas the MATE applet is currently using dbus-glib calls. There is also a PR in process to convert the applet to GDBus calls.

Is the best route to fix this to patch the MATE applet to use ioctl calls or is it there going to be something in dbus-glib or GDBus that can be patched instead to enable it to correctly control the backlight?

vimanuelt

In the meantime, you can try this workaround: xcrsz/display-control

SteveM

I'd rather not. I mentioned I am able to control backlight with /usr/bin/backlight and some keybindings so I'm not needing a stop gap. You suggested an 18M monster that is less convenient and uses xrandr to control the software brightness which leaves my backlight alone. This is a laptop, backlight power consumption matters.

I probably should have asked the FreeBSD people anyway.

vimanuelt

SteveM
Yes, they own the delivery of this solution. You can press them to complete it, as their previous work only covered 3 vendors.

SteveM

To start to answer my own question, the issue is not with dbus as mate-power-manager is simply using it for IPC and the underlying problem is that src/gpm-backlight-helper.c is written specifically for Linux. The FreeBSD package maintainer patched the file to simply return an error code that a backlight could not be found. So I believe that the correct fix is to modify src/gpm-backlight-helper.c to use ioctl

vimanuelt

SteveM

No. One ioctl() is not going to fix every machine. Backlight control is not a single thing on FreeBSD: some systems use ACPI, some use DRM, and some need driver-specific handling.

The fix belongs in the FreeBSD backend. It should try the interfaces the machine provides, use the one that works, and only say "no backlight" when there really isn't one.

SteveM

I am curious as to why the /usr/bin/backlight utility uses ioctl to control the backlight if this is not correct?
ghostbsd/ghostbsd-srcblob/stable/15/usr.bin/backlight/backlight.c

Me thinks you have confused user space control of backlight brightness with the backlight device driver.
ghostbsd/ghostbsd-srcblob/stable/15/sys/dev/backlight/backlight.c

vimanuelt

SteveM

You might be assuming that all brightness mechanisms eventually appear through the FreeBSD backlight framework, and that assumption may not hold for all modern hardware.

The reason /usr/bin/backlight uses ioctl() is because it is a client of the FreeBSD backlight device interface. It is not communicating directly with the panel, the GPU, ACPI firmware, or an embedded controller. It opens /dev/backlight/backlight0 and uses the ioctl interface exported by the backlight subsystem.

However, modern laptops have made the situation more complicated. Brightness control may be implemented through several different paths:

ACPI video methods exposed by firmware.
DRM/KMS backlight interfaces implemented by GPU drivers.
Vendor-specific firmware interfaces.
Embedded controller mechanisms.
Other platform-specific methods.

Those mechanisms do not necessarily map one-to-one onto the FreeBSD backlight framework today. A laptop may have a perfectly functional brightness control path that is not represented as a /dev/backlight/* device.

Therefore, there are two separate questions:

What should MATE use on FreeBSD?

It should use the operating system's supported user-space interface rather than attempting to implement hardware detection itself. If FreeBSD exposes the backlight through /dev/backlight/backlight0, then the MATE helper should use the same ioctl interface that backlight(8) uses.
Does the FreeBSD backlight subsystem support every brightness mechanism used by current laptops?

That is a FreeBSD kernel/platform support question. If a vendor uses a mechanism that is not represented by the backlight framework, that support needs to be added at the appropriate layer. Otherwise every desktop environment would need to duplicate knowledge of ACPI quirks, vendor firmware interfaces, and GPU-specific behavior.

So the existence of modern vendor brightness mechanisms does not make the ioctl approach incorrect. It means the ioctl is only the final user-space interface. The important question is whether the kernel side exposes all required mechanisms through that interface.

The current MATE problem is that the FreeBSD backend is missing or incomplete. The broader FreeBSD problem is ensuring that the backlight framework represents the brightness mechanisms found in current hardware. Those are related issues, but they are not the same issue.

SteveM

Please take your unhelpful AI generated content elsewhere. You have rendered this thread useless with your astonishing lack of understanding and I would close it if I could. Since I cannot I am going to stop following it and will make no further replies here.

vimanuelt

SteveM

I think I understand the problem space reasonably well, even if the conclusion is not the one you were hoping for.

One complication today is that laptop vendors are increasingly moving hardware management functionality into firmware. Brightness control is no longer always a simple OS-controlled operation through a documented interface. Some systems rely on ACPI methods, GPU firmware, embedded controllers, vendor-specific firmware interfaces, or other components that may not expose a traditional operating system API.

This makes it even more important that desktop environments do not attempt to implement their own hardware detection logic. A desktop should not need to know about every vendor firmware interface or every laptop-specific workaround.

The proper separation is:

Kernel and platform drivers: handle whatever hardware and firmware interfaces are available and expose them through a common operating system interface.
User space: consumes that interface without needing to understand the underlying implementation.

The challenge for FreeBSD is ensuring that its hardware abstraction layer can represent the variety of mechanisms found in modern systems, including cases where vendors have replaced traditional OS-controlled functionality with firmware-managed behavior.

If a vendor introduces a new firmware mechanism, the solution is not for every desktop environment to add another vendor-specific implementation. The solution is to add support at the appropriate system layer and keep applications using a stable interface.

vimanuelt

If you can tell us the make and model of your computer, we may be able to determine what is needed to make brightness controls work. On some 2025 and newer systems, vendors such as Intel, AMD, and NVIDIA have started relying more heavily on proprietary firmware blobs for parts of the display and power management stack. That can change how brightness controls are exposed to the operating system and may require a different approach depending on the hardware.