Always start listening for commit events in mapnotify. This allows to
avoid checking c->mon each commit and fixes the crash opening
applications who commit subsurfaces before mapping them
Fixes#102. The "ideal" behavior might be to ignore buttons other than
the one being used for the action, but this is super-simple and still
seems reasonable.
wlr_output_damage_add_whole() has no effect in mapnotifu_sub,
destroynotify_sub and caused crashes when closing applications which use
subsurfaces
Keep track of subsurfaces in a list so that it is possible to remove and
free them.
This prevents applications such as firefox from freezing when nothing
else is going on. Those applications use subsurfaces (for efficiency
reasons), which we were not keeping track of before.
Applications who use subsurfaces were working fine as long as other
applications were updating or the user was simply moving the mouse (and
thus damaging the whole screen anyway).
I'm not sure if listening to map and unmap events of subsurfaces is
necessary.
Most of this was inspired by sway.
Prior to damage tracking, we had to make sure wlr_output_commit was
called even if we weren't rendering anything new. If we didn't, then
nothing would render after attempting the first window resize. This is
no longer a problem (maybe because adding damage schedules another frame
callback?), so we can do some normal early-returns here.
The wlr-output-management protocol requires that either all of the
changes from an apply request be applied successfully, in which case a
"succeeded" event is sent, or all of the changes are reverted and a
"failed" event is sent. As written, this could partially commit
changes, then fail.
Test the changes first (even for an "apply" event), then commit or
rollback as appropriate.
Additionally, variables xcursor and xcursor_mgr are only used
when xwayland is defined, so I make the variables declaration
contingent on whether xwayland is being used
Replaces the outputOrder patch.
This avoids recalculating positions and allows to arrange monitors in
any order, not just from left to right.
The order in which monitors are defined in config.h still matters but
it's just the order in the list, not the actual position.
