66d97f5...
by
Benjamin Berg <email address hidden>
rfkill-glib: Rework async CHANGE repeat logic
Currently we could end up sending to write events at the same time,
because e.g. the previous one has been cancelled but did not yet finish.
Rework the async logic, also changing the bluetooth repeat logic
slightly to repeat all "broken" change events for a certain period
(rather than just always reacting to the first change event).
Closes: #332
f33abac...
by
Benjamin Berg <email address hidden>
Release 40.0.1
f80f993...
by
Nishal Kulkarni <email address hidden>
night-light: Minor get_property fix
Current behavior:
`gsd_night_light_get_property` function would set the wrong value,
value for PROP_SUNSET and PROP_TEMPERATURE was set to cached_sunrise
Minor Fix:
For PROP_SUNSET case set value to cached_sunset.
For PROP_TEMPERATURE case set value to cached_temperature.
1ec87c5...
by
Benjamin Berg <email address hidden>
rfkill: Do not sync state immediately when opening rfkill
We are opening the device asynchronously anyway. There is really no need
to sync the state immediately, we can simpl rely on the POLL handler to
do so later on from the mainloop.
The difference we should see is that the debug information about there
being no rfkill devices is gone. And, that some of the debug messages
will be slightly different.
f6ce8d3...
by
Benjamin Berg <email address hidden>
rfkill: Fix rfkill event read length check
The kernel may return a short read for rfkill events in case it is using
an older API version while g-s-d was compiled using the newer struct. As
this is perfectly valid, we need to check the read length against
RFKILL_EVENT_SIZE_V1 rather than the size of the struct.
d7a414c...
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.
