[Milhouse]

will try this here on various systems with and without working upower, if it works i will report back so you can make a PR with this changes (or i help you with this) - nice find.

It works as a patch for a Pi, that's all I've tested with.

the problem here is xbmc calls "upower" to get if suspend/hibernate is supported. because upower depends on consolekit, which depends (still) on x11 librarys we dont include upower (also because supend/hibernate is not supported). this also means xbmc shows this options which are set as default because xbmc dont get the requested info

The problem is there is no valid power management option for the Pi, so it always uses the default null provider.

Here is the code to determine a suitable option:

Code:

#if defined(TARGET_DARWIN)
  m_instance = new CCocoaPowerSyscall();
#elif defined(TARGET_ANDROID)
  m_instance = new CAndroidPowerSyscall();
#elif defined(_LINUX) && defined(HAS_DBUS)
  if (CConsoleUPowerSyscall::HasConsoleKitAndUPower())
    m_instance = new CConsoleUPowerSyscall();
  else if (CConsoleDeviceKitPowerSyscall::HasDeviceConsoleKit())
    m_instance = new CConsoleDeviceKitPowerSyscall();
  else if (CSystemdUPowerSyscall::HasSystemdAndUPower())
    m_instance = new CSystemdUPowerSyscall();
  else if (CUPowerSyscall::HasUPower())
    m_instance = new CUPowerSyscall();
#ifdef HAS_HAL
  else
    m_instance = new CHALPowerSyscall();
#endif
#elif defined(_WIN32)
  m_instance = new CWin32PowerSyscall();
#endif

  if (m_instance == NULL)
    m_instance = new CNullPowerSyscall();
[

None of the Linux tests are performed, not even HAS_HAL, so I'm guessing HAS_DBUS is not defined. On a Pi, m_instance is always NULL, so is assigned an instance of CNullPowerSyscall.

So the question becomes - maybe one for Popcornmix - does the Pi have any kind of power management interface, and if so should the above test be modified rather than patching the properties of the default?

Edit: On further investigation, _LINUX and HAS_DBUS are both defined, but HAS_HAL isn't, so none of the four conditions tested within __LINUX && HAS_DBUS evaluate to true on a R-Pi, thus explaining why m_instance is always null before being assigned the default instance.