mirrors/labwc
1
0
Fork 0
mirror of https://github.com/labwc/labwc.git synced 2025-10-29 05:40:24 -04:00
Code Issues Projects Releases Packages Wiki Activity Actions

CONTRIBUTING.md: add notes on debugging

Browse source
This commit is contained in:
Johan Malm 2022-05-26 21:51:17 +01:00
parent 163179dda1
commit 48e787ba10
1 changed files with 35 additions and 0 deletions
Download patch file Download diff file Expand all files Collapse all files

35
CONTRIBUTING.md
View file

@ -2,6 +2,41 @@
## How to Contribute
## Debugging
There is no one-way-fits-all method for debugging, so you have to use your antennae and do some dective work.
This section contains some approachies which may prove useful.
If the compositor crashes, a good starting point is to produce a backtrace by building with ASAN/UBSAN:
```
meson -Db_sanitzise=address,undefined build/
ninja -C build/
```
Get debug log with `labwc -d`. The log can be directed to a file with `labwc -d 2>log.txt`
To see what is happening on the wayland protocol for a specific client, run it with environment variable `WAYLAND_DEBUG` set to 1, for example:
```
WAYLAND_DEBUG=1 foot
```
To see what the compositor is doing on the protocol run `labwc` nested (i.e. start labwc from a terminal in another instance of labwc or some other compositor) with `WAYLAND_DEBUG=server`. This filters out anything from clients.
For wayland clients, you can get a live view of some useful info using [wlhax](https://git.sr.ht/~kennylevinsen/wlhax).
If you think you've got a damage issue, you can run labwc like this: `WLR_SCENE_DEBUG_DAMAGE=highlight labwc` to get a visual indication of damage regions.
For some types of bugs, it might be useful to find out which mesa driver (.so) you are using. This can be done with:
```
EGL_LOG_LEVEL=debug labwc 2>&1 | grep MESA-LOADER
```
You can also get some useful system info with [drm_info](https://github.com/ascent12/drm_info)
## Packaging
Some distributions carry labwc in their repositories or user repositories.