hansdegoede | Entries tagged with backlight

As mentioned in my previous blog post, I have written a new patch series for 6.2 to try to avoid having multiple entries in /sys/class/backlight for a single panel again.

This new series might cause regressions on a different set of even older laptop models then the one affected by the 6.1 backlight work. So I'm again looking for people willing to run a few quick tests.

To see if your laptop is possibly affected by the 6.2 change please run:

ls /sys/class/backlight

if the output of this command contains both:

A GPU native backlight device, with intel/nv/nvidia/amd/radeon/psb/oaktrail in the name; and
A vendor backlight device, with either a model-series: eeepc, ideapad, thinkpad, etc; or a vendor-name: acer, asus, dell, toshiba, sony, etc. in the name

then 6.2 will cause a behavior change on your device, it will hide the vendor backlight device in preference of the native backlight device.

If your laptop shows only a native or only a vendor backlight device (possibly in combination with another type of backlight device such as acpi_video#), then your laptop will not be affected by the planned changes for 6.2.

Note that I expect only very old models to be affected, e.g. the Sony Vaio PCG-FRV3
from 2003 is known to be affected.

If your laptop has both native + vendor backlight devices, then please do 2 things:

Please run the following commands:
1. ls /sys/class/backlight > ls-backlight.txt
2. sudo dmesg > dmesg.txt
3. sudo dmidecode > dmidecode.txt
4. sudo acpidump -o acpidump.txt
Please test if the native backlight interface works, the example below assumes the native backlight is called "intel_backlight":
1. cd /sys/class/backlight/intel_backlight
2. cat max_brightness
3. <the "cat max_brightness" will show the maximum brightness value supported>
4. echo $max_brightness_value > brightness
5. echo $half-of-max_brightness_value > brightness

Where if for example cat max_brightness returns 255 then $max_brightness_value
is 255 and $half-of-max_brightness_value is 127. And then check if the brightness of the backlight actually changes when you do this ?

After generating the 4 .txt files and running the native backlight tests, please send me an email about this at hdegoede@redhat.com with the results of the native backlight tests (panel brightness changes when echo-ing values to brightness or not?) and with the 4 generated .txt files attached.

If the native backlight interface works then things should keep working fine with 6.2 and typically you will get more fine-grained brightness control as an added bonus. Please send me an email with the test results even if the native backlight interface works.

I have received quite a few test reports in response to my previous blog post. Many thanks to everyone who has run the tests and send me their results!

These tests show that as a result of the current 6.1 changes quite a few laptop models will end up with an empty "/sys/class/backlight", breaking users ability to control their laptop panel's brightness.

I have submitted a patch-set for 6.1 upstream to fix this.

More detailed summary/analysis of the received test reports:

Known Windows laptop models affected by this:
- Acer Aspire 1640
- HP Compaq nc6120
- IBM ThinkPad X40
- System76 Starling Star1
Known MacBook models affected by this:
- Apple MacBook 2.1
- Apple MacBook 4.1
- Apple MacBook Pro 7.1
30 unaffected models
The Dell Inspiron N4010 has acpi_video support and acpi_osi_is_win8() returns false, so acpi_video_get_backlight_type() returns acpi_video, but acpi_video fails to register a backlight device due to a _BCM eval error. This model already has a DMI quirk for this, so it is unaffected.
The following laptop models use vendor backlight control method, while also having a native backlight entry under /sys/class/backlight:
- Asus EeePC 901 (native backlight confirmed to work better then vendor)
- Dell Latitude D610 (native backlight confirmed to also work)
- Sony Vaio PCG-FRV3 (native backlight control does not work, BIOS from 2003!)

The fixes for 6.1 restore the behavior where userspace can see multiple entries under "/sys/class/backlight" for a single panel and the kernel leaves figuring out which one actually works up to userspace. This is undesirable and having more then 1 backlight device for a single panel also blocks the new backlight userspace API work which I have planned.

This first round of testing has shown that native works well even on systems so old that they don't have acpi_video backlight control support.

So I have prepared a patch series to try again with 6.2 by making native be preferred over vendor, which should avoid the problems seen with the 6.1 changes before the fixes.

I have landed a large(ish) refactor of the ACPI/x86 backlight detection code in the kernel for 6.1. I have been very careful to try and not break things but there is a special group of laptops where the ability to control the backlight brightness may disappear because of this.

The most likely laptops to be hit by this are laptops which are either pretty old and or which are weird in some other way (e.g. flashed with coreboot, did not ship with Windows as factory os, ...). Note Chromebooks are affected by this too, but that special category has already been fixed.

You can check if your laptop is affected by this by running "ls /sys/class/backlight" if this shows only 1 entry and that entry is named "intel_backlight", "nouveau_bl", "amdgpu_bl0" or "radeon_bl0" then your laptop might be affected.

Note this is quite normal on modern(ish) laptops, a second check is to boot with "acpi_backlight=video" added to the kernel commandline and then run "ls /sys/class/backlight" again, if you now additionally also have an "acpi_video0" entry then your laptop should work fine with 6.1, if you don't have an "acpi_video0" entry please first do "cat /proc/cmdline" and check that "acpi_backlight=video" is present there.

If you have e.g. only the "intel_backlight" entry and adding "acpi_backlight=video" does not cause an "acpi_video0" entry to appear then 6.1 will likely break backlight control!

If you have a laptop which is likely affected by this then please run the following commands:

ls /sys/class/backlight > ls-backlight.txt
sudo dmesg > dmesg.txt
sudo dmidecode > dmidecode.txt
sudo acpidump -o acpidump.txt

And send me an email about this at hdegoede@redhat.com with the 4 generated .txt files attached. If possible please also give an actual 6.1 kernel a try and see if that indeed breaks things. E.g. for Fedora you can find 6.1 kernel builds here and see here for some install instructions for these Fedora kernel builds.

A while ago as a spin-off of my project to improve support for Logitech wireless keyboards and mice I have also done some work on improving support for (Gaming) keyboards with a builtin LCD panel.

Specifically if you have a Logitech MX5000, G15, G15 v2 or G510 and you want the LCD panel to show something somewhat useful then on Fedora 31 you can now install the lcdproc package and it will automatically recognize the keyboard and show "top" like information on it. No need to manually write an LCDd.conf or anything, this works fully plug and play:

sudo dnf install lcdproc
sudo udevadm trigger

If you have a MX5000 and you do not want the LCD panel to show "top" like info, you may still want to install the mx5000tools package, this will automatically send the system time to the keyboard, after which it will display the time.

Once the 5.5 kernel becomes available as an update for Fedora you will also be able to use the keys surrounding the LCD panel to control the lcdproc menu-s on the LCD panel. The 5.5 kernel will also export key backlight brightness control through the standardized /sys/class/leds API, so that you can control it from e.g. the GNOME control-center's power-settings and you get a nice OSD when toggling the brightnesslevel using the key on the keyboard.

The 5.5 kernel will also make the "G" keys send standard input-events (evdev events), once userspace support for the new key-codes these send has landed, this will allow e.g. binding them to actions in GNOME control-center's keyboard-settings. But only under Wayland as the new keycodes are > 255 and X11 does not support this.

About 10 weeks ago I bought a GPDwin. I was working on improving Fedora on Cherry Trail based as a side project and I found out about this cute little machine via a blogpost from Adrien Plazas.

So now 10 weeks later I'm happy to report that after spending a lot of my spare time on kernel fixes I've it mostly working, specifically I've fixed the following things:

1) Brightness control
2) Wifi no longer working with recent kernels
3) Suspend/resume not working
4) Power and volume up/down buttons not working
5) System not waking up when opening the lid
6) Not charging when the power cable gets plugged in after boot
7) Only drawing max 0.5A from the charger, charging slowly if at all
8) Battery monitoring

