The ‘river’ module depends on generated protocol sources. These are
normally provided, indirectly, by the Wayland bar backend. But when
building plugins as shared modules, the plugins no longer depend on
the bar, and thus ‘river’ fails to build.
Fix this by doing two things:
* **Remove** the ‘river’ protocol from the ‘generic’ Wayland protocols
* Explicitly add both the generic and the ‘river’ specific protocols
to the ‘river’ module.
This is done by update_size(). Setting it in xdg_output_handle_done()
causes update_size() to do an early exit, and thus we end up never
actually configuring the surface.
We also never instantiate a pixman image, which led to a hard crash at
startup when the user had configured a specific output to use.
This allows the backend to support multi-seat "properly", by checking
against the correct seat. Before this, when we used a single, global
xcursor value, a seat whose pointer needed to be updated would not be
updated.
Instead, roundtrip once all globals have been handled. This means all
listeners have been registered.
When we detect a specific monitor to map to, and it has a non-default
scale, update the cursor theme (since it depends on the scale).
We only care about the mouse. We now track per-seat cursor positions
and cursor themes.
Any enter/leave/motion/button event will call the bar on_mouse()
method using the coordinates from the "current" seat.
Since the bar framework doesn't deal with multi-seats at all, we
internally, in the backend, track the currently active seat. This is
the seat which we last saw any kind of events from.
This is used in e.g. set_cursor(), which is called from the bar.
wl_display_dispatch() calls poll(), which is unnecessary since we
already know the FD is readable.
Use the more lower level wl_display_read_events() +
wl_display_dispatch_pending().
These require wl_display_prepare_read() to have been called.
Instead of us selecting an output randomly (we used to select that
"last" output) when the user hasn't configured one, let the compositor
choose one for us.
This is trivial in the Wayland backend; just instantiate a pixman
pointing to the same mmapped memory as the wayland buffer.
In the XCB backend, we change the implementation slightly; instead of
rendering via a cairo XCB surface backend (to a server side pixmap),
which is then blitted to the window in commit(), we now render to a
client-side pixman pixmap, and blit it using xcb_put_image() in
commit().
All decoration, particle and module interfaces now takes a
pixman_image_t parameter, and all drawing is done using pixman APIs.
The wayland/xcb backends implement a new interface functions,
get_pixman_image(), that should return a pixman image instance that is
suitable for rendering.
In the wayland backend, the image uses the same backing data as the
cairo surface.
In the XCB backend, we create a new image each time, and then blit it
to the cairo surface at commit time.
