w i p
changes acpilight 1.2: 2019-06-22
* Added a new „-perceived„ flag to control brightness in logarithmic
steps (thanks to Lars-Dominik Braun).
* New action „-get-steps„ to get the brightness resolution.
* Fixed the built-in udev rules for the keyboard backlight.
! 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
ddcci-driver-linux 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: capabilities 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. idProt ACCESS.bus protocol supported by the device. Usually "monitor". idType ACCESS.bus device subtype. Usually "LCD" or "CRT". idModel ACCESS.bus device model identifier. Usually a shortened form of the device model name. idVendor ACCESS.bus device vendor identifier. Empty if the Identification command is not supported. idModule ACCESS.bus device module identifier. Empty if the Identification command is not supported. idSerial 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 = f.read(8) print("Contrast:", response * 256 + response, "/", response * 256 + response) 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/. Limitations 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", "VGN-FZ38","VPCCW1","VPCCW2","VPCS1","VGN-S560","VPCF1" "Dell Inc.", "Inspiron 1370","Vostro 3400","Vostro 3500","Latitude E6530" "SAMSUNG ELECTRONICS CO., LTD.", "N510","SR70S/SR71S","Q430/Q530","R510/P510", "RV409/RV509/RV709","RV420/RV520/RV720/E3530/S3530/E3420/E3520", "TOSHIBA", "SATELLITE PRO U500","SATELLITE L750","SATELLITE L755" "Apple Inc.", "MacBook5,1","MacBook5,2","MacBook6,1","MacBook7,1","MacBookPro3,1", "MacBookPro3,2","MacBookPro4,1","MacBookPro5,2","MacBookPro5,4","MacBookPro5,5", "MacBookPro7,1","MacBookAir2,1","MacBookAir3,1","MacBookAir3,2" "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",
fixes since v4l2loopback-0.12.1:
– * Fixed compat with kernel 5.0
– * Replace v4l2_get_timestamp with ktime_get_ts(64) for linux-5.1 compat
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".