* Make sure to _exit() in all forked code paths that doesn't end in a
successful exec()
* Report errno to parent process on failure so that we can log it
The second point is implemented by a) manually double forking instead
of calling daemon(), and b) using a pipe in the inner fork to be able
to wait for the child process to either succeed in its exec() call, or
write errno to the pipe on failure.
This fixes hangs and crashes when e.g. the binary we're trying to
execute doesn't exist.
We do it differently from everybody else...
A traditional HiDPI implementation typically scales up
everything. I.e. if the user wants a 1px border, it's scaled up to
2px. The wayland server typically presents an output width/height that
has been scaled *down*.
This is all a bit backwards, but perhaps was the best choice to make
legacy applications at least work.
f00bar on the other hand, wants to give the user absolute
control. Thus, we don't scale up at all. If the user wants a 25px bar
height, that's what he gets.
This does mean however, that we need to scale *down* the surface size
since it's in logical pixels, not physical.
So we scale *down* the surface size (which then gets scaled back up by
the wayland server), and then render everything *on* that surface
without any scaling.
The main advantage is when targeting sway/wayland instead of i3/x11;
sway doesn't package ipc.h. There *is* an ipc.h in the sway sources,
but it doesn't define e.g the header format, and has different names
for the constants.
