Created Log Filters (markdown)

yuriks 2014-12-27 04:03:58 -08:00
parent 716897156a
commit 22ec24f9c4

29
Log-Filters.md Normal file

@ -0,0 +1,29 @@
Citra supports configurable filtering of log message per-class. This is especially useful if you're debugging a subsystem and want very detailed messages from it or if you want to silence some annoyingly spammy errors (e.g. unimplemented GPU features.)
Messages are filtered in each class according to their severity, the filter will block all messages in the class that are below the configured severity. The severity levels are:
- `Trace`: Extremely detailed and repetitive (many times per frame) debugging information that is likely to pollute logs.
- `Debug`: Less detailed debugging information.
- `Info`: Status information from important points during execution.
- `Warning`: Minor or potential problems found during execution of a task.
- `Error`: Major problems found during execution of a task that prevent it from being completed.
- `Critical`: Major problems during execution that threathen the stability of the entire application. (This severity cannot be filtered out.)
Note that `Trace` is *permanently filtered out in non-Debug builds* for performance reasons.
Class names can be discovered from the log messages themselves. For example, this message is in the class `Service`:
```
[ 10.285042] Service <Error> core/hle/service/service.h:Service::Interface::SyncRequest:84: unknown/unimplemented function '0x01020000': port=APT:U
```
Otherwise, a complete list can be found in the source in [log.h](https://github.com/citra-emu/citra/blob/master/src/common/logging/log.h#L37)
## Log Filters
To configure the log filter, edit the configuration file (either `qt-config.ini` or `glfw-config.ini`) and change the `log_filter` setting. The filter string consists of a space-separated list of filter rules, each of the format `<class>:<level>`. `<class>` is a log class name, with subclasses separated using periods. A rule for a given class also affects all of its subclasses. `*` wildcards are allowed and can be used to apply a rule to all classes or to all subclasses of a class without affecting the parent class. `<level>` a severity level name which will be set as the minimum logging level of the matched classes. Rules are applied left to right, with later rules overriding previous ones in the sequence.
A few examples of filter rules:
- `*:Info` -- Resets the level of all classes to Info.
- `Service:Info` -- Sets the level of Service and all subclasses (Service.FS, Service.APT,
etc.) to Info.
- `Service.*:Debug` -- Sets the level of all Service subclasses to Debug, while leaving the
level of Service unchanged.
- `Service.FS:Trace` -- Sets the level of the Service.FS class to Trace.