And Takashi Iwai and Adrian Plazas have fixed:

9) Headphone jack detection

I've done my best to fix all of these properly and I've been submitting patches for all of this upstream. About half of the patches have already been accepted and will be merged into the kernel for the 4.12 release.

If you want to give it a try here are some step-by-step instructions:

1) First of all if you still have Windows on there and you've the 20161118 BIOS you may want to consider downgrading the BIOS to the 20161025 version before wiping Windows. The 20161118 BIOS is locked in a sort of novice mode and removes all options from the BIOS. Since Windows does not support USB gadget mode the dwc3 gadget controller is disabled and cannot be re-enabled in the 20161118 BIOS. So if you want to be able to use the USB-C connector in gadget/device mode and not just as a charging or host port in the future you are going to need the 20161025 BIOS and BIOS-flashing is only supported under Windows (flashrom may work but I was not brave enough to try it).

2) Install your favorite distro, either use an external hdmi monitor or add "i915.modeset=0 fbcon=rotate:1" to the kernel cmdline

3) To get wifi to work copy this file to /lib/firmware/brcm and then reboot.

If you kernel is new enough it will trip over a BIOS bug which causes the wifi chip to get disabled, you can "fix" the BIOS bug (if you do not have
the 20161118 BIOS) by changing the following BIOS setting: "Chipset" -> "South Bridge" -> "LPSS & SCC Configuration" -> "SCC SDIO Support"
to "Disabled". My patches include a workaround for the BIOS bug which works with the 20161118 BIOS, so if you've that you will need to install my kernel through other means (e.g. an USB network adapter).

