mrw;593894 Wrote:
> @gharris
>
> Thank you very much for that. I'll work through and see how I get on.
>
> An OSX sleep inhibit app might be made with a cut down version of
> SleepWatcher (it is GPL 2). I think it could boil down to just a few
> lines of C code. Launch the cut-down and it sits in the background,
> preventing sleep when OSX tries to sleep. Kill it, or signal it in some
> way, and normal service is resumed.
>
> And then I wonder if the necessary system hook could be/has been
> incorporated into a perl module.
Thus far, my approach with ReallyPreventStandby has been to try to
duplicate on linux/gnome and OSX what the stock PreventStandby plugin
does with windows, i.e. while SBS is not idle, the plugin will tell the
system every minute:
don't sleep for the next two minutes
don't sleep for the next two minutes
don't sleep for the next two minutes
don't sleep for the next two minutes
..etc., until the plugin
On linux/gnome, this is accomplished by ReallyPreventStandby executing
gsession-inhibit which makes a dbus call to the gnome-session-manager's
Inhibit function. gsession-inhibit then idles for a minute and then
makes another dbus call to un-inhibit the session manager. While this
hanging-around-for-a-minute is unfortunate, it seems to be necessary as
gnome-session-manager will cancel an inhibition as soon as an inhibiting
app terminates.
I'm trying to do more or less the same thing with my OSX app by calling
the core services UpdateSystemActiviy() function. I've yet to really
figure out how to navigate Xcode's documentation system so I don't know
if I'll be able to, say, inhibit sleep without inhibiting monitor
turn-off. What the documentation does reveal, however, is that
UpdateSystemActiviy() needs to be called at least every 30 seconds.
Anyway, both these approaches are at odds with the SleepWatcher
approach, which comes at the problem from the opposite direction, i.e.
a system daemon gets power management notifications from the system,
queries SBS to see if it is idle and then tells the system if it's OK
to sleep or not.
Either approach ought to work. Again, I picked the former simply
because it was closest to the model that PreventStandby uses with
Windows.
PS: ReallyPreventStandby's definition of "not-idle" is very close to
what is used in the current PreventStandby plugin:
SBS will not-be-idle if:
- the system has resumed from sleep within the INTERVAL time + 5
seconds.
- if the "Prohibit standby if players are on?" setting is checked and
any attached player is powered on.
- If any player is currently doing a firmware upgrade or playing
content.
- If SBS is doing a library scan. (Sorry..I don't think it knows
about Lazyfacation scans.)
- If it has been fewer than X idle-minutes since the last not-idle, X
being controllable in the settings.
Remember, the "idle-slack-time" feature in PreventStandby debuted back
in January '09 in the original incarnation of ReallyPreventStandby and
was driven by Windows XP's propensity to go back to sleep 2 minutes
after a WOL no matter how you had the system's power management
settings set.
--
gharris999
------------------------------------------------------------------------
gharris999's Profile: http://forums.slimdevices.com/member.php?userid=115
View this thread: http://forums.slimdevices.com/showthread.php?t=48521
_______________________________________________
plugins mailing list
[email protected]
http://lists.slimdevices.com/mailman/listinfo/plugins
