If a device is removed while the computer is hibernating, and then
reconnected after waking it up, Sway sends an “added” event without
first sending a “removed” event.
Yambar used to assert that an “added” event didn’t refer to an already
tracked device.
This patch changes this, and simply ignores duplicate “added” events.
Closes#177
Seat status v3 adds a new ‘mode’ event, that informs us of the current
mode (as set by e.g. ‘riverctl enter-mode passthrough’)
The mode is exposed as a tag (named “mode”) on river’s “title”
particle:
- river:
title:
map:
default: {empty: {}}
conditions:
mode == passthrough:
string: {text: " {mode} ", deco: {background: {color: ff0000ff}}}
/proc/stat lists CPU usage, in the form:
cpu ...
cpu0 ...
cpu1 ...
...
cpuN ...
where the first line is a summary line. We’ve been using the CPU
numbers from /proc/stat to index into our internal stats array.
This doesn’t work on systems where the core IDs aren’t
consecutive. Examples of such systems are SMT systems with SMT
disabled. Here, /proc/stat may look like this instead:
cpu ...
cpu0 ...
cpu2 ...
cpu4 ...
...
With this patch, we ignore the CPU ID from /proc/stat. Instead, we use
a simple counter that is incremented for each (valid) cpu line found
in /proc/stat. To protect against corrupt /proc/stat content, stop
parsing /proc/stat if the number of parsed CPU lines exceed what we
consider to the be total number of CPUs in the system.
Closes#172
All FDs should now have the CLOEXEC flag set, and thus there’s no
longer needed to manually loop “all” possible FDs and (trying to)
close them.
Note: the alsa module (alsalib, actually) is “racy” - while booting
up, it temporarily opens the asoundrc file without CLOEXEC. If
e.g. the script module starts its script inside this window, it’ll
have a leaked FD. Not much we can do about it though :/
Closes#169
This ensures we don’t leak FDs when exec:ing e.g. on-click
handlers.
Note that the comm-pipe FD is *supposed* to stay open when we execing
the script. This is handled by the call to dup2(), which drops the
CLOEXEC flag. Since dup2() is called after the fork, the dup:ed FD is
never visible in the “parent” yambar process.
On i3, users are currently greeted with:
err: modules/i3.c:94: workspace reply/event without 'name' and/or
'output', and/or 'focus' properties
This patch makes ‘focus’ an optional attribute. When missing, we
assume a node-count of 0, which means the workspace’s ‘empty’ tag will
always be true. Document this in the i3 man page.
This is a boolean option. When set, “N:” prefixes will be stripped
from the workspaces’ name tag, *after* having been sorted (if the
‘sort’ option is being used).
This makes it useful to arrange the workspaces in a fixed order, by
prefixing the names with a number in the Sway config:
set $ws1 “1:xyz”
set $ws2 “2:abc”
Then, in the yambar config:
i3:
sort: ascending
strip-workspace-numbers: true
Audio CDs are special, in that they don’t (usually) have any data
partitions. They also don’t have a volume label. They just have
tracks.
Before this patch, we ignored all optical mediums that did *not* have
a filesystem (that includes audio CDs).
Now, instead of using the ID_FS_USAGE property to determine whether
there’s media present in the CD-ROM or not, we use the
ID_CDROM_MEDIA. This property is set to ‘1’ for both audio CDs and
data CDs.
Then, we read the ID_CDROM_MEDIA_TRACK_COUNT_AUDIO property to
determine how many audio tracks there are.
If the CD has a filesystem, we treat it as a data CD, and use the
already existing add_partition() function to track it.
If the CD does _not_ have a filesystem, but it _does_ have at least
one audio track, we treat it as an audio CD and use the new
add_audio_cd() function to track it.
This function is almost identical to add_partition(), but instead of
reading the ID_FS_LABEL property, it reads the
ID_CDROM_MEDIA_TRACK_COUNT_AUDIO property and synthesizes a label on
the form “Audio CD - N tracks”.
Finally, a new boolean tag, “audio”, has been added. It is set to true
for audio CD “partitions”, and to false in all other cases.
Set to true for empty (no windows) workspaces.
Mostly useful with persistent workspaces, to be able to differentiate
between invisible non-empty workspaces and actually empty
workspaces (the latter not being possible with non-persistent
workspaces).
This fixes an issue where we sometimes failed to retrieve the SSID; we
sent one initial request before the family ID had been set.
Then, we received the family ID and tried to send another
request. However, if the first request was still in progress, the
second request was never made.
Since the first request lacked the family ID, that response didn’t
contain anything useful.
Without this change yambar can't be installed/used without libmpdclient even for
people who do not use MPD. Let's make this optional.
We could put the optional module summary in the module meson.build but we'd have
to move summary() in main meson.build so that they appear in proper order.
This adds a new ‘poll-interval’ option to the network module. When set
to a non-zero value, the following Wi-Fi stats will be updated:
* Signal strength
* RX+TX bitrate
This cleans up the nl80211 handling quite a bit, and adds initial
support for nl80211 notifications.
* We now join the nl80211 MLME multicast group (done by parsing the
CTRL_ATTR_MCAST_GROUPS attribute in the reply to our
CTRL_CMD_GETFAMILY request). This gives us CONNECT and DISCONNECT
notifications, allowing us to request and reset SSID that way, instead
of detecting the link’s OPER state.
* Before parsing an nl80211 message, verify it’s for us, by looking
for a NL80211_ATTR_IFINDEX attribute in the message (and comparing the
contents with our previously detected ifindex).
This mostly comes down to tracking whether each channel is a playback,
or capture channel, and using the appropriate APIs when dealing with
it.
Some cleanup related to this:
* Add a channel struct, for per-channel data. Previously, our channel
list was just a list of ALSA channel IDs.
* We now store current volume per-channel (but volume min/max is
per-device)
* Muted state is stored per-channel
* Track both the device’s playback and capture volume ranges, as well
as whether the device *has* playback or capture volume.
* Get the playback/capture volume ranges once, during init, instead of
at each update.
* Use struct pointers for the volume/muted channels. This way we don’t
have to iterate all channels and to string comparisons on the name
each time we update our state.
