The docs are slightly ambiguous here but it appears a call to
sd_journal_next() is required at least once before the actual data
message.
journalctl positions the cursor with sd_journal_seek_tail() followed by
sd_journal_seek_previous(). The actual enty is then fetched with
sd_journal_next().
Let's do the same here and let's hope this fixes the current race
condition with the test sometimes failing.
pw_log_log/logv now go through the topic-based logger using the
"default" topic. Log topics themselves can be allocated by the call
sites. The simplest way to use a topic from e.g. a module:
PW_LOG_TOPIC_STATIC(mod_topic, "mod.foo");
#define PW_LOG_TOPIC_DEFAULT mod_topic
...
void pipewire__module_init() {
PW_LOG_TOPIC_INIT(mod_topic);
...
}
With the #define all pw_log_foo() are now routed through the custom
topic. For the cases where the log topic must be specified, a
pw_logt_foo() set of macros is available.
Log topics are enabled through the PIPEWIRE_DEBUG environment variable
which now supports globs, e.g. PIPEWIRE_DEBUG="*:I;mod.access:D"
to enable global INFO but DEBUG for the access module.
Namespaces documented are "pw", "mod" and "conn", for pipewire-internal
stuff, modules and connection dumping. The latter is special-cased to
avoid spamming the log files, it requires an expcit "conn.<glob>"
pattern to enable.
The "default" topic always exists and is the fallback for any
pw_log_foo() invocation that does not use a topic.
The tests using this function use the pw_log* macros which invoke
whichever logger pipewire has set. Since the default logging
implementation supports logging to a file anyway, let's just use that
instead of having to load the plugin ourselves.
Allow one of "XEWIDT" to refer to none, errors, warnings, info, debug
and trace, respectively because they're immediately recognizable. Well,
except maybe the X.
PIPEWIRE_DEBUG="I" is equivalent to PIPEWIRE_DEBUG="3" for example.
