- Correct value after boot, triggered by a message on questions@. I have looked the file history, and see that it was implemented previously, and backed out as breaking pure GPE lid switches -- it should not be a problem now as the logic has changed, and we send notifications based only on current value, without comparing it to previous one.
- Correct value after resume, PR240881.
- Correct the sysctl description while here.
Details
Details
Check dev.acpi_lid.0.state value after:
- Both open and closed lid: normal boot, 1 open, 0 closed.
- Closed lid: suspend using acpiconf -s3, resume by opening the lid, check state (state = 1).
- Closed lid: suspend using acpiconf -s3, resume using a power button on dock (state = 0).
- Open lid: suspend using acpiconf -s3, resume using a power button (state = 1).
Diff Detail
Diff Detail
- Repository
- rS FreeBSD src repository - subversion
- Lint
Lint Not Applicable - Unit
Tests Not Applicable
Event Timeline
| sys/dev/acpica/acpi_lid.c | ||
|---|---|---|
| 136 ↗ | (On Diff #68435) | Wonder if I should fix this description while here, it's somewhat misleading. |
| sys/dev/acpica/acpi_lid.c | ||
|---|---|---|
| 136 ↗ | (On Diff #68435) | Please do. |
| sys/dev/acpica/acpi_lid.c | ||
|---|---|---|
| 136 ↗ | (On Diff #68435) | Looks better now? |
| head/sys/dev/acpica/acpi_lid.c | ||
|---|---|---|
| 128 | This is now inconsistent with acpi_lid_notify_status_changed(), which checks the return value of acpi_GetInteger(... "_LID" ...) with if (ACPI_FAILURE(status)). (We should probably check the error return everywhere, or nowhere.) | |
| head/sys/dev/acpica/acpi_lid.c | ||
|---|---|---|
| 128 | I need to check in which cases we can expect an error. For the time being, failure in these code paths is not critical and will likely block attach for the LID driver. | |