| View previous topic :: View next topic |
| Author |
Message |
equaeghe
l33t
Joined: 22 Feb 2005
Posts: 654
|
 Posted: Sat Feb 06, 2021 9:03 pm Post subject: [solved] Len. T14 AMD: brightness ctrl not effective under… |
 |
|
I have a Lenovo Thinkpad T14 AMD. I have Gentoo wit Plasma installed. When I use the brightness control keys, the brightness change overlay appears, but does nothing when changed. The brighness level shown is at 0% when reducing brightnes. When increasing brightness, the levels shown are increasing in steps of about 6.5% (7-13-20-…), but the actual brighness does not change.When releasing the brightness control key for a moment, the brightness goes back to 0%.
The kernel does support backlight changes:
| Code: | /sys/class/backlight # tree -l -L 2
.
├── amdgpu_bl0 -> ../../devices/pci0000:00/0000:00:08.1/0000:07:00.0/backlight/amdgpu_bl0
│ ├── actual_brightness
│ ├── bl_power
│ ├── brightness
│ ├── device -> ../../../0000:07:00.0
│ ├── max_brightness
│ ├── power
│ ├── scale
│ ├── subsystem -> ../../../../../../class/backlight [recursive, not followed]
│ ├── type
│ └── uevent
└── thinkpad_screen -> ../../devices/virtual/backlight/thinkpad_screen
├── actual_brightness
├── bl_power
├── brightness
├── max_brightness
├── power
├── scale
├── subsystem -> ../../../../class/backlight [recursive, not followed]
├── type
└── uevent |
putting a value in amdgpu_bl0/brightness changes the brightness. I do not know what thinkpad_screen is; its brightness is at 0 even though in reality this is not so.
Perhaps Plasma is writing to thinkpad_screen/brightness instead of amdgpu_bl0/brightness? How can I find out? Perhaps something else is wrong?
Last edited by equaeghe on Thu Mar 11, 2021 8:12 am; edited 1 time in total |
|
| Back to top |
|
 |
