Display control

Display control protocols allow for controlling displays with auxiliary signalling through the video link or an additional bus. The most basic functionality is power and backlight management, the latter of which is mostly supported in laptops and some television screens, but still less prevalent in standalone computer monitors.

Controllable features are very implementation-dependent in general. Also, there are numerous display control protocols and their implementations in use with overlapping capabilities.

For most tools mentioned below and in linked articles user access can be granted by adding the user to the video user group.

Hardware-only

These limited implementations can mostly be found in older laptops. Hardware-only meaning there is no software interface for backlight control so the user can only use preset keyboard keys/combinations or a dedicated rotating-type/sliding-type switch or a knob. Old CRT computer monitors also had hardware brightness control.

Vendor-specific

Vendor-specific implementations and also some related tools are well presented in Backlight. Vendor-specific ACPI implementations and GPU hacks without a standard kernel interface also fall in this limited category, as do external displays with a custom protocol over UART/USB and similar. These are typically not supported in desktop environments.

ACPI

ACPI-module implementations are only found in laptops and PCs with integrated displays (such as AIOs), but partially standardized and accessible from software. ACPI implementations with /sys/class/backlight interface are usually well-supported in desktop environments, but no other display control features are available.

DPMS

While omnipresent in computer hardware and well-supported in software for a long time, the Display Power Management Signaling only allows for display power management into 2-4 states, but no finer backlight or other control. In TV setups it can switch the panel state at best, but it cannot wake or suspend a TV.

(E-)DDC/CI

The (Enhanced) Display Data Channel / Command Interface interface carries Monitor Control Command Set (MCCS) over I2C and can complement or even replace DPMS in computer hardware. Even though DDC 1.0 was published in 1994 and E-DDC 1.0 in 1999, the feature has only started to appear in standalone computer monitors in 2010s. Besides power and backlight management it has an extensive command set for controlling all display settings supported in its controller. ddcutil (GUI: ddcui^AUR) and ddccontrol^AUR (GUI: gddccontrol^AUR) are the tools to look at. For backlight control it is possible to create /sys/class/backlight interface with ddcci-driver-linux-dkms^AUR, which enables desktop integration, but still needs mainlining.

eDP v1.2

Embedded Display Port (eDP) introduced a display control protocol in version 1.2 working through the auxiliary DisplayPort channel, superseding DDC/CI in embedded/laptop displays.[1]

HDMI-CEC

HDMI - Consumer Electronics Control is an additional I2C-like, but very slow bus for waking and controlling standalone enduser devices such as TVs. Available from HDMI 1.0, it uses pin 13 in a HDMI connector and it needs a tiny bit of additional hardware to drive the bus. Somehow it is typically not supported in PC GPUs so additional hardware is needed. Specialised USB-CEC adapters are not cheap and abundant, a better alternative is to use kernel driver which uses auxiliary channel of DisplayPort for HDMI-CEC signalling, but it works only with a select few DP-to-HDMI adapters. On the other hand native HDMI-CEC support is normal in ARM single-board computers and certain Android devices. Desktop HDMI-CEC integration in Arch Linux is currently manual, but manageable for simple setups such as waking TV from standby. Supported in userspace primarily through cec-ctl from v4l-utils or alternatively with cec-client from libcec.