This tool is similar to xtrace in usage in that it intercepts traffic to
the X server. The motivating feature for writing the tool is its ability
to inject prepared reply messages instead of the server’s reply. In
this particular case, we’ll inject a RRGetMonitors reply to test i3’s
RandR 1.5 code paths.
The added testcase is a noop for now, but with the code that’s lingering
in the randr15 branch, i3 does actually detect monitors as per the
injected reply:
2016-11-20 21:10:05 - randr.c:__randr_query_outputs:618 -
RandR 1.5 available, querying monitors
2016-11-20 21:10:05 - randr.c:__randr_query_outputs:628 -
1 RandR monitors found (timestamp 0)
2016-11-20 21:10:05 - randr.c:__randr_query_outputs:646 -
name DP3, x 0, y 0, width 3840 px, height 2160 px, width 520 mm,
height 290 mm, primary 1, automatic 1
This is preparation work for issue #1799
Commit 287a0b4 introduced a segfault when validating the i3 config
as the root_screen will not be set in this case, causing a null
pointer dereference.
fixes#2144
The suppression file makes valgrind output more readable by hiding
reports of memory leaks for GObject-related initialization functions in
Pango and Cairo.
This behavior can be avoided by passing dont_create_temp_dir => 1 to
launch_with_config (or activate_i3).
This commit fixes t/159-socketpaths.t being flaky on non-systemd computers.
Michael Stapelberg