Otherwise we’ll keep adding the same channel(s) over and over again,
for each (successful) connect attempt.
I.e. if you plug and unplug an USB soundcard repeatedly, we’ll keep
extending the channel list each time.
When e.g. a USB soundcard is inserted, we get several CREATE
events. In my experiments, we only succeed in connecting to ALSA after
the last event.
This means, we’ll have several CREATE events that we receive, remove
the watcher, attempt to connect, fail, and then re-add the watcher.
What if that “last” CREATE event occurs while our watcher has been
removed? That’s right, we miss it, and will get stuck waiting forever.
The solution is keep the watcher around.
Now, if we’ve been successfully connected to ALSA for a long time,
chances are we’ve built up events (for other cards, for example). We
don’t want to trigger a storm of re-connect attempts, so drain the
event queue after having been disconnected from ALSA.
There *is* a small race here - if a card is removed and
re-added *very* fast, we _may_ accidentally drain the CREATE event. I
don’t see this happening in reality though.
While waiting for the configured ALSA card to become available, use
inotify and watch for CREATE events on /dev/snd instead of
polling (using a timeout in the poll(3) call).
Note that we don’t know the actual names of the files that (will) be
created. This means:
* Every time we see a CREATE event on /dev/snd, we *try* to connect to
ALSA. If we fail, we go back to watching /dev/snd again.
* ALSA (not yambar) will log an error message each time we fail.
These options allows you to select which channel to use as volume
source, and which channel to use as the source for the muted state.
With this, we can also remove the check for *all* (playback) channels
having the same volume/muted state. And with that, we no longer need
to warn when not all channels have the same volume/muted state.
With this patch, a non-existing ALSA device is no longer considered a
fatal error. Instead, we keep retrying until we succeed.
Furthermore, if we have successfully opened the ALSA device, and it
then disappears, we a) no longer crash, or cause 100% CPU usage, and
b) try to re-connect to the device.
With this, we now handle e.g. USB soundcards being disconnected and
then re-connected. We should also handle pseudo devices, like pipewire
provides ones, when yambar is started before pipewire.
Closes#59Closes#61Closes#86
When set, river tags and seats’ view titles apply to the output yambar
is on, only.
The default is disabled, which implements the old behavior, where
river tags and seats’ view titles represent the union of all
outputs.
Add ‘persistent’, a list-of-strings specifying workspace names that
should be persistent. That is, workspaces that should never be
removed, even if empty.
Note that the workspaces _are_ still destroyed (in i3/Sway), but
yambar keeps abstractions for them around. This is useful to e.g. keep
a strict order between your “core” workspaces.
Closes#72
When set to a non-negative value, the script module will call the
configured script every <poll-interval> second.
In this mode, the script is expected to write one tag set and then
exit.
This is intended to simplify the implementation of scripts that would
otherwise just do a loop + sleep.
Closes#67
Some batteries support charge thresholds and when the upper limit is set to a number less than 100 percent and it reaches that limit and it is connected to the charger the battery state will be "Not charging".
It doesn't charge anymore despite it's not full.
Some battery drivers will remove their sysfs directory when the
battery goes from charging to discharging, or vice verse.
This caused yambar’s battery module to terminate, resulting in the
last known battery state to “freeze”.
With this patch, failure to read the battery directory the *first*
time is still considered a hard failure, resulting in an error message
and then termination.
However, subsequent failures, i.e. while polling the battery state,
is *not* considered fatal; we simply don’t update the bar, and retry
again the next poll interval. Error messages are still logged however.
Closes#44
This is already being done in the initial query response. Not doing it
in the input event handler too leads to an assertion if there are
multiple devices with the same ID.
Hopefully fixes#54
When sorting workspaces in ascending order, put numerical
workspaces *after* non-numerical ones.
When sorting in descending order, put numerical workspaces *before*
non-numerical.
In both cases, sort numerical workspaces using a numerical comparison,
rather that doing a lexicographical sorting.
Closes#30
96d2d057e0
added a new tag, ‘volume’, but didn’t bump the tag count.
This meant the last tag in the set, ‘elapsed’ was never seen by
anybody, and not free:d when the tag set was free:d.
Assume that a closed pipe means the child died. Even if it hasn’t, we
can’t read anymore from it. We’ll end up killing it anyway before
returning from run().
This is mainly to fix a race when river is *not* running; sometimes we
ended up allocating particles for N seats in content(), but then when
iterating the seats, run() had destroyed all, or some of the seats,
causing us to feed NULL pointers to dynlist, which crashed.
* Verify int/float/bool values are that, and nothing else
* Verify tag ranges are integers
* Verify a range tag value is inside its range
* Don’t allow anything but false|true for booleans
User is expected to send ‘false’ or ‘true’. But we were parsing the
value using `strtol()`. This caused all bools to be false, since
`strtol()` would always return 0.
