Bug 207197
| Summary: | acpi_video0 appears and disappears on Lenovo ThinkPad E585 - Lenovo ThinkPad E585 | ||
|---|---|---|---|
| Product: | ACPI | Reporter: | Dāvis (davispuh) |
| Component: | Power-Video | Assignee: | Zhang Rui (rui.zhang) |
| Status: | ASSIGNED --- | ||
| Severity: | low | CC: | davispuh, pmenzel+bugzilla.kernel.org, rui.zhang |
| Priority: | P1 | ||
| Hardware: | x86-64 | ||
| OS: | Linux | ||
| Kernel Version: | 5.6.3 | Subsystem: | |
| Regression: | No | Bisected commit-id: | |
|
Description
Dāvis
2020-04-11 15:08:55 UTC
ACPI video driver has the API to unregister itself, and this API will be invoked by other drivers like graphics driver, when it knows that there is a better backlight control interface available. The decision of if and when to disable the ACPI video driver is not made by the ACPI video driver. Reading https://github.com/systemd/systemd/issues/15329, what is the status here? Should some mailing list be used to contact the maintainers about the issue? acpi_video backlight interface is registered and then replaced by the amdgpu_bl0. It is another problem that amdgpu_bl0 interface does not work, and I'm not sure which driver registers the amdgpu backlight interface after a quick search. But to me, the problem is why systemd-backlight still pokes the unregistered acpi_video0 interface when there is already an replacement. I think we need to get contact with the systemd-backlight owner. https://wiki.archlinux.org/index.php/Backlight#Save_and_restore_functionality "The systemd package includes the service systemd-backlight@.service, which is enabled by default and "static". It saves the backlight brightness level at shutdown and restores it at boot. The service uses the ACPI method described in #ACPI, generating services for each folder found in /sys/class/backlight/. For example, if there is a folder named acpi_video0, it generates a service called systemd-backlight@backlight:acpi_video0.service. When using other methods of setting the backlight at boot, it is recommended to stop systemd-backlight from restoring the backlight by setting the kernel parameters parameter systemd.restore_state=0. See systemd-backlight@.service(8) for details. Note: Some laptops have multiple video cards (e.g. Optimus) and the backlight restoration fails. Try masking an instance of the service (e.g. systemd-backlight@backlight:acpi_video1 for acpi_video1)." To me, "stop systemd-backlight from restoring the backlight by setting the kernel parameters parameter systemd.restore_state=0" is not a perfect solution. If user is okay when running with amdgpu_bl0, it means the cur_brightness in amdgpu_bl0 interface is the one user uses, thus we can quit systemd-backlight@backlight:acpi_video0.service smoothly and do save and restore in systemd-backlight@backlight:amdgpu_bl0.service as well. right? I was just thinking why we don't have this problem for Intel graphics, so an alternative solution is to do early check in acpi_video_init(). In acpi_video_init(), if we know the amd graphics driver is built and we know it has backlight control, we should stop registering the acpi_video backlight interface. is amdgpu_bl0 registered by kernel amd graphics driver? or are you using out of tree amd graphics driver? Do you know what is the proper place to raise this, Paul? |