In addition to the name of the monitor itself (which is still used as
the i3 output's primary name), register RandR output names associated
with the RandR monitor as alternative i3 output names.
Currently, only one name is ever added, and only the first name is
ever accessed; actually using the capability to store and access
multiple names comes in the following commits.
Currently simply returns output->name, but this will make it easier to
change how output names are stored in the following commits.
Also replace reading output->name with invocations of
output_primary_name. Code which writes output->name is unchanged. Done
using a mostly mechanical replacement of output->name to
output_primary_name(output).
- Promote the "How to build?" sub-section to a top-level
section ("Building i3")
- Convert the "Introduction" sub-section as the intro to the remaining
contents of the "Using git / sending patches" section
- Keep "Which branch to use?" as a level-3 sub-section, thus making it
a sub-section of what used to be the "Introduction" sub-section.
The test runs `xrandr setmonitor`, which will otherwise affect any test
scheduled after 533-randr15.t, causing flakyness in t/217-NET_CURRENT_DESKTOP.t
for example.
• The output currently contains a large number of false-positives and — AFAICT —
no actual issues.
• Upstream shows little interest in addressing the long-standing issues with the
TAILQ macros, so the false-positive situation probably won’t change soon:
https://bugs.llvm.org/show_bug.cgi?id=18222
Currently, we largely spend travis CPU cycles on this, for no additional value.
$config is never touched after being initially set up.
Not restarting i3 between each test case reduces the runtime of this test by an
order of magnitude.
For opaque text, SOURCE is not any different from OVER. However, when
drawing color glyphs (which consist of RGBA pixels instead of strokes)
SOURCE's handling of alpha is not what we want.
I stumbled across this because cairo 1.15.8 seems to clear the surface
before drawing color emoji if the operator is SOURCE, deleting every-
thing drawn before. Arguably, the area outside the glyph bounds should
not be touched, but even if this is a cairo bug the problem of alpha
within the glyph remains.
The code in handle_signal() wasn't clearing the struct sigaction before passing it to sigaction().
This meant that we would block a random set of signals while executing the default handler, or jump to the uninitialized __sa_sigaction__ (instead of sa_handler).
Initialize properly as we do in setup_signal_handler().
Vladimir Panteleev