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.
We subscribe to Sway's 'input' events, and use these to expose input
devices' active XKB layout.
The module is configured by specifying a list of 'identifiers'; these
are the input devices (keyboards, typically), that we'll be
monitoring. All other input devices are ignored.
'content' is a template, and the module will instantiate a dynlist
with a 'content' for each *existing* input found in the 'identifiers'
list.
We also monitor for device 'added' and 'removed' events, and update
our internal list of existing inputs.
This means the user can configure a set of identifiers, and only those
that are actually present will be displayed. If a device that is
listed in the 'identifiers' list is added, it will be displayed. If it
is removed, it will no longer be displayed.
This is a configuration that is expected to validate, and to exercise
as much as possible of the code up until validation has
completed. That is, as much as possible of the configuration
validation code.
It currently instantiates all modules, but not yet all particles and
decorations.
