Most of these don't use the parameter that changes at all, but some get
a nice simplification.
Signed-off-by: Derek Foreman <derek.foreman@collabora.com>
There are many times when we want to set a global position with a surface
offset added.
It's a fairly nasty operation, and most places in the code currently do
it naively, ignoring the painful existence of freeform window rotations
and other complex transforms that could be in play (but probably aren't)
Add a helper for this and convert existing usage.
Signed-off-by: Derek Foreman <derek.foreman@collabora.com>
Oops, this was always wrong but nothing actually checked it. Checks are
coming, so it needs to be fixed.
Signed-off-by: Derek Foreman <derek.foreman@collabora.com>
PIXMAN_a8r8g8b8 / PIXMAN_a8b8g8r8 only matches GL_BGRA_EXT / GL_BGRA on little-endian.
So to have a GL format, we should use DRM_FORMAT_ARGB8888 / DRM_FORMAT_ABGR8888.
Without GL_EXT_read_format_bgra, the read-back format is DRM_FORMAT_ABGR8888.
Then weston-screenshooter fails to create a wl_shm buffer with WL_SHM_FORMAT_ABGR8888,
unless it has been added with wl_display_add_shm_format.
Signed-off-by: Loïc Yhuel <loic.yhuel@softathome.com>
Allow passing NULL to monitor string in order to set the default
"unknown" strings. This allows a head to be initialized with the default
strings, meaning that it will no longer be mandatory for a backend to
call weston_head_set_monitor_strings(). In DRM-backend case this makes
future changes more convenient.
Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.com>
We never expected these strdups to fail, and things tend to assume these
fields are not NULL (except serial_number).
Use xstrdup to ensure that a catastrophic OOM is immediately obvious.
Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.com>
If serial is unknown, it's best to leave it as NULL. All usage sites
already deal with it possibly being NULL.
This makes DRM-backend consistent with all other backend that leave
serial as NULL, allowing to move the initialization of these fields into
core.
Pipewire and remoting plugins are modified just for consistency.
Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.com>
Round up the ms delay to make sure that the finish_frame_timer always
expires after the next frame_time. That way, finish_frame_handler()
never passes a timestamp in the future to weston_output_finish_frame().
Setting frame_time into the future risks hitting an assert in
weston_output_finish_frame(), when it is called from start_repaint_loop
within the frame interval.
Signed-off-by: Philipp Zabel <p.zabel@pengutronix.de>
Round up the ms delay to make sure that the finish_frame_timer always
expires after the next frame_time. That way, finish_frame_handler()
never passes a timestamp in the future to weston_output_finish_frame().
Setting frame_time into the future risks hitting an assert in
weston_output_finish_frame(), when it is called from start_repaint_loop
within the frame interval.
Use CLIP() to simplify limiting the ms delay to a reasonable range.
Signed-off-by: Philipp Zabel <p.zabel@pengutronix.de>
Round up the ms delay to make sure that the finish_frame_timer always
expires after the next frame_time. That way, finish_frame_handler()
never passes a timestamp in the future to weston_output_finish_frame().
Setting frame_time into the future risks hitting an assert in
weston_output_finish_frame(), when it is called from start_repaint_loop
within the frame interval.
Use CLIP() to simplify limiting the ms delay to a reasonable range.
Signed-off-by: Philipp Zabel <p.zabel@pengutronix.de>
If the compositor is disabling a weston_output,
weston_head_from_resource can return NULL, so the return code must be
checked where used.
Fixes#638
Signed-off-by: Joshua Watt <JPEWhacker@gmail.com>
When gl_renderer_attach is called, surface->buffer_ref.buffer points to the buffer.
So if the surface state needs to be created, we have :
gl_renderer_attach -> get_surface_state -> gl_renderer_create_surface -> gl_renderer_attach
Fixes: 895b1fdcb2 ("gl-renderer: Attach buffer during surface state creation if possible")
Signed-off-by: Loïc Yhuel <loic.yhuel@softathome.com>
For drivers not supporting importing them directly. We use the equivalent
values to NV12 but with 16bit. The lowest 6 or 4 bits for P010/P012 are
padding and set to zero, so we can use the same subformats like for P016
and share the shader with NV12.
Signed-off-by: Robert Mader <robert.mader@collabora.com>
They are the 10/12/16bit equivalents of NV12 and at least P010 is widely
supported for a while now, so let's support them.
Signed-off-by: Robert Mader <robert.mader@collabora.com>
Since drm-backend requires libgbm 21.1.1 or later, there is no need to
support the old libgbm which does not support modifiers or fd import.
Signed-off-by: Tomohito Esaki <etom@igel.co.jp>
Initialize no-op color manager in weston_compositor_backends_loaded()
if weston_compositor_load_color_manager() was never called.
This makes weston_compositor_load_backend() live up to its name and
prepares it to be called multiple times.
Signed-off-by: Philipp Zabel <p.zabel@pengutronix.de>
Move the presentation clock selection loop into
weston_compositor_set_presentation_clock() and refactor
weston_compositor_backends_loaded() to make it possible
to add more functionality.
Signed-off-by: Philipp Zabel <p.zabel@pengutronix.de>
We seem to be using at least mesa 21.1.1 since Weston 10, but we never
explicitly asked for it.
Fixes: #790
Signed-off-by: Marius Vlad <marius.vlad@collabora.com>
Since we use paint nodes to track damage, we have to be very careful to
make sure that we never have paint nodes that aren't actually being
displayed on their outputs.
Shells may move views to invisible layers (minimized_layer, inactive_layer)
and this currently leaves the paint node alive but not visible on its
output.
When this happens, the paint node's previous visible region is left
undamaged, and the paint node is removed from processing.
Let's delete paint nodes when their views change layers, thus creating
damage for their full visible region.
This may create excess damage if the paint node moves between two visible
layers, but this is probably far less harmful than leaving pieces of
invisible views on screen.
Signed-off-by: Derek Foreman <derek.foreman@collabora.com>
Commit 43b59786 errantly claimed that paint_node_damage_below() needed to
damage all planes because it's used when moving paint nodes between
planes.
This is wrong because the destination plane will receive damage correctly
from paint_node_update_late() when the node's visible region is added to
its damage.
Leave the rest of that commit's changes, but make it once again only
damage the plane the node is currently on.
The problem this caused is easily seen by turning on triangle fan debug
and moving the mouse. Extra damage is generated beneath the cursor plane.
Fixes 43b59786
Signed-off-by: Derek Foreman <derek.foreman@collabora.com>
Let backends declare the presentation clocks they can use with a
new bitfield weston_backend::supported_presentation_clocks and set
presentation clock after loading the backend in the compositor.
Make weston_compositor_set_presentation_clock() internal and replace
weston_compositor_set_presentation_clock_software() with an exported
weston_compositor_backends_loaded(), which is called by the compositor
after the backend is loaded.
In the future, this can be extended to determine the subset of clocks
supported by all backends.
Signed-off-by: Philipp Zabel <p.zabel@pengutronix.de>
The function find_focus_successor() is called when destroying a surface to find
a successor to the current focus. It, however, has the following issues:
- Its first parameter is the weston layer from which to search for a successor.
This is an unnecessary flexibility for our use, which only adds complexity to
the user of the function by having to make a call for each layer. We know
that we want to search for a successor first in the normal layer, and if that
fails, then in the inactive layer. So we change the signature of
find_focus_successor(), removing this first parameter.
- It includes logic to decide whether to do the search or not: if the destroyed
surface is different from the surface that currently has focus, and if their
outputs are the same, then abort and don't do the search. This returns NULL to
the calling function. The problem is that the function also returns NULL if
it does the search and finds no successor. The distinction for the failing
reason is lost, and the user of the function needs to add more logic to know
the reason for failure. To simplify, we take the logic out of
find_focus_successor() and inside the caller.
- It returns the successor view, although it receives surfaces and the client
has logic to retrieve the surface corresponding to the returned view. To
simplify and maintain symmetry, we change the signature so that the function
returns the surface corresponding to the successor view.
Fixes: #738
Signed-off-by: Sergio Gómez <sergio.g.delreal@gmail.com>
We don't need to manually schedule a repaint after we've updated our
views - which happens as a side effect of destroying the transform/etc
within the animation.
Signed-off-by: Daniel Stone <daniels@collabora.com>
Whenever a view is moved, we should schedule a repaint for the outputs
the view is on. This avoids users having to do it by hand every time
they change something. There is no change in determinism of behaviour
(e.g. 'I can reconfigure views as often as I like and it won't take
effect until I schedule a repaint' isn't true, because output repaints
might happen for reasons outside your control).
Signed-off-by: Daniel Stone <daniels@collabora.com>
This list walk is broken, the intent was to walk the tail of the list
starting from the currently held node - but that is not what happens.
Instead, walk the list backwards and stop a the held node.
Also, paint_node_damage_below() is used when moving paint nodes between
planes, and in these cases we definitely don't want to limit damage to
the current plane.
Signed-off-by: Derek Foreman <derek.foreman@collabora.com>
Currently this isn't calculated properly, and results in clipping away
important damage when a client moves from a non-primary plane to the
primary plane.
Instead of trying to fix it, let's just throw it away.
Signed-off-by: Derek Foreman <derek.foreman@collabora.com>
In other parts of the code, use_geometry implies a parent is present. So
let's clear it when we clear relative placement.
Signed-off-by: Derek Foreman <derek.foreman@collabora.com>
Having use_geometry set is not the only time we have a parent window,
apparently.
Clicking on the 'Line diff' drop down in gitk would cause an assert()
because of this.
Fixes#769
Signed-off-by: Derek Foreman <derek.foreman@collabora.com>
Until kernel mainline does merge the aysnc page flip ioctl, make the
whole bit look like it's unsupported. We can further switch it back when
it lands into the kernel.
Fixes: 9203d98f
Signed-off-by: Marius Vlad <marius.vlad@collabora.com>
Reported-by: Simon Ser <contact@emersion.fr>
Stop flushing surfaces that are put on an overlay plane on the output to
be repainted next, but that have to be painted into another output's
primary_plane.
Now that each output has its own primary_plane, and flush_damage() knows
the output that is going to be repainted, texture_used can be limited to
surfaces that will actually be used by the renderer during the following
repaint_output().
Always upload when called from gl_renderer_surface_copy_content() or
gl_renderer_create_surface() with the output parameter set to NULL.
Signed-off-by: Philipp Zabel <p.zabel@pengutronix.de>
When flush_damage() is called, the output to be repainted next is
already known. Pass it along into the renderer, which can make use
of this information:
The GL renderer can get a better idea which SHM surface textures
actually have to be updated, in case a surface can be put on a plane
on one output, but not another.
A future Vulkan renderer could record texture uploads into an output
specific command buffer.
Signed-off-by: Philipp Zabel <philipp.zabel@gmail.com>
Currently dbus support is built when launcher-logind option
is set; let's split that such that dbus is its own option
and launcher-logind depends on dbus.
Signed-off-by: Christopher Obbard <chris.obbard@collabora.com>
Currently the dbus helper stuff is internal only in libweston,
let's move it to being public so that custom shells may use
the helper code.
Signed-off-by: Christopher Obbard <chris.obbard@collabora.com>
Use the shared helper extracted from the RDP backend to avoid leaking
modes into the output mode list on every resize.
Signed-off-by: Philipp Zabel <p.zabel@pengutronix.de>
The ensure_single_mode() helper replaces an output's single mode.
Extract it into libweston so it can be reused by the VNC backend,
and rename it to weston_output_set_single_mode().
At the same time, set the the previously missing
WL_OUTPUT_MODE_CURRENT flag on the new mode.
Fixes#758
Signed-off-by: Philipp Zabel <p.zabel@pengutronix.de>
We can now have overlapping outputs, so we can remove the checks that
protected us against this previously.
We may want to consider adding checks for discontinuities in the future
though, so leave a brief comment where the checks used to be.
Signed-off-by: Derek Foreman <derek.foreman@collabora.com>
Now that planes are attached to paint nodes, we no have no reason to
prevent placing a view on a plane when it's on multiple monitors.
Signed-off-by: Derek Foreman <derek.foreman@collabora.com>
The primary_plane is currently shared amongst all outputs, and is the last
barrier to having overlapping outputs.
Split it up and make it per output instead.
Signed-off-by: Derek Foreman <derek.foreman@collabora.com>
The color-metadata-errors test inits outputs with a NULL compositor, and
makes a compositor that's entirely 0s except for the bits it's interested
in.
This makes a mess in a future where the primary_plane is split up per
output, as initializing the primary plane tries to add it to the
compositor's plane_list.
Signed-off-by: Derek Foreman <derek.foreman@collabora.com>
We don't need to do this, we can just leave them in the plane list until
they're used.
Also, doing so helps for when we want to move the primary_plane from
the compositor to the outputs in the future.
Signed-off-by: Derek Foreman <derek.foreman@collabora.com>
Remove plane->damage and instead accumulate damage on paint
nodes.
This is a step towards allowing multiple overlapping outputs.
Signed-off-by: Derek Foreman <derek.foreman@collabora.com>
Tracking the view's plane in the paint node in this way is a step towards
inflicting plane damage from paint node update during the output repaint,
instead of manually doing weston_view_damage_below().
We remove view->plane entirely and do all access through pnodes.
Signed-off-by: Derek Foreman <derek.foreman@collabora.com>
We used to do this through a byzantine path involving the view's plane
transitioning from NULL to primary - but that doesn't work very well
when we want to track the plane in the paint node, because the paint
node will never have a NULL plane state.
This can be removed later when we track damage on paint nodes.
Signed-off-by: Derek Foreman <derek.foreman@collabora.com>
Now that we have visibility for views, we can clip that to an output
and store it in paint nodes.
This requires us to split the paint_node_update() function into two,
one for things that need to be done before assign_planes() and
one for after.
This will eventually be useful for tracking damage with paint nodes,
as we'll need to damage a paint node's entire visible area for
some operations.
Signed-off-by: Derek Foreman <derek.foreman@collabora.com>
Pretty cosmetic right now, but make the ALL_DIRTY only contain set
bits, and fix the accidentally sparse bitfield.
Signed-off-by: Derek Foreman <derek.foreman@collabora.com>
This is kind of confusing, as the visibility calculation is just a side
effect of the damage accumulation.
At the expense of walking the paint node list another time, make this
a separate function.
Signed-off-by: Derek Foreman <derek.foreman@collabora.com>
Later, we'll want to use the visible region for damage tracking in
paint_nodes. For now, we can use it in the renderers where they've been
calculating it independently to draw paint nodes.
We still can't remove view->clip entirely, because
weston_view_damage_below() may be called before the first render of
a view, when its visible region hasn't been calculated yet. The
clip is empty at that point, which allows weston_view_damage_below()
to "work".
Signed-off-by: Derek Foreman <derek.foreman@collabora.com>
This is when they need to be up to date. And it makes it so that
view_ensure_paint_node() only does what the function name indicates.
Also, later when we tie damage tracking to paint nodes it will make
more sense to update them just in time for the output being repainted.
Signed-off-by: Derek Foreman <derek.foreman@collabora.com>
In the future we'd like to have multiple overlapping outputs.
weston_output_damage() currently adds damage to the output's coordinates
on the primary plane. This plane is shared between all outputs, so it
would result in damaging more than the intended output.
Eventually, plane damage will go away and be replaced by paint node damage,
and damaging the entire output would involve adding damage to a list of
paint nodes.
Instead, use a flag to indicate the output must be fully redrawn, and add
the damage during the repaint loop.
Signed-off-by: Derek Foreman <derek.foreman@collabora.com>
Right now every backend clears output damage from the primary plane when
it repaints. Instead of having this same operation spread across all
the backends, just do it in the core instead.
In the future, we want to remove damage tracking from the primary plane
entirely, and this is a small step in that direction.
Signed-off-by: Derek Foreman <derek.foreman@collabora.com>
We've just made this impossible, so we can now clean up all the TODO
locations.
I've only turned some of them into assert()s, because they're all mostly
in the same place.
Signed-off-by: Derek Foreman <derek.foreman@collabora.com>
In the future when we track damage with paint nodes we have a problem when
a paint node is moved off of its output - it immediately stops being
present, so we don't generate damage for the move that placed it off
screen.
We don't want paint nodes to exist when their view isn't on their output
anyway, so let's cull these nodes at the point where we assign outputs to
views.
In the damage-from-paint-nodes future, this will let us properly post
damage when the paint node is destroyed.
Signed-off-by: Derek Foreman <derek.foreman@collabora.com>
Paint nodes should only exist when they're visible.
In the future where we want to track damage with paint nodes we need
this to be enforced, or damage won't properly be tracked when a
paint node is hidden from us but continues to exist.
Signed-off-by: Derek Foreman <derek.foreman@collabora.com>
We want an output's z_order_list to only contain paint nodes for that
output, but until now we've been pretty careless about this.
Signed-off-by: Derek Foreman <derek.foreman@collabora.com>
Notify the shell of the state transition when going from fullscreen to
normal toplevel window.
Signed-off-by: Alexandros Frantzis <alexandros.frantzis@collabora.com>
The fullscreen state for xwayland surfaces can currently only be
effectively set from the client side. This commit enables
libweston-desktop based shells to properly set the fullscreen state
for xwayland surfaces.
Signed-off-by: Alexandros Frantzis <alexandros.frantzis@collabora.com>
Now that we deterministically create views for subsurfaces, we don't
need to stash them away into unused_views to dynamically create and free
them at repaint time.
Signed-off-by: Daniel Stone <daniels@collabora.com>
Now we create subsurface views both when linking to the parent
subsurface, and when creating new views for the parent surface, we no
longer need to magically materialise new views when building the view
list.
Signed-off-by: Daniel Stone <daniels@collabora.com>
When we're linking a subsurface to its parent for the first time,
materialise new views for every view the parent has.
Signed-off-by: Daniel Stone <daniels@collabora.com>
When we're destroying a parent view, also destroy any of its children
which are subsurface views that we've created automatically in the core.
Signed-off-by: Daniel Stone <daniels@collabora.com>
If a view is in the view list when it's being destroyed, we need to
rebuild the view list. However, doing so is currently very hairy as
views are created and destroyed at will ... including when rebuilding
the view list.
In preparation for creating and destroying subsurface views at the time
of the action rather than later at repaint time, pull out the immediate
view-list rebuild and simply mark the view list as needing a full
rebuild.
Signed-off-by: Daniel Stone <daniels@collabora.com>
Most of the time when we're changing things about views, we don't need
to throw away the view list and rebuild it from scratch. The only times
when we need to do this are when views have been added to or removed
from the scene graph, or have been restacked within it.
Signed-off-by: Daniel Stone <daniels@collabora.com>
weston_view_geometry_dirty_internal() can be used by internal callers to
mark a view's internal geometry as dirty, without signaling the need for
a full rebuild of the view list.
This is a transitional step towards eliminating
weston_view_geometry_dirty() from public API. Up until recently, the
view-manipulation API has been that users should manually manipulate
lists of transforms, layers, and other internal members, then call
weston_view_geometry_dirty() as well as manually provoking damage.
Now that we have helper functions to handle view manipulation, they
still need to mark the view geometry as being dirty. However, most of
them do not need to invoke a full rebuild of the view_list, which is
only required when views are added or removed from the scene graph, or
restacked.
weston_view_geometry_dirty() will assume that everything has changed
before eventually being ushered out of existence.
Signed-off-by: Daniel Stone <daniels@collabora.com>
There's no need to go through and rebuild the subsurface list every
time. In addition to being unnecessary work, it complicates things like
damage tracking.
Track a new surface dirty status indicating that the subsurface tree has
changed in some way, and only rebuild subsurface stacking when this has
occurred.
Signed-off-by: Daniel Stone <daniels@collabora.com>
When we're committing anything, return the collected status of what
we've just made live, including any changes resulting from subsurfaces
having changed.
Signed-off-by: Daniel Stone <daniels@collabora.com>
weston_view_geometry_dirty() marks the passed-in view as dirty, as well
as all of its children.
weston_view_update_transform() updates the geometry of its ancestors,
then itself.
Users are required (for now) to call weston_view_update_transform() in
order to not experience a disappointing amount of death-by-assert.
Users do not have a pointer to child views which are magically
materialised by the subsurface code.
The end result is disappointing. But it is less disappointing if
updating the transform for a view the user is actually aware exists,
also updates the transform for all its children.
Signed-off-by: Daniel Stone <daniels@collabora.com>
When the destroy signal is fired, child views will disassociate
themselves from the parent. This means that we can no longer see what
the child views are - and that recursive unmapping does not work.
Make sure that views are fully unmapped before anything else happens in
destroy, so we can recursively unmap child views.
Signed-off-by: Daniel Stone <daniels@collabora.com>
Per the wl_subsurface spec:
A sub-surface becomes mapped, when a non-NULL wl_buffer is applied
and the parent surface is mapped. The order of which one happens
first is irrelevant. A sub-surface is hidden if the parent becomes
hidden, or if a NULL wl_buffer is applied. These rules apply
recursively through the tree of surfaces.
[...]
If the parent wl_surface object is destroyed, the sub-surface is
unmapped.
The terminology is kind of loose. My reading of this is that we should
'unmap' (hide from display, remove from input/focus consideration, etc)
a subsurface immediately when a parent is destroyed.
However, if the child surface is then paired with another parent which
is itself mapped, then the child surface should immediately be mapped,
because it has a non-NULL buffer already applied, and the parent surface
is mapped.
By marking the surface as 'unmapped' on parent destroy, we were removing
it from the scene graph, but also I think breaking the rules on mapping
by requiring another commit when it was reassociated with another,
already mapped, surface.
Removing the explicit surface unmap leaves the surface in the 'mapped'
state, but without any views, which I believe has the intended effect.
Signed-off-by: Daniel Stone <daniels@collabora.com>
Quoth the spec:
A sub-surface becomes mapped, when a non-NULL wl_buffer is applied
and the parent surface is mapped. The order of which one happens
first is irrelevant. A sub-surface is hidden if the parent becomes
hidden, or if a NULL wl_buffer is applied. These rules apply
recursively through the tree of surfaces.
We currently apply this rule through reconstructing the view_list at
repaint time, materialising new views and garbage-collecting unwanted
views as appropriate. Since this can be a costly operation, it's best if
we move this closer to the source.
This makes the core recursively unmap any child views when the parent is
unmapped. Future commits will do the same for mapping new views.
Signed-off-by: Daniel Stone <daniels@collabora.com>
View transform parents can be set by anyone. parent_view, on the other
hand, is only set for subsurfaces.
Signed-off-by: Daniel Stone <daniels@collabora.com>
This is heading towards being able to materialise subsurface views
closer to the source. weston_view_create() - being used only by
window-management code - will ultimately create all required subsurface
views as well. The internal variant will be used by this and also by the
subsurface code as required.
Signed-off-by: Daniel Stone <daniels@collabora.com>
This indicates that more than just the content changing, the form of the
buffer has changed in a way which may not be like-for-like to the
previous buffer but require significant reinterpretation. Examples
include the format, opacity, colour state, etc.
Signed-off-by: Daniel Stone <daniels@collabora.com>
Both wl_surface.damage and wl_surface.damage_buffer explicitly refer to
the 'pending buffer'. wl_surface.attach states that there is no pending
buffer after the commit is processed, so it follows that a commit which
includes damage but no attach will not process any damage.
Change surface-commit processing to ignore all damage unless a buffer
was attached in the same commit cycle.
(Thanks to @pH5 for his spec analysis which I've just paraphrased here.)
Signed-off-by: Daniel Stone <daniels@collabora.com>
Instead of having a bool for whether or not a buffer has been attached
in this commit cycle, use a status bitmask.
Signed-off-by: Daniel Stone <daniels@collabora.com>
The only time we need to go through recalculating the surface size is
when either the buffer dimensions or the surface transforms have
changed. Now that we have dirty flags, use them to avoid a calculation
where required.
Signed-off-by: Daniel Stone <daniels@collabora.com>
Instead of passing an output to weston_compositor_build_view_list(),
have it set up all the output z_order_lists at once.
This is a preamble for MR !1285 which wants to maintain a compositor
wide dirty bit for the view list.
Signed-off-by: Derek Foreman <derek.foreman@collabora.com>
Moves the output specific stuff into one place, after the view_list is
already properly set up.
Signed-off-by: Derek Foreman <derek.foreman@collabora.com>
A video mode change would be needed to change the underlying renderer
framebuffer. All other backends make uses of this so let's do it for the
DRM-backend as well.
This would also be needed for the output capture to function properly as
we need call weston_output_update_capture_info() when a new mode set has
set. Otherwise we'd run into mismatched dimensions for the current mode
versus the dimensions set-up initially in weston_output_capture_source_info.
Signed-off-by: marius vlad <marius.vlad@collabora.com>
Turn the Pixman/GL if/else conditionals into switch cases to make it
easier to add support for other renderers in the future.
Also makes sure that weston --backend=wayland --renderer=noop fails
with an error message instead of segfaulting.
Signed-off-by: Philipp Zabel <philipp.zabel@gmail.com>
Turn the Pixman/GL if/else conditionals into switch cases to make it
easier to add support for others renderer in the future.
Also makes sure that weston --backend=x11 --renderer=noop fails
with an error message instead of starting with the GL renderer.
Signed-off-by: Philipp Zabel <p.zabel@pengutronix.de>
Derek Foreman