Bug 195116 - Display brightness control/resuming require acpi_video to be loaded after i915kms
Summary: Display brightness control/resuming require acpi_video to be loaded after i91...
Status: Closed Overcome By Events
Alias: None
Product: Base System
Classification: Unclassified
Component: kern (show other bugs)
Version: CURRENT
Hardware: Any Any
: --- Affects Only Me
Assignee: freebsd-acpi (Nobody)
URL: https://reviews.freebsd.org/rS367328
Keywords: i915
Depends on:
Blocks:
 
Reported: 2014-11-17 17:52 UTC by Lutz Bichler
Modified: 2022-03-17 16:08 UTC (History)
3 users (show)

See Also:


Attachments
Info of affected system (15.40 KB, text/plain)
2019-01-22 09:07 UTC, shadow53
no flags Details

Note You need to log in before you can comment on or make changes to this bug.
Description Lutz Bichler 2014-11-17 17:52:18 UTC
On an Asus UX31A (Ivybridge) it is required to load the acpi_video module after the i915kms module to be able to control the brightness (hw.acpi.video.lcd0.brightness) or to successfully resume the machine. 

Therefore, it is not possible to directly load the acpi_video module at startup
(especially because loading the i915kms module from loader.conf leads to a black screen on this machine).
Comment 1 shadow53 2019-01-22 09:07:42 UTC
Created attachment 201323 [details]
Info of affected system

Text file contains the output of pciconf -lv, /var/run/dmesg.boot, freebsd-version, and uname -a in that order.

System uses a system and kernel built from source, using the default GENERIC configuration for amd64. Had this issue using the default binary updates as well.
Comment 2 shadow53 2019-01-22 09:12:19 UTC
New to bugzilla - didn't realize the attaching of files was its own comment.

The system described in the attachment has this same issue, where brightness cannot be controlled if acpi_video is loaded on boot but can be controlled if the module is unloaded and loaded again. The system is a laptop with an Intel Skylake i5 processor and Optimus graphics, using only the Intel card.

I have not run into issues with black screens, though that may be because I'm using the i915kms module from the drm-fbsd12.0-kmod package, loaded using kld_list in rc.conf.
Comment 3 freebsd 2022-03-17 06:41:40 UTC
I see the same issue -- "where brightness cannot be controlled if acpi_video is loaded on boot but can be controlled if the module is unloaded and loaded again" -- with 14-CURRENT c 20220316 on Framework laptop (Intel i5-1135G7 CPU).
Comment 4 freebsd 2022-03-17 06:58:55 UTC
Apparently order matters of values assigned to a variable in /etc/rc.con. Now I have ...

kld_list="filemon"
kld_list="$kldlist i915kms"
kld_list="$kldlist acpi_video"


... ... now the MIBs in /etc/sysctl.conf related to "hw.acpi.video.lcd0" are not reported as unknowns.

Earlier I had ...

kld_list="filemon"
kld_list="$kldlist acpi_video"
kld_list="$kldlist i915kms"
Comment 5 freebsd 2022-03-17 07:07:12 UTC
That's what I get for not copying-pasta. There were too many technical errors in previous 💩response. I will be grateful if the comment #3 is stricken out|hidden|deleted.🙇‍♂️

In any case, corrected response ...

Apparently order matters of values assigned to a variable in /etc/rc.conf. Now I have ...

kld_list="filemon"
kld_list="$kld_list i915kms"
kld_list="$kld_list acpi_video"


... ... now the brightness related "hw.acpi.video.lcd0" MIBs in /etc/sysctl.conf  are not reported as unknowns.

Earlier I had ...

kld_list="filemon"
kld_list="$kld_list acpi_video"
kld_list="$kld_list i915kms"
Comment 6 Dries Michiels freebsd_committer freebsd_triage 2022-03-17 07:21:38 UTC
This has been documented about year ago in https://www.freebsd.org/cgi/man.cgi?acpi_video.
"compatibility". is this sufficient to close this issue?
Comment 7 Dries Michiels freebsd_committer freebsd_triage 2022-03-17 16:08:07 UTC
Feel free to reopen, but this is by technical design and is documented as such.