e9c5057...
by
Benjamin Berg <email address hidden>
Release 3.38.2
d220063...
by
Hans de Goede <email address hidden>
rfkill: set the g_io_channel to unbuffered mode
Access to a /dev/foo device should never use buffered mode.
While debugging a gsd-rfkill issue I noticed in the g_debug output
that the rfkill-glib.c code now seems to be receiving bogus events.
Doing a strace I noticed some read(dev_rfkill_fd, buf, 8) calls,
even though we call:
g_io_channel_read_chars(..., sizeof(struct rfkill_event, ...)
Which requests 9 bytes. The problem is the kernel expects us to
read 1 event per read() system-call and it will throw away
excess data. The idea is here that the rfkill_event struct can
be extended by adding new fields at the end and then userspace code
compiled against older kernel headers will still work since it
will only read the fields it knows in a single call and the
extra fields are thrown away.
Since the rfkill-glib.c code was using buffered-io and asking
g_io_channel_read_chars for 9 bytes when compiled against recent
kernel headers, what would happen is that 2 events would be consumed
in 2 read(fd, buf, 8) syscalls and then the first byte of the
second event read would be appended to the previous event and
the remaining 7 bytes would be used as the first 7 bytes for the
next event (and eventually completed with the first 2 bytes of
the next event, etc.). Leading to completely bogus events.
cdd4229...
by
Benjamin Berg <email address hidden>
tests: Unset display environment variables
The environment variables were not correctly cleared. Fix this and also
make sure that we don't have the GNOME_SETUP_DISPLAY environment
variable leaking in from the outside.
70cadb7...
by
Benjamin Berg <email address hidden>
datetime: Load Olson DB on the fly instead of caching it
We need the database only quite irregularly (i.e. when the location
change). Just load the database on the fly when we need it, and discard
it afterwards to free up the memory again.
See also: !168
df6c69f...
by
Benjamin Berg <email address hidden>
datetime: Query GWeather DB on the fly instead of caching
We need the database only quite irregularly (i.e. when the location
change). Just grab the required information from GWeather on the fly and
destroy it immediately after. Also, use the API to only grab the cities
of one country instead of filtering them later.
power: Don't warn more than once per warning level for devices
A lot of wireless input devices, such as Logitech mice and touchpads, or
Bluetooth LE input devices, will disconnect and reconnect frequently
from the computer when unused.
This causes a problem when the battery on the device is low because
a new notification will be generated each time the device reconnects, as
if it was the first time it connected.
Saving the last warning-level for every external peripheral ensures that
we only emit one low battery notification for each warning-level, when
the threshold is crossed, rather than at every reconnect.
The last warning-level is not stored, so a new session, or a reboot will
cause devices to warn again once.
