Skip site navigation (1)Skip section navigation (2)
Date:      Fri, 29 Sep 2017 16:23:14 +0000
From:      bugzilla-noreply@freebsd.org
To:        freebsd-bugs@FreeBSD.org
Subject:   [Bug 222691] Thinkpad t440p - lid sysctl gets confused
Message-ID:  <bug-222691-8@https.bugs.freebsd.org/bugzilla/>

next in thread | raw e-mail | index | archive | help
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D222691

            Bug ID: 222691
           Summary: Thinkpad t440p - lid sysctl gets confused
           Product: Base System
           Version: CURRENT
          Hardware: amd64
                OS: Any
            Status: New
          Severity: Affects Only Me
          Priority: ---
         Component: misc
          Assignee: freebsd-bugs@FreeBSD.org
          Reporter: bsd@haps.ca

Created attachment 186804
  --> https://bugs.freebsd.org/bugzilla/attachment.cgi?id=3D186804&action=
=3Dedit
AC adapter state change script to put the notebook into sleep on ac disconn=
ect,
but only if the lid is closed.

I have created a small acpi script (attached) to monitor the ac line and
suspend the machine if the ac line is removed while the lid is closed.  This
script complements the lid script that suspends the machine if the lid is
closed on battery.

I have found, however, that the value of the lid sysctl changes without a
hardware state change.  My guess is that there is some condition where the =
lid
is closed or opened that the sysctl doesn't update.

For example, my log shows:
 ACLINE Event.  acline devd value:\'0x01\', lid sysctl:\'0\'.
 AC Power inserted when lid was closed. No need for sleep.

However, the lid was open.  Typically ``sysctl -n dev.acpi_lid.0.state'' is=
 0
for closed lid, 1 for open.  I actually don't care what the value is, as lo=
ng
as it remains consistent, I guess the devd side of things stays constant (w=
hich
is even more confusing) - the event 0x01 =3D open event, 0x00 =3D close eve=
nt.

--=20
You are receiving this mail because:
You are the assignee for the bug.=



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?bug-222691-8>