acpi_lid: correct Lid state after boot and resume

[yuripv]

Summary

1. 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.
2. Correct value after resume, PR240881.
3. Correct the sysctl description while here.

Test Plan

Check dev.acpi_lid.0.state value after:

1. Both open and closed lid: normal boot, 1 open, 0 closed.
2. Closed lid: suspend using acpiconf -s3, resume by opening the lid, check state (state = 1).
3. Closed lid: suspend using acpiconf -s3, resume using a power button on dock (state = 0).
4. Open lid: suspend using acpiconf -s3, resume using a power button (state = 1).

[yuripv]

sys/dev/acpica/acpi_lid.c

136 ↗

(On Diff #68435)

Wonder if I should fix this description while here, it's somewhat misleading.

[• hselasky]

sys/dev/acpica/acpi_lid.c

136 ↗

(On Diff #68435)

Please do.

[yuripv]

Correct sysctl description.

[yuripv]

sys/dev/acpica/acpi_lid.c

136 ↗

(On Diff #68435)

Looks better now?

[cem]

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.)

[• hselasky]

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.