video display

w i p

! Preparation: you as user must be member of group "video" !
"acpilight" is a backward-compatibile replacement for xbacklight that uses the
ACPI interface to set the display brightness. On modern laptops "acpilight" can
control both display and keyboard backlight uniformly on either X11, the
console or Wayland.
On some modern laptops "XRandR" might lack the ability to set the display
brightness. This capability was moved/unified to the kernel's ACPI interface,
via /sys/class/backlight/.
"acpilight" provides a drop-in replacement for the xbacklight command that
uses the ACPI interface instead of "XRandR", allowing old scripts to run. As a
result, xbacklight can subsequently be used also from the console and
Wayland (X11 is not used at all).
When paired with the ddcci-backlight kernel module, the backlight of most
professional external monitors can be controlled as well.

"acpilight" is distributed under GPLv3+ (see COPYING) WITHOUT ANY WARRANTY.
Copyright(c) 2016-2018 by wave++ "Yuri D'Elia" .

For external monitors use dkms-ddcci


A pair of Linux kernel drivers for DDC/CI monitors. DDC/CI is a control protocol
for monitor settings supported by most monitors since about 2005.
It is based on ACCESS.bus (an early USB predecessor).

ddcci (bus driver)
This driver detects DDC/CI devices on DDC I²C busses, identifies them and
creates corresponding devices. As this is a I²C driver it won't be autoloaded
and must be manually loaded, for example by putting a line with ddcci
in /etc/modules.

sysfs interface
Each detected DDC/CI device gets a directory in /sys/bus/ddcci/devices.
The main device on a bus is named ddcci[I²C bus number].
Internal dependent devices are named ddcci[I²C bus number]i[hex address]
External dependent devices are named ddcci[I²C bus number]e[hex address]
There the following files export information about the device:

The full ACCESS.bus capabilities string. It contains the protocol, type and
model of the device, a list of all supported command codes, etc.
See the ACCESS.bus spec for more information.

ACCESS.bus protocol supported by the device. Usually "monitor".

ACCESS.bus device subtype. Usually "LCD" or "CRT".

ACCESS.bus device model identifier.
Usually a shortened form of the device model name.

ACCESS.bus device vendor identifier.
Empty if the Identification command is not supported.

ACCESS.bus device module identifier.
Empty if the Identification command is not supported.

32 bit device number. A fixed serial number if it's positive, a temporary serial
number if negative and zero if the Identification command is not supported.

Character device interface
For each DDC/CI device a character device in /dev/bus/ddcci/[I²C bus number]/
is created. The main device on the bus is named display.
Internal dependent devices are named i[hex address]
External dependent devices are named e[hex address]
These character devices can be used to issue commands to a DDC/CI device more
easily than over i2c-dev devices.
They should be opened unbuffered and may be opened with O_EXCL if you want
exclusive access. To send a command just write the command byte and the
arguments with a single write() operation. The length byte and checksum are
automatically calculated.
To read a response use read() with a buffer big enough for the expected answer.
NOTE: The maximum length of a DDC/CI message is 127 bytes.
An Example (in Python):
with open('/dev/bus/ddcci/3/display', 'r+b', buffering=0) as f:
	# Read contrast
	f.write(bytes([0x01, 0x12]))
	response =
	print("Contrast:", response[6] * 256 + response[7], "/", response[4] * 256 + response[5])
The following error codes are used:

EAGAIN: there was no response yet or (with O_NONBLOCK) the device was in use by another thread
EBADMSG: there was a response but the checksum didn't match
EBUSY: the device is opened exclusively by another thread (on open())
EINVAL: message too big (on write())
EIO: generic I/O failure
EMSGSIZE: the buffer was too small (on read())
ENOMEM: not enough free memory to allocate buffers (on open())

Lower layers may pass error codes not in this list like ENXIO, so be prepared for that.

ddcci-backlight (monitor backlight driver)
For each monitor that supports accessing the Backlight Level White or the Luminance property, a backlight device of type "raw" named like the corresponding ddcci device is created. You can find them
in /sys/class/backlight/.

Dependent device (sub devices using DDC/CI directly wired to the monitor,
like Calibration devices, IR remotes, etc.) aren't automatically detected.
You can force detection of internal dependent devices by setting the
autoprobe_addrs module parameter of ddcci.
You can force detection of external dependent devices by
writing "ddcci-dependent [address]" into /sys/bus/i2c/i2c-?/new_device.
There is no direct synchronization if you manually change the luminance with the
buttons on your monitor, as this can only be realized through polling and some
monitors close their OSD every time a DDC/CI command is received.
Monitor hotplugging is not detected. You need to detach/reattach the I²C driver
or reload the module.

imported from mga-cauldron+aur

This package contains a DKMS-ready driver
for nvidia laptop display back-lights.

This driver drives the smartdimmer register found on modern mobile
Nvidia graphics adapters such as NV40, NV41, NV43, NV44, NV46, NV47,
NV49, NV4B, C51, G84, G86, G92, G94, G96, GT200 architectures to adjust
the display backlight.

On Apple machines this driver allows more fine-grained brightness
adjustment than the mbp-nvidia-bl-dkms (mbp_nvidia_bl) driver and is
generally preferred.

Knowing maybe work's on:
"Sony Corporation", "VGN-AW11","VGN-AW290J","VGN-FZ11","VGN-FZ31",

"Dell Inc.", "Inspiron 1370","Vostro 3400","Vostro 3500","Latitude E6530"

"SAMSUNG ELECTRONICS CO., LTD.", "N510","SR70S/SR71S","Q430/Q530","R510/P510",


"Apple Inc.", "MacBook5,1","MacBook5,2","MacBook6,1","MacBook7,1","MacBookPro3,1",

"LENOVO", "4313CTO","4270CTO","42844MG","9523","20192","QIQY5","20193"

"LG Electronics", "R590-P.BN58P1","R590-K.BE52P1","R580-K.AHC4WA9",

"ASUSTeK COMPUTER INC.", "G75VW","G75VX","G74Sx","G55VW","G55VW",

"Compal", "PBL01","QAL51",

"Quanta", "TW9",

"FUJITSU", "AMILO Pi 3560",

"Acer", "TravelMate 8481TG",

"Hewlett-Packard", "HP Pavilion dv3500 Notebook PC",



This module allows you to create "virtual video devices" normal (v4l2)
applications will read these devices as if they were ordinary video
devices, but the video will not be read from e.g. a capture card but
instead it is generated by another application.


Use v4l2loopback-ctl for controlling FPS, placeholder image and image format.
See "$ man v4l2loopback-ctl.1" or "$ v4l2loopback-ctl --help".