Re: acpiconf -s 3 does not call acpi sleep event handlers
For those not on the bug, this is being followed up in PR 230290. On Wed, Aug 1, 2018 at 10:27 PM, Johannes Lundberg wrote: > > > On Thu, Aug 2, 2018 at 06:20 Andriy Gapon wrote: >> >> On 02/08/2018 01:17, Conrad Meyer wrote: >> > I don't understand the concern. There is only one listener to the >> > event and it just invokes ReqSleepState, which is responsible for >> > performing all suspend behavior. The behavior is identical between >> > lid close and acpiconf. >> >> Unless someone is adding a new listener for that event. > > > Exactly my point. > >> >> -- >> Andriy Gapon ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: acpiconf -s 3 does not call acpi sleep event handlers
On Thu, 2018-08-02 at 08:20 +0300, Andriy Gapon wrote: > On 02/08/2018 01:17, Conrad Meyer wrote: > > > > I don't understand the concern. There is only one listener to the > > event and it just invokes ReqSleepState, which is responsible for > > performing all suspend behavior. The behavior is identical between > > lid close and acpiconf. > Unless someone is adding a new listener for that event. > Or if there is some listener in some proprietary or local module that's not part of base freebsd. The ability to support modules that didn't exist at the time the event was added is exactly the main benefit of a loose-runtime-binding scheme such as event notifications. -- Ian ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: acpiconf -s 3 does not call acpi sleep event handlers
On Thu, Aug 2, 2018 at 06:20 Andriy Gapon wrote: > On 02/08/2018 01:17, Conrad Meyer wrote: > > I don't understand the concern. There is only one listener to the > > event and it just invokes ReqSleepState, which is responsible for > > performing all suspend behavior. The behavior is identical between > > lid close and acpiconf. > > Unless someone is adding a new listener for that event. > Exactly my point. > -- > Andriy Gapon > ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: acpiconf -s 3 does not call acpi sleep event handlers
On 02/08/2018 01:17, Conrad Meyer wrote: > I don't understand the concern. There is only one listener to the > event and it just invokes ReqSleepState, which is responsible for > performing all suspend behavior. The behavior is identical between > lid close and acpiconf. Unless someone is adding a new listener for that event. -- Andriy Gapon ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: acpiconf -s 3 does not call acpi sleep event handlers
I don't understand the concern. There is only one listener to the event and it just invokes ReqSleepState, which is responsible for performing all suspend behavior. The behavior is identical between lid close and acpiconf. On Wed, Aug 1, 2018 at 3:00 PM, Johannes Lundberg wrote: > > > On Wed, Aug 1, 2018 at 22:55 Conrad Meyer wrote: >> >> ReqSleepState is the routine that takes care of suspend, not the >> eventhandler. I'm not sure what difference the proposed change is >> supposed to make. > > > Listeners to acpi_sleep_event don’t get the event when suspending with > acpiconf (but they do when suspending via lid or sleep button). > > I think one would expect the same behavior when suspending via command line > or physical switch. > > >> >> >> Best, >> Conrad >> >> On Wed, Aug 1, 2018 at 2:48 PM, Johannes Lundberg >> wrote: >> > >> > >> > On Wed, Aug 1, 2018 at 9:15 PM Conrad Meyer wrote: >> >> >> >> It seems deliberate, although the commit message does not call it out >> >> and the event is perhaps poorly named. The event currently indicates >> >> that the lid was closed. And the final registered eventhandler for >> >> the event calls ReqSleepState. >> >> >> >> The ReqSleepState routine, as well as the userspace ioctl that >> >> 'acpiconf -s' uses (which just invokes ReqSleepState directly, rather >> >> than invoking the acpi sleep event), were introduced together in >> >> r170976. >> >> >> > >> > Unless there's a way of calling suspend properly from the cli (zzz uses >> > acpiconf...) maybe something like this makes more sense to get the same >> > behavior on for example lid close as zzz or acpiconf -s 3? (untested) >> > >> > diff --git a/sys/dev/acpica/acpi.c b/sys/dev/acpica/acpi.c >> > index c1bfd880c89..87b506d6bf5 100644 >> > --- a/sys/dev/acpica/acpi.c >> > +++ b/sys/dev/acpica/acpi.c >> > @@ -3700,7 +3700,8 @@ acpiioctl(struct cdev *dev, u_long cmd, caddr_t >> > addr, >> > int flag, struct thread *t >> > case ACPIIO_REQSLPSTATE: >> > state = *(int *)addr; >> > if (state != ACPI_STATE_S5) >> > - return (acpi_ReqSleepState(sc, state)); >> > + return ACPI_SUCCESS(AcpiOsExecute(OSL_NOTIFY_HANDLER, >> > + acpi_invoke_sleep_eventhandler, )) ? 0 : >> > ENXIO; >> > device_printf(sc->acpi_dev, "power off via acpi ioctl not >> > supported\n"); >> > error = EOPNOTSUPP; >> > break; >> > >> > >> >> >> >> Best, >> >> Conrad >> >> >> >> On Wed, Aug 1, 2018 at 8:05 AM, Johannes Lundberg >> >> wrote: >> >> > Hi >> >> > >> >> > As the title says, callbacks registered with >> >> > EVENTHANDLER_REGISTER(acpi_sleep_event, >> >> > does not get called when calling acpiconf -s 3. >> >> > They do however, when suspending with lid or sleep button. >> >> > >> >> > Is this deliberate or an oversight? >> >> > >> >> > Cheers >> >> > ___ >> >> > freebsd-current@freebsd.org mailing list >> >> > https://lists.freebsd.org/mailman/listinfo/freebsd-current >> >> > To unsubscribe, send any mail to >> >> > "freebsd-current-unsubscr...@freebsd.org" ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: acpiconf -s 3 does not call acpi sleep event handlers
ReqSleepState is the routine that takes care of suspend, not the eventhandler. I'm not sure what difference the proposed change is supposed to make. Best, Conrad On Wed, Aug 1, 2018 at 2:48 PM, Johannes Lundberg wrote: > > > On Wed, Aug 1, 2018 at 9:15 PM Conrad Meyer wrote: >> >> It seems deliberate, although the commit message does not call it out >> and the event is perhaps poorly named. The event currently indicates >> that the lid was closed. And the final registered eventhandler for >> the event calls ReqSleepState. >> >> The ReqSleepState routine, as well as the userspace ioctl that >> 'acpiconf -s' uses (which just invokes ReqSleepState directly, rather >> than invoking the acpi sleep event), were introduced together in >> r170976. >> > > Unless there's a way of calling suspend properly from the cli (zzz uses > acpiconf...) maybe something like this makes more sense to get the same > behavior on for example lid close as zzz or acpiconf -s 3? (untested) > > diff --git a/sys/dev/acpica/acpi.c b/sys/dev/acpica/acpi.c > index c1bfd880c89..87b506d6bf5 100644 > --- a/sys/dev/acpica/acpi.c > +++ b/sys/dev/acpica/acpi.c > @@ -3700,7 +3700,8 @@ acpiioctl(struct cdev *dev, u_long cmd, caddr_t addr, > int flag, struct thread *t > case ACPIIO_REQSLPSTATE: > state = *(int *)addr; > if (state != ACPI_STATE_S5) > - return (acpi_ReqSleepState(sc, state)); > + return ACPI_SUCCESS(AcpiOsExecute(OSL_NOTIFY_HANDLER, > + acpi_invoke_sleep_eventhandler, )) ? 0 : > ENXIO; > device_printf(sc->acpi_dev, "power off via acpi ioctl not > supported\n"); > error = EOPNOTSUPP; > break; > > >> >> Best, >> Conrad >> >> On Wed, Aug 1, 2018 at 8:05 AM, Johannes Lundberg >> wrote: >> > Hi >> > >> > As the title says, callbacks registered with >> > EVENTHANDLER_REGISTER(acpi_sleep_event, >> > does not get called when calling acpiconf -s 3. >> > They do however, when suspending with lid or sleep button. >> > >> > Is this deliberate or an oversight? >> > >> > Cheers >> > ___ >> > freebsd-current@freebsd.org mailing list >> > https://lists.freebsd.org/mailman/listinfo/freebsd-current >> > To unsubscribe, send any mail to >> > "freebsd-current-unsubscr...@freebsd.org" ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: acpiconf -s 3 does not call acpi sleep event handlers
On Wed, Aug 1, 2018 at 22:55 Conrad Meyer wrote: > ReqSleepState is the routine that takes care of suspend, not the > eventhandler. I'm not sure what difference the proposed change is > supposed to make. Listeners to acpi_sleep_event don’t get the event when suspending with acpiconf (but they do when suspending via lid or sleep button). I think one would expect the same behavior when suspending via command line or physical switch. > > Best, > Conrad > > On Wed, Aug 1, 2018 at 2:48 PM, Johannes Lundberg > wrote: > > > > > > On Wed, Aug 1, 2018 at 9:15 PM Conrad Meyer wrote: > >> > >> It seems deliberate, although the commit message does not call it out > >> and the event is perhaps poorly named. The event currently indicates > >> that the lid was closed. And the final registered eventhandler for > >> the event calls ReqSleepState. > >> > >> The ReqSleepState routine, as well as the userspace ioctl that > >> 'acpiconf -s' uses (which just invokes ReqSleepState directly, rather > >> than invoking the acpi sleep event), were introduced together in > >> r170976. > >> > > > > Unless there's a way of calling suspend properly from the cli (zzz uses > > acpiconf...) maybe something like this makes more sense to get the same > > behavior on for example lid close as zzz or acpiconf -s 3? (untested) > > > > diff --git a/sys/dev/acpica/acpi.c b/sys/dev/acpica/acpi.c > > index c1bfd880c89..87b506d6bf5 100644 > > --- a/sys/dev/acpica/acpi.c > > +++ b/sys/dev/acpica/acpi.c > > @@ -3700,7 +3700,8 @@ acpiioctl(struct cdev *dev, u_long cmd, caddr_t > addr, > > int flag, struct thread *t > > case ACPIIO_REQSLPSTATE: > > state = *(int *)addr; > > if (state != ACPI_STATE_S5) > > - return (acpi_ReqSleepState(sc, state)); > > + return ACPI_SUCCESS(AcpiOsExecute(OSL_NOTIFY_HANDLER, > > + acpi_invoke_sleep_eventhandler, )) ? 0 : > > ENXIO; > > device_printf(sc->acpi_dev, "power off via acpi ioctl not > > supported\n"); > > error = EOPNOTSUPP; > > break; > > > > > >> > >> Best, > >> Conrad > >> > >> On Wed, Aug 1, 2018 at 8:05 AM, Johannes Lundberg > >> wrote: > >> > Hi > >> > > >> > As the title says, callbacks registered with > >> > EVENTHANDLER_REGISTER(acpi_sleep_event, > >> > does not get called when calling acpiconf -s 3. > >> > They do however, when suspending with lid or sleep button. > >> > > >> > Is this deliberate or an oversight? > >> > > >> > Cheers > >> > ___ > >> > freebsd-current@freebsd.org mailing list > >> > https://lists.freebsd.org/mailman/listinfo/freebsd-current > >> > To unsubscribe, send any mail to > >> > "freebsd-current-unsubscr...@freebsd.org" > ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: acpiconf -s 3 does not call acpi sleep event handlers
On Wed, Aug 1, 2018 at 9:15 PM Conrad Meyer wrote: > It seems deliberate, although the commit message does not call it out > and the event is perhaps poorly named. The event currently indicates > that the lid was closed. And the final registered eventhandler for > the event calls ReqSleepState. > > The ReqSleepState routine, as well as the userspace ioctl that > 'acpiconf -s' uses (which just invokes ReqSleepState directly, rather > than invoking the acpi sleep event), were introduced together in > r170976. > > Unless there's a way of calling suspend properly from the cli (zzz uses acpiconf...) maybe something like this makes more sense to get the same behavior on for example lid close as zzz or acpiconf -s 3? (untested) diff --git a/sys/dev/acpica/acpi.c b/sys/dev/acpica/acpi.c index c1bfd880c89..87b506d6bf5 100644 --- a/sys/dev/acpica/acpi.c +++ b/sys/dev/acpica/acpi.c @@ -3700,7 +3700,8 @@ acpiioctl(struct cdev *dev, u_long cmd, caddr_t addr, int flag, struct thread *t case ACPIIO_REQSLPSTATE: state = *(int *)addr; if (state != ACPI_STATE_S5) - return (acpi_ReqSleepState(sc, state)); + return ACPI_SUCCESS(AcpiOsExecute(OSL_NOTIFY_HANDLER, + acpi_invoke_sleep_eventhandler, )) ? 0 : ENXIO; device_printf(sc->acpi_dev, "power off via acpi ioctl not supported\n"); error = EOPNOTSUPP; break; > Best, > Conrad > > On Wed, Aug 1, 2018 at 8:05 AM, Johannes Lundberg > wrote: > > Hi > > > > As the title says, callbacks registered with > > EVENTHANDLER_REGISTER(acpi_sleep_event, > > does not get called when calling acpiconf -s 3. > > They do however, when suspending with lid or sleep button. > > > > Is this deliberate or an oversight? > > > > Cheers > > ___ > > freebsd-current@freebsd.org mailing list > > https://lists.freebsd.org/mailman/listinfo/freebsd-current > > To unsubscribe, send any mail to " > freebsd-current-unsubscr...@freebsd.org" > ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: acpiconf -s 3 does not call acpi sleep event handlers
It seems deliberate, although the commit message does not call it out and the event is perhaps poorly named. The event currently indicates that the lid was closed. And the final registered eventhandler for the event calls ReqSleepState. The ReqSleepState routine, as well as the userspace ioctl that 'acpiconf -s' uses (which just invokes ReqSleepState directly, rather than invoking the acpi sleep event), were introduced together in r170976. Best, Conrad On Wed, Aug 1, 2018 at 8:05 AM, Johannes Lundberg wrote: > Hi > > As the title says, callbacks registered with > EVENTHANDLER_REGISTER(acpi_sleep_event, > does not get called when calling acpiconf -s 3. > They do however, when suspending with lid or sleep button. > > Is this deliberate or an oversight? > > Cheers > ___ > freebsd-current@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org" ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
acpiconf -s 3 does not call acpi sleep event handlers
Hi As the title says, callbacks registered with EVENTHANDLER_REGISTER(acpi_sleep_event, does not get called when calling acpiconf -s 3. They do however, when suspending with lid or sleep button. Is this deliberate or an oversight? Cheers ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