4) clone my personal linux kernel repo:

git clone https://github.com/jwrdegoede/linux-sunxi.git

This comes with a kernel .config file based on the standard Fedora kernel config (so highly modular). Follow the usual instructions for your distro to build a kernel from source (minus getting the .config). Make sure an initrd gets generated, this kernel-config will not work without an initrd.

Before rebooting into the new kernel add the following to the kernel cmdline in your grub configuration: "fbcon=rotate:1 dmi_product_name=GPD-WINI55".

For brightness control to work your initrd must include the pwm-lpss and pwm-lpss-platform modules. Under Fedora you can do this by booting into the new kernel and then running:

dracut -f --add-drivers "pwm-lpss pwm-lpss-platform" /boot/initramfs-$(uname -r).img $(uname -r)

5) To get sound to work you need to do some userspace config tweaks:

Edit /etc/pulse/daemon.conf and set: "realtime-scheduling = no" to work around a pulse issue with the hdmi-audio support for Cherry Trail.

Create an /usr/share/alsa/ucm/chtrt5645 directory and copy the 2 .conf files from here into that dir.

6) Edit /lib/udev/hwdb.d/99-local.hwdb, add:

sensor:modalias:acpi:KIOX000A*:dmi*:
ACCEL_MOUNT_MATRIX=-1, 0, 0; 0, -1, 0; 0, 0, 1

Copy this file to /lib/udev/rules.d/

Then run "sudo udevadm hwdb --update" and reboot, together with a new enough iio-sensor-proxy, this will fix the screen orientation under gdm / gnome (note you need to tilt the device a bit toward you after booting to get it to recognize the screen orientation for now).

7) All done enjoy your (almost) fully functional GPDwin under Linux

Note these instructions are for somewhat advanced Linux users, if you hit problems please take a look at your distro's documentation or ask for help on your distro's forums.

Linux BIOS tweaks, if you have the 20161025 BIOS, there are 2 BIOS tweaks you can do:

1) Enable USB gadget support, goto: "Chipset" -> "South Bridge" -> "USB Configuration" And change the following 2 options:
"USB OTG Support" : "PCI"
"DRD Access Method" : "Mmio"
This will allow you to load gadget drivers (e.g. "modprobe g_serial") and then connect the GPD-win to a PC and have it show up as an usb device

2) Enable the "S5-Charging Driver" some howtos actually advice disabling this, but it is useful to make sure the GPDwin fast charges when plugged into a charger without being turned on (and even allows for faster charging once the OS is booted). The reason some people advice to turn it off is because it causes problems turning the device on when plugged in and fully charged, when plugged in and fully charged it will simply show a "Battery 100%" screen when you turn it on and then turn off again. You can workaround this by pressing ctrl-alt-del while at the "Battery 100%" screen, or not enable the "S5-Charging Driver" and live with the slower charging.

To enable this goto: "Advanced" -> "System Component" and set "S5-Charging Driver" to "Enabled"

TODO:

1) Recently I found out that the GPDwin has a FUSB300C USB Type-C controller and a PI3USB30532 USB switch which together should allow full USB-C functionality at USB 3.0 speeds (currently the gadget mode runs at 2.0 speed and host mode does not work at all). I plan to write and upstream drivers for this to make this all work.

2) Get all of the required kernel changes upstream.

3) Make things more simple overall ideally new distros released in 2018 will just work without requiring any changes at all.

I've been debugging various backlight brightness problems lately, and I've learned a lot in the process. First lets take a look at how all the bits fit together. There are 3 parts involved in changing the brightness:

Detecting brightness up / down keypresses

Processing the keypresses

Controlling the actual backlight

Detecting brightness up / down keypresses

The brightness keys can be hooked up in a number of ways. Sometimes they function as normal keyboard keys generating extended keycodes. On other cases they are reporting events through some firmware interface (ie ACPI) and they require a driver to be loaded listening for these firmware events.

Processing the keypresses

This is normally done by your desktop environment (Gnome, KDE, etc.) some part of your DE will listen to the events and react to them.

If the acpi video driver is active it may be processing its own events and changing the brightness itself, this usually is underiable as now the
brightness gets changed twice for each keypress. Fedora has this disabled by default. For other distros it is advisable to disable this by adding
video.brightness_switch_enabled=0 to your kernel commandline.

Controlling the actual backlight

This unfortunately is quite complicated. Most laptops have multiple ways to control the backlight, some of which sometimes do not work. You can see
which interfaces are currently available on your laptop by doing:

ls /sys/class/backlight

There are usually 1 or more firmware interfaces, usually the standard ACPI video interface, as well as a vendor specific interface. On a Lenovo Yoga 2 11, I counted 3 firmware interfaces known to Linux, acpi-video, ideapad-laptop and thinkpad_acpi all could create a backlight interface (and none of them
worked). Besides the firmware interface there will often also be a direct hardware (raw) interface, ie /sys/class/backlight/intel_backlight.

Detecting where the problem is

The first step is to figure out in which of the 3 parts listed above the problem is. If you get an on screen display (osd) showing the brightness
setting when you press your brigthness up / down setting, but the brightness does not change, then detecting and processing the keypresses works fine, and there is a problem with controlling the actual backlight.

If the osd does not show then install evemu, and as root run evemu-record, this will show you a list of input devices. You can select capturing raw events from one of them by entering the number for the device. Try these one by one, and for each press the brightness keys and see if they generate events. Likely candidates for generating brightness key events are "Video Bus", something with your laptop model / manufacturer name in it, something with WMI in it, and the actual keyboard device. If one of these generates events for the brightness keys, and the events are KEY_BRIGHTNESSUP/DOWN then the detection of the keypresses works fine and there is a problem in the processing of them by your DE. If there are no events, or the events have the wrong key-codes, then file a bug against the kernel.

Note in some rare cases the OSD will not show, but the backlight brightness will change, this means all steps are done purely in the laptops firmware, and any DE brightness control / change notification will not be possible. There is nothing which can be done to fix this.

Debugging backlight control problems

Backlight control not working usually indicates a problem with one of the firmware interfaces. Note that if more then one backlight interface is present that DE-s will just pick one, DE-s prefer the firmware interfaces.

There are a number of kernel commandline options which influence the various firmware backlight drivers. To debug backlight control problems try these *one* by *one*, please do not mix and match! For each boot with a new kernel option do "ls /sys/class/backlight" and save the output + which kernel option it belongs to. The options below are listed from most likely to help to least likely. Once you've found an option which makes the backlight work properly, make sure to test it also works with suspend and resume, and then you can stop going through the list. Here are the options to try;

video.use_native_backlight=1

acpi_backlight=vendor

acpi_osi="!Windows 2012"

acpi_osi="!Windows 2009"

If you've found an on option that helps, please still file a bug, so that we can add a quirk to the kernel for your laptop model to do the right thing automatically. This way you will both help yourself when you install a new Linux version in the future, as well as others with the same model laptop.

Filing bugs

When filing a bug please for brightness problems please always put your exact laptop model in the Summary of the bug. Also please always run the following 2 commands:

dmesg > dmesg.log

grep '.*' /sys/class/dmi/id/*_* 2> /dev/null > dmi.log

And attach the 2 generated .log files to the bug-report.

When the bug is a problem about backlight control please also add the output of "ls /sys/class/backlight" for each boot with different kernel commandline
options you've tried, including the output for a boot without any kernel options.