GitLab

Uses gdk to get monitor information, tries to identify the builtin
monitor via the model string; if that fails uses the primary one,
and finally falls back to the first if none of that works.

In the case there we have less then 3 components for the kernel
we return the un-split string, but we need to make a copy of it
before.

Unbreaks the build. Ups.

If getting the renderer via the session fails, we can use a helper
binary provided by gnome-session to get the information.

Therefore we can simplify the code. The minimal interval we need
to wait to see any changes is UPDATE_FREQUENCY.

We are not reading it anymore anyway; everything is based on energy.

Having timestamps makes gbb significantly more useful for logging
because you can record and then later retrace what was happening.

https://bugzilla.gnome.org/show_bug.cgi?id=782062

We really support "energy" properly, so no need to pretend to
do for "capacity".

If the corresponding sys devices/entries are missing we should
still get 'Unknown' in the fields, but the fields should be
present.

Not only useful for humans, but also to synchronize the tests, i.e.
as an indicator when the monitor binary is started and delivering
notifications.

Currently only runs gbb info --json and checks that the simulated
battery has the right vendor and model.

We are now returning only energy values from GbbBattery, so we can
get rid of the charge related fields/functions/calculations from
everywhere that is not the GbbBattery itself.

That is, also return GbbMains, and rename it to
gbb_power_supply_discover.

Plan is to have own GbbBattery and GbbAdapter classes that can
then be used by GbbPowerMonitor and also GbbSystemInfo. New
code will be using GUdev.

That will make it easy to globally identify runs, which might come
in handy especially if we synchronize runs into a central database.

On Apple hardware the sysfs directory for the mains power supply
is called ADPx and not ACx.

https://bugzilla.gnome.org/show_bug.cgi?id=777149

Before trying to take the inhibitor lock via logind we should
check we actually have the logind connection, because we are not
failing in init() if we could not get the logind proxy.

We force stop the test runner, so the epilogue does not get played,
because it is very likely that the screen has already been locked by
gnome-shell and we would play the epilogue on the lock-screen.

This will stop the player and skip the playing of the epilogue; the
idea is to use this in emergency situations, e.g. when we are going
to sleep or really running out of battery soon.