alamahant
Advocate
Joined: 23 Mar 2019
Posts: 3950
|
| Posted: Sun Feb 07, 2021 10:33 am Post subject: |
|
|
Hi
Does thinkpad_screen/brightness and amdgpu_bl0/brightness point to the same device?
They may be symlinks to a device.Is it the same?(ls -l)
If not maybe symlink amdgpu_bl0/brightness to thinkpad_screen/brightness (ln -sf)
Do symlinks under /sys even work?Please experiment..
Normally you shoudnt be forced to do dirty tricks like that but from reading posts in this forum it appears plasma is a very glitchy product...
Many failures when compiling,problems with polkit,problems with brightness etc etc etc...
If the symlink solution works you may wish to make it permanent or just resign to echoing values to brightness to adjust it.....
_________________
|
|
| Back to top |
|
|
equaeghe
l33t
Joined: 22 Feb 2005
Posts: 654
|
| Posted: Sun Feb 07, 2021 1:32 pm Post subject: |
|
|
| alamahant wrote: | | Does thinkpad_screen/brightness and amdgpu_bl0/brightness point to the same device? |
No. thinkpad_screen is a virtual device and does not point to any real device.
| alamahant wrote: | | They may be symlinks to a device.Is it the same?(ls -l) |
No.
| alamahant wrote: | | If not maybe symlink amdgpu_bl0/brightness to thinkpad_screen/brightness (ln -sf) |
No, I'm not going to do such hacks, it should be solvable without, I hope.
| alamahant wrote: | | Do symlinks under /sys even work? |
Yes. |
|
| Back to top |
|
|
jbaldassari
n00b
Joined: 24 Mar 2009
Posts: 13
|
| Posted: Thu Mar 04, 2021 12:32 am Post subject: |
|
|
I'm hitting a similar problem on my new P14s. After some investigation I found that the brightness controls on the keyboard seem to be changing the brightness of the thinkpad_screen device rather than the amdgpu_bl0 device. Also, when using the keyboard controls, I can only get the value of thinkpad_screen's brightness to toggle between 1 and 2. It doesn't seem to support any other values.
If I echo values into /sys/class/backlight/amdgpu_bl0/brightness it does adjust the screen brightness correctly. So it seems like the only issue here is that something (systemd? gnome?) is manipulating the wrong device in response to brightness inputs. |
|
| Back to top |
|
|
jbaldassari
n00b
Joined: 24 Mar 2009
Posts: 13
|
| Posted: Thu Mar 04, 2021 1:34 am Post subject: |
|
|
Well I accidentally fixed the problem while trying to debug it
Here's what fixed it for me. First, ensure that you have the thinkpad_acpi module loaded. I was experimenting with removing this module, which causes the thinkpad_screen device to disappear, but in the end this module turned out to be necessary because the acpi events for the screen brightness buttons do not fire without it.
Next, make sure you have the acpid service installed/running:
| Code: |
emerge sys-power/acpid
systemctl enable --now acpid
|
That's all I needed to do. Once you have acpid running you can watch the events by running
While listening for acpi events, hit the screen brightness up/down control keys, and you should see the events coming through if it's all working correctly.
I should also mention that I have the following kernel settings in /etc/default/grub, although I'm not sure whether they are necessary:
| Code: |
acpi_osi=Linux acpi_backlight=native
|
|
|
| Back to top |
|
|
jbaldassari
n00b
Joined: 24 Mar 2009
Posts: 13
|
| Posted: Sat Mar 06, 2021 6:09 am Post subject: |
|
|
There's one more thing I discovered about thinkpad_acpi, and maybe this will help solve the OP's problem as well. For whatever reason it makes a big difference when this module is loaded. If it's loaded immediately on boot the brightness controls do not work as described in this thread. However, if you delay inserting the module until the system has completely booted up, at least into your display manager, then the display controls seem to work. So first what I had to do was prevent the module from loading automatically by creating /etc/modprobe.d/blakclist.conf with this line:
| Code: |
blacklist thinkpad_acpi
|
After that I tried many different ways of delaying the module insertion. I created a oneshot systemd service to modprobe thinkpa_acpi and then tried to make it run after various services like acpid, gdm, NetworkManage, etc., but no matter what I did it was always getting inserted too early. The last resort was creating a systemd timer to insert the module at a fixed time after boot. This is really not ideal, but I just couldn't find any other way to get it all working. So I now have these in /etc/systemd/system:
thinkpad-acpi.service:
| Code: |
[Unit]
Description=Loads thinkpad_acpi module
[Service]
Type=oneshot
ExecStart=/bin/sh -c 'modprobe thinkpad_acpi'
[Install]
WantedBy=default.target
|
thinkpad-acpi.timer:
| Code: |
[Unit]
Description=thinkpad-acpi timer
[Timer]
OnBootSec=15s
Unit=thinkpad-acpi.service
[Install]
WantedBy=default.target
|
Then just enable the timer with:
| Code: |
systemctl enable thinkpad-acpi.timer
|
|
|
| Back to top |
|
|
equaeghe
l33t
Joined: 22 Feb 2005
Posts: 654
|
| Posted: Tue Mar 09, 2021 7:51 am Post subject: |
|
|
| jbaldassari wrote: | First, ensure that you have the thinkpad_acpi module loaded.
Next, make sure you have the acpid service installed/running:
[…]
Once you have acpid running you can watch the events by running
|
All this seems OK for me, but the events are not handled (from the logs):
| Code: | ACPI event unhandled: video/brightnessup BRTUP 00000086 00000000 K
ACPI event unhandled: video/brightnessdown BRTDN 00000087 00000000 K |
| jbaldassari wrote: |
I should also mention that I have the following kernel settings in /etc/default/grub, although I'm not sure whether they are necessary:
| Code: |
acpi_osi=Linux acpi_backlight=native
|
|
I have tested this (with/without), but it doesn't make a difference for me.
| jbaldassari wrote: |
There's one more thing I discovered about thinkpad_acpi, and maybe this will help solve the OP's problem as well. For whatever reason it makes a big difference when this module is loaded. If it's loaded immediately on boot the brightness controls do not work as described in this thread. However, if you delay inserting the module until the system has completely booted up, at least into your display manager, then the display controls seem to work. |
I tested this (blacklisting and then modprobing) and it didn't seem to help, but perhaps I didn't wait long enough still. |
|
| Back to top |
|
|
jbaldassari
n00b
Joined: 24 Mar 2009
Posts: 13
|
| Posted: Wed Mar 10, 2021 11:15 pm Post subject: |
|
|
| Quote: |
I tested this (blacklisting and then modprobing) and it didn't seem to help, but perhaps I didn't wait long enough still.
|
If I blacklist the driver and then modprobe it manually after logging into the desktop it seems to work fairly well, but I haven't found a reliable way to automate it yet. The systemd timer seems to work sometimes but not always. I also tried using an idle service instead of a timer:
| Code: |
[Unit]
Description=Loads thinkpad_acpi module
[Service]
# Run after all other startup jobs
Type=idle
ExecStart=/bin/sh -c 'modprobe thinkpad_acpi'
[Install]
WantedBy=default.target
|
The results are similarly unreliable. Maybe I'll try an xdg autostart (/etc/xdg/autostart/) script next. |
|
| Back to top |
|
|
equaeghe
l33t
Joined: 22 Feb 2005
Posts: 654
|
| Posted: Thu Mar 11, 2021 8:11 am Post subject: |
|
|
| For me, it turned out to be a missing kernel config! I didn't have ACPI_VIDEO enabled. After I did, things worked automatically. More details in the Lenovo Forums. |
|
| Back to top |
|
|
|
Kernel & Hardware
