Helps people avoid wayland-egl if they don't want it.
Makes the check for wayland-egl explicit on the site instead of relying
on gl-renderer checking for it.
Signed-off-by: Pekka Paalanen <pq@iki.fi>
Helps people to avoid EGL and GLESv2 if they do not want them.
Stops using dep_egl and dep_glesv2 so that the human friendly error
message is alongside the dependency() statement, so that the message and
the statement can later be merged together once Meson offers the custom
error messages feature or something even more sophisticated.
Signed-off-by: Pekka Paalanen <pq@iki.fi>
Make fbdev work with some Android downstream kernels, like the
asus-grouper (Google Nexus 7 2012).
Signed-off-by: Oliver Smith <ollieparanoid@bitmessage.ch>
The 'done' event sent back to client with the weston screenshot interface
is not being sent if there is no damage on the plane. This patch (re-uses just
like recording part) weston_output_damage() to achieve that.
Otherwise the client will have to wait (and be blocked) until some
damage on the plane is being done.
Signed-off-by: Marius Vlad <marius.vlad0@gmail.com>
This fixes the situation when using only plane-state mode for
compositing there's no obvious debug message stating that. This patch
makes it slightly better/easier to dermine what mode the compositor is
using currently.
Signed-off-by: Marius Vlad <marius.vlad0@gmail.com>
This fixes warnings like ``may be used uninitialized''
libweston/compositor-drm.c: In function 'drm_device_is_kms':
libweston/compositor-drm.c:6374:12: warning: 'id' may be used uninitialized in this function [-Wmaybe-uninitialized]
b->drm.id = id;
Signed-off-by: Marius Vlad <marius.vlad0@gmail.com>
Meson is a build system, currently implemented in Python, with multiple
output backends, including Ninja and Make. The build file syntax is
clean and easy to read unlike autotools. In practise, configuring and
building with Meson and Ninja has been observed to be much faster than
with autotools. Also cross-building support is excellent.
More information at http://mesonbuild.com
Since moving to Meson requires some changes from users in any case, we
took this opportunity to revamp build options. Most of the build options
still exist, some have changed names or more, and a few have been
dropped. The option to choose the Cairo flavour is not implemented since
for the longest time the Cairo image backend has been the only
recommended one.
This Meson build should be fully functional and it installs everything
an all-enabled autotools build does. Installed pkg-config files have
some minor differences that should be insignificant. Building of some
developer documentation that was never installed with autotools is
missing.
It is expected that the autotools build system will be removed soon
after the next Weston release.
Signed-off-by: Daniel Stone <daniels@collabora.com>
Co-authored-by: Pekka Paalanen <pq@iki.fi>
Signed-off-by: Pekka Paalanen <pq@iki.fi>
In current form SHM buffers pixel format can only be printed as 0 and 1.
With the help of this helper we align with DRM_FORMAT_ pixel format.
Signed-off-by: Marius Vlad <marius.vlad0@gmail.com>
Use the pixel format table to parse format names. This makes the parser
recognize almost all DRM format names.
Not all formats are usable, but we rely on the use to fail
appropriately. What we can use depends on the drivers anyway.
Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.co.uk>
Add a function to find a format description by the DRM format name. This
will be useful when parsing configuration strings.
While at it, fix the two function formattings in pixel-formats.h to
match everything else in the file.
Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.co.uk>
There is often a need to print the name of a pixel format. Printing the
raw numeric value is hard to decipher, printing the four ASCII
characters is slightly more human-friendly but still needs a decoder
table. Add a name that can be printed easily.
The bulk of this patch was done with:
sed -i -e 's/\.format = DRM_FORMAT_\(.\+\),/DRM_FORMAT(\1),/' libweston/pixel-formats.c
Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.co.uk>
Introduce a helper function to disconnect the client on unhandled
buffer types, and use it in the gl and pixman renderers. The function
is modeled after linux_dmabuf_buffer_send_server_error.
Also print the egl error state in the gl renderer, in case the
unrecognized buffer error happens when querying an egl buffer.
https://gitlab.freedesktop.org/wayland/weston/issues/148
Add support virtual output for streaming image to remote output by
remoting-plugin which will be added by the patch:
"Add remoting plugin for output streaming."
The gbm bo of virtual output is the linear format.
Virtual output is implemented based on a patch by Grigory Kletsko
<grigory.kletsko@cogentembedded.com>.
Signed-off-by: Tomohito Esaki <etom@igel.co.jp>
Store usage flags of gbm bo in drm_output in order to specify the bo
format for each output. A following patch will add a new type of
drm_output which requires different gbm_bo_flags.
Signed-off-by: Tomohito Esaki <etom@igel.co.jp>
Add new API to gl-renderer interface for providing fence sync fd. the
backend can wait for GPU rendering by this API.
Signed-off-by: Tomohito Esaki <etom@igel.co.jp>
In the case where CreateContext/MakeCurrent fails, we still want to
know what the EGL driver is capable of.
Move the EGL info printing, just after the eglInitialize() call to
ensure that.
Signed-off-by: Emil Velikov <emil.velikov@collabora.com>
Split the two into separate functions. Former requires an initialized
EGL display, while the latter a current context.
We will use that distinction with the next patch.
Signed-off-by: Emil Velikov <emil.velikov@collabora.com>
Not every output will have a backlight control, and even if it does we
may just not be able to find it. Not having backlight control isn't an
error, so don't spam the log with it, as doing so can confuse users into
thinking this is an actual error which is responsible for their real
problems.
Signed-off-by: Daniel Stone <daniels@collabora.com>
Not having swap_buffers_with_damage could cause a performance impact on
some backends, but at least on GBM it causes no issues. It also seems to
confuse users into thinking it's a legitimate error which could explain
session slowness.
Similarly with buffer_age, whilst we do lose a little bit of performance
by not being able to do partial renders, it is not a great deal, and the
user is unlikely to be able to do anything about it in any event.
Remove the warning; we print the full extension list at startup, so we
already have enough information from the logs to easily diagnose any
real errors.
Signed-off-by: Daniel Stone <daniels@collabora.com>
Use the DRM connector "non-desktop" property to mark weston_heads that
represent head mounted displays and other non-standard displays that the
desktop should not be extended to.
Signed-off-by: Philipp Zabel <philipp.zabel@gmail.com>
Add non-desktop property for weston_heads representing displays that the
desktop should not be extended to by default, e.g. head mounted displays.
Signed-off-by: Philipp Zabel <philipp.zabel@gmail.com>
Implement drm_view_is_opaque() using weston_view_is_opaque(). Also, use
weston_view_is_opaque() directly in drm_output_propose_state(), with the
clipped_view.
Signed-off-by: Philipp Zabel <philipp.zabel@gmail.com>
Use the weston_surface is_opaque property, the opaque region, and the view
alpha value to determine whether the weston_view is opaque in a specific
region.
Signed-off-by: Philipp Zabel <philipp.zabel@gmail.com>
Add an is_opaque property that is set to true if the attached buffer does not
have an alpha component, or if the solid color is non-transparent.
Signed-off-by: Philipp Zabel <philipp.zabel@gmail.com>
Add a 'drm-debug' scope which prints verbose information about the DRM
backend's repaint cycle, including the decision tree on how views are
assigned (or not) to planes.
Signed-off-by: Daniel Stone <daniels@collabora.com>
Shift up our calculation of the flags we use for atomic commits. We will
later use this to differentiate between test-only and full commits when
printing debug information inside drm_output_state_apply_atomic.
Signed-off-by: Daniel Stone <daniels@collabora.com>
Reviewed-by: Pekka Paalanen <pekka.paalanen@collabora.co.uk>
Add a 'scene-graph' debug scope which will dump out the current set of
outputs, layers, and views and as much information as possible about how
they are rendered and composited.
Signed-off-by: Daniel Stone <daniels@collabora.com>
As a counterpart to weston_layer_set_mask_infinite(), returning if the
mask is the same as what is set.
Signed-off-by: Daniel Stone <daniels@collabora.com>
Reviewed-by: Pekka Paalanen <pekka.paalanen@collabora.co.uk>
weston_debug is both a libweston API for relaying debugging messages,
and the compositor-debug wayland protocol implementation for accessing those
debug messages from a Wayland client.
weston_debug_compositor_{create,destroy}() are private API, hence not
exported.
Signed-off-by: Pekka Paalanen <pq@iki.fi>
append the debug scope name along with the timestamp in
weston_debug_scope_timestamp API
Signed-off-by: Maniraj Devadoss <Maniraj.Devadoss@in.bosch.com>
Reviewed-by: Pekka Paalanen <pekka.paalanen@collabora.co.uk>
Add explicit advertisement of debug scope names.
Signed-off-by: Daniel Stone <daniels@collabora.com>
Reviewed-by: Emre Ucan <eucan@de.adit-jv.com>
This is a new debugging extension for non-production environments. The
aim is to replace all build-time choosable debug prints in the
compositor with runtime subscribable debug streams.
Signed-off-by: Pekka Paalanen <pq@iki.fi>
Added new libweston-$MAJOR-protocols.pc file and install that
for external projects to find the XML files installed by libweston.
Signed-off-by: Maniraj Devadoss <Maniraj.Devadoss@in.bosch.com>
Use noarch_pkgconfig_DATA instead, add ${pc_sysrootdir}, drop
unnecessary EXTRA_DIST of weston-debug.xml.
Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.co.uk>
Add explicit advertisement of available debug interfaces.
Signed-off-by: Daniel Stone <daniels@collabora.com>
Reviewed-by: Emre Ucan <eucan@de.adit-jv.com>
Linux v4.7 introduced a new connector type for display parallel
interface (DPI). Add DPI to the list of connectors in the DRM
backend of Weston as well. This avoid DPI connectors showing up
as UNNAMED.
Signed-off-by: Stefan Agner <stefan@agner.ch>
Client may map any file descriptor opened for writing with PROT_WRITE
themselves. On linux, even a read-only file descriptor to an unlinked
file can be re-opened with write permission through /proc/self/fd.
The only way to prevent this is to create a memfd which
is subsequently write-sealed. Unfortunately this prevents clients
from mapping with MAP_SHARED, which is already in widespread usage.
To isolate and protect the keymap, whilst allowing MAP_SHARED clients
to continue to work, use a unique file descriptor for each
wl_keyboard resource.
Reviewed-by: Daniel Stone <daniels@collabora.com>
We've always had "send_keymap" internally, but some places failed to use
it. Since we also use this in the text backend, export it.
Reviewed-by: Daniel Stone <daniels@collabora.com>
THe KMS AddFB call can fail for any reason at all: format/modifier not
suitable, stride not aligned, allocation not contiguous, etc. If this
happens with Weston's own buffers, the result is bad - no composition
output.
Failing AddFB from user-supplied buffers though, is not an error. The
user can't necessarily allocate suitable buffers, nor does it have to.
Don't spam the log with warnings when we fail on user buffers.
Signed-off-by: Daniel Stone <daniels@collabora.com>
Reported-by: Pekka Paalanen <pekka.paalanen@collabora.co.uk>
Reviewed-by: Derek Foreman <derek.foreman.samsung@gmail.com>
In the RENDERER_ONLY state proposal mode, we don't actually have a
viable configuration to test, because we won't get a renderer buffer
until after assign_planes - where we're called from - has completed.
This can result in us trying to test a configuration with the CRTC and
connectors active, but no planes active, which the kernel can
legitimately fail.
If we're working in renderer-only mode, just return the state we have
without trying to test it first, and let the kernel fill it in later.
Signed-off-by: Daniel Stone <daniels@collabora.com>
Acked-by: Derek Foreman <derek.foreman.samsung@gmail.com>
The backend begins with a series of #defines of libdrm tokens, in case
the libdrm we build against is too old.
Commit efdebbc4e8 ("configure.ac: bump libdrm requirement to 2.4.68")
did what it said on the box; since we now depend on a relatively modern
libdrm, we can get rid of most of our compatibility defines.
DRM_CAP_TIMESTAMP_MONOTONIC was added in libdrm 2.4.47 (f8f1f6e37ae2).
DRM_CLIENT_CAP_UNIVERSAL_PLANES was added in libdrm 2.4.55
(8fc62ca8ac01).
DRM_CAP_CURSOR_WIDTH and HEIGHT were added in libdrm 2.4.68
(cc9a53f076d4).
Remove these four fallback definitions.
Signed-off-by: Daniel Stone <daniels@collabora.com>
Reviewed-by: Derek Foreman <derek.foreman.samsung@gmail.com>
Now that we can sensibly test proposed plane configurations with atomic,
sprites are not broken.
Signed-off-by: Daniel Stone <daniels@collabora.com>
Reviewed-by: Pekka Paalanen <pekka.paalanen@collabora.co.uk>
Since we now incrementally test atomic state as we build it, we can
loosen restrictions on what we can do with planes, and let the kernel
tell us whether or not it's OK.
Signed-off-by: Daniel Stone <daniels@collabora.com>
Reviewed-by: Pekka Paalanen <pekka.paalanen@collabora.co.uk>
a0f8276fe8 ("compositor-drm: Disallow overlapping overlay planes") was
a little too pessimistic in rejecting occluded views. Whilst it
correctly prevented overlay planes from occluding each other, it also
prevented overlay planes from occluding the scanout plane.
This is undesirable: the primary/scanout plane is specified to stack
strictly below all overlay planes, so there is no need to reject a plane
from consideration for scanout due to being occluded by an overlay
plane.
Shift the check downwards so it only applies to overlay rather than
scanout planes.
Signed-off-by: Daniel Stone <daniels@collabora.com>
Reviewed-by: Pekka Paalanen <pekka.paalanen@collabora.co.uk>
In the plane-only mode, we try to place every view on a hardware plane,
and fail if we can't do this. This requires a full walk of the scene
graph to come up with a complete configuration in order to be able to
test.
In mixed mode, we know at least some visible views will fail to be
promoted to planes and must be composited via the renderer. In order to
still use some planes where possible, we use atomic modesetting's
test-only mode to incrementally test configurations.
We know that the renderer output will always be visible, and because it
is the renderer, that it will be occupying the scanout plane underneath
everything else. The actual renderer buffer doesn't materialise until
after assign_planes, because it cannot know what to render until then.
However, in order to test whether a configuration is valid, we need the
renderer buffer in the scanout plane. For testing, we fake this by
temporarily stealing the old buffer - if it seems sufficiently
compatible - and placing it in the state we construct. This is used to
test whether or not a renderer buffer will work with the addition of
overlay planes.
Doing this incremental testing will allow us to enable plane usage for
atomic by default, since we know ahead of time that our chosen plane
configuration will work.
Signed-off-by: Daniel Stone <daniels@collabora.com>
Reviewed-by: Pekka Paalanen <pekka.paalanen@collabora.co.uk>
Add a new mode, which attempts to construct a scene exclusively using
planes. This is a building block for incrementally testing and
constructing state: in the plane-only mode, we test the state exactly
once, when we have constructed a full set of planes and want to know if
it works or not.
When using the renderer, we need to incrementally test views one by one
to see if they will work on planes, falling back to the renderer if not.
This test is different, since the scanout plane will be occupied by the
renderer's buffer. Testing using the renderer or client buffers may have
completely different characteristics, so we need two passes: first,
constructing a state with only planes and testing if that succeeds,
falling back later to a mixed renderer/plane mode which tests
incrementally.
This implements the first mode, and preferentially attempts to use it.
Signed-off-by: Daniel Stone <daniels@collabora.com>
Reviewed-by: Pekka Paalanen <pekka.paalanen@collabora.co.uk>
This will never work, so don't even try to do it.
Signed-off-by: Daniel Stone <daniels@collabora.com>
Reviewed-by: Pekka Paalanen <pekka.paalanen@collabora.co.uk>
The atomic API can allow us to test state before we apply it, to see if
it will be valid. Use this when we construct a plane configuration, to
see if it has a chance of ever working. If not, we can fail
assign_planes early.
This will be used in later patches to incrementally build state by
proposing and testing potential configurations one at a time.
Signed-off-by: Daniel Stone <daniels@collabora.com>
Reviewed-by: Pekka Paalanen <pekka.paalanen@collabora.co.uk>
Return a pointer to the plane state, rather than returning its
underlying weston_plane. This eliminates any ambiguity between placing
client buffers on planes, and placing them through the renderer.
drm_output_propose_state is only concerned with preparing, testing, and
returning DRM state objects. Assigning views to weston_planes only
happens later, inside drm_assign_planes. This makes that split more
clear.
Signed-off-by: Daniel Stone <daniels@collabora.com>
Reviewed-by: Pekka Paalanen <pekka.paalanen@collabora.co.uk>
Add support for multiple modes to drm_output_propose_state. Currently we
intend to operate in three modes: planes-only (no renderer buffer,
client buffers in planes only), mixed-mode (promote client buffers to
planes where possible, falling back to the renderer where not), and
renderer-only (no plane usage at all).
We want to use the first (planes-only) mode where possible: it can avoid
us having to allocate buffers for the renderer, and it also gives us the
best chance of the optimal configuration, with no composition. In this
mode, we walk the scene looking at all views, trying to put them in
planes, and failing as soon as we find a view we cannot place in a
plane.
In the second mode, rather than failing, we assign those views which
cannot be on a plane to the renderer, and allow the renderer to
composite them.
In the third mode, planes are not usable, so everything but the cursor
goes to the renderer. We will use this when we cannot use the planes-only
mode (because some views cannot be placed in planes), but also cannot
use the 'mixed' mode because we have no renderer buffer yet. Since we
walk the scene graph from top to bottom, using atomic modesetting we
will determine if planes can be promoted in mixed mode by placing a
renderer buffer at the bottom of the scene, placing a cursor buffer if
applicable, then testing if we can add overlay planes to this mode.
Without a buffer from the renderer, we cannot do these tests, so we push
everything through the renderer and then switch to mixed mode on the
next repaint.
This patch implements the mixed and renderer-only modes (previously
differentiated only by the sprites_are_broken flag), with the
planes-only mode being left for a later patch.
Signed-off-by: Daniel Stone <daniels@collabora.com>
Reviewed-by: Pekka Paalanen <pekka.paalanen@collabora.co.uk>
When the sprites_are_broken variable is set, do not attempt to promote
client surfaces to the scanout plane.
We are currently assuming that every client buffer will be compatible
with the scanout plane, but that is not the case, particularly with more
exotic tiled/compressed buffers. Once we promote the client buffer to
scanout, there is no going back: if the repaint fails, we do not mark
this as failed and go back to repaint through composition.
This permanently removes the ability for scanout bypass when using the
non-atomic path. Future patches lift the restriction when using atomic
modesetting, as we can actually test and ensure that the view is
compatible with scanout.
Signed-off-by: Daniel Stone <daniels@collabora.com>
Reviewed-by: Pekka Paalanen <pekka.paalanen@collabora.co.uk>
Reported-by: Pekka Paalanen <pekka.paalanen@collabora.co.uk>
The scanout plane strictly stacks under all overlay planes, and the
cursor plane above. However, the stacking of overlay planes with respect
to each other is undefined.
We can control the stacking order of overlay planes with the zpos
property, though this significantly complicates plane assignment. In the
meantime, simply disallow assigning a view to an overlay, when it
overlaps another view which is already on an overlay. This ensures
stacking order is irrelevant, since the planes never intersect each
other.
Signed-off-by: Daniel Stone <daniels@collabora.com>
Reviewed-by: Pekka Paalanen <pekka.paalanen@collabora.co.uk>
Since the repaint status of the flushed output may be reset if a output
repaint is failed, it is necessary to clear the repainted flag
immediately after output repaint flush/cancel.
Signed-off-by: Tomohito Esaki <etom@igel.co.jp>
Reviewed-by: Pekka Paalanen <pekka.paalanen@collabora.co.uk>
When trying to assign planes, keep track of the areas which are
already occluded, and ignore views which are completely occluded. This
allows us to build a state using planes only, when there are occluded
views which cannot go into a plane behind views which can.
Signed-off-by: Daniel Stone <daniels@collabora.com>
Reviewed-by: Pekka Paalanen <pekka.paalanen@collabora.co.uk>
Tested-by: Emre Ucan <eucan@de.adit-jv.com>
When we come to assign_planes, try very hard to ignore views which are
only visible on other outputs, rather than forcibly moving them to the
primary plane, which causes damage all round and unnecessary repaints.
Signed-off-by: Daniel Stone <daniels@collabora.com>
Reviewed-by: Pekka Paalanen <pekka.paalanen@collabora.co.uk>
Tested-by: Emre Ucan <eucan@de.adit-jv.com>
Move drm_assign_planes into two functions: one which proposes a plane
configuration, and another which applies that state to the Weston
internal structures. This will be used to try multiple configurations
and see which is supported.
Signed-off-by: Daniel Stone <daniels@collabora.com>
Reviewed-by: Pekka Paalanen <pekka.paalanen@collabora.co.uk>
Tested-by: Emre Ucan <eucan@de.adit-jv.com>
Now that we collect information about which modifiers are supported for
KMS display, and are able to create KMS framebuffers with modifiers,
begin using the modifier-aware GBM API.
Client buffers from dmabuf already store multi-plane and modifier
information into drm_fb. Extend this to drm_fb_get_from_bo(), used for
wl_buffer, cursor, and gbm_surface buffers. wl_buffer buffers should by
convention not require modifiers. Cursor buffers must not require
modifiers, as they should be linear. Prior to this patch, GBM buffers
must have been single-planar, and able to used without explicitly naming
modifiers.
Using gbm_surface_create_with_modifiers allows us to pass the list of
modifiers acceptable to KMS for scanout to GBM, so it can allocate
multi-planar buffers or those which are otherwise only addressible with
modifiers. On platforms supporting and preferring modifiers for scanout,
this means that the gbm_bos we get from our scanout surface need to use
the extended API to query multiple planes, offsets, modifiers, etc.
Signed-off-by: Daniel Stone <daniels@collabora.com>
Reviewed-by: Pekka Paalanen <pekka.paalanen@collabora.co.uk>
Tested-by: Emre Ucan <eucan@de.adit-jv.com>
The per-plane IN_FORMATS KMS property describes the format/modifier
combinations supported for display on this plane. Read and parse this
format, storing the data in each plane, so we can know which
combinations might work, and which combinations definitely will not
work.
Similarly to f11ec02cad ("compositor-drm: Extract overlay FB import to
helper"), we now use this when considering promoting a view to overlay
planes. If the framebuffer's modifier is definitely not supported by the
plane, we do not attempt to use that plane for that view.
This will also be used in a follow-patch, passing the list of modifiers
to GBM surface allocation to allow it to allocate more optimal buffers.
Signed-off-by: Sergi Granell <xerpi.g.12@gmail.com>
Reviewed-by: Daniel Stone <daniels@collabora.com>
Reviewed-by: Pekka Paalanen <pekka.paalanen@collabora.co.uk>
Tested-by: Emre Ucan <eucan@de.adit-jv.com>
Add support for the GBM_BO_IMPORT_FD_MODIFIER path, which allows us to
import multi-plane dmabufs, as well as format modifiers.
Signed-off-by: Daniel Stone <daniels@collabora.com>
Reviewed-by: Pekka Paalanen <pekka.paalanen@collabora.co.uk>
Tested-by: Emre Ucan <eucan@de.adit-jv.com>
Fixes: https://gitlab.freedesktop.org/wayland/weston/issues/113
When creating a drm_fb from client (wl_buffer/dmabuf), gbm_surface, or
client buffers, set fb->size to 0. The size member is only used for dumb
buffers, where we mmap the whole buffer, and need the size recorded to
later pass to munmap.
Determining the full size of multi-planar buffers is difficult, as
auxiliary planes are not guaranteed to have a (height*stride)
allocation, e.g. if they are subsampled or if they do not contain pixel
data at all but, e.g., compression information. Single-plane tiled
buffers also often pad the buffer allocation to a multiple of tile
height, making our existing calculation incorrect.
Though it does no harm to record incorrect information, it also does
no good as we never use it; remove it in order to avoid any confusion.
Signed-off-by: Daniel Stone <daniels@collabora.com>
Reviewed-by: Pekka Paalanen <pekka.paalanen@collabora.co.uk>
ARRAY_LENGTH returns a size_t; rather than casting its result to
int so we can compare to our signed index variable, just declare the
index as a compatible type in the first place.
Signed-off-by: Daniel Stone <daniels@collabora.com>
Reviewed-by: Pekka Paalanen <pekka.paalanen@collabora.co.uk>
The DPMS connector property is an enum property in KMS, which made our
property handling complain at startup as we weren't defining its enums.
Fix our definition so we parse the enum values.
The only user of the property is the legacy path, which can continue
using fixed values as those values are part of the KMS ABI. The atomic
path does not need any changes, since atomic uses routing and CRTC
active to determine the connector's power state, rather than a property.
Signed-off-by: Daniel Stone <daniels@collabora.com>
Fixes: https://gitlab.freedesktop.org/wayland/weston/issues/125
Reviewed-by: Pekka Paalanen <pekka.paalanen@collabora.co.uk>
Use the new drmModeAddFB2WithModifiers interface to import buffers with
modifiers.
Signed-off-by: Daniel Stone <daniels@collabora.com>
Reviewed-by: Pekka Paalanen <pekka.paalanen@collabora.co.uk>
Tested-by: Emre Ucan <eucan@de.adit-jv.com>
We currently do the same thing in two places, and will soon have a
third.
Signed-off-by: Daniel Stone <daniels@collabora.com>
Reviewed-by: Pekka Paalanen <pekka.paalanen@collabora.co.uk>
Tested-by: Emre Ucan <eucan@de.adit-jv.com>
Use the same codepath, which has the added advantage of being able to
import dmabufs.
Signed-off-by: Daniel Stone <daniels@collabora.com>
Reviewed-by: Pekka Paalanen <pekka.paalanen@collabora.co.uk>
Tested-by: Emre Ucan <eucan@de.adit-jv.com>
... in order to be able to use it from scanout as well.
In doing this, the check for format compatibility is moved from after
selecting a plane to before selecting a plane. If different planes have
disjoint format support, this ensures that we don't reject the view from
all overlay consideration, just because the first plane we found didn't
support its format.
Signed-off-by: Daniel Stone <daniels@collabora.com>
Reviewed-by: Pekka Paalanen <pekka.paalanen@collabora.co.uk>
Tested-by: Emre Ucan <eucan@de.adit-jv.com>
Use the new helper to populate the cursor state as well, with some
special-case handling to account for how we always upload a full-size
BO.
As this now fully takes care of buffer transformations, HiDPI client
cursors work, and we also clip the cursor plane completely to CRTC
bounds.
Signed-off-by: Daniel Stone <daniels@collabora.com>
Reviewed-by: Pekka Paalanen <pekka.paalanen@collabora.co.uk>
Reported-by: Derek Foreman <derekf@osg.samsung.com>
Tested-by: Emre Ucan <eucan@de.adit-jv.com>
Fixes: https://gitlab.freedesktop.org/wayland/weston/issues/118
Now that we have a helper to fill the plane state co-ordinates from a
view, use this for the scanout plane.
We now explicitly check that the view fills exactly the fullscreen area
and nothing else. We then use the new helper to fill out the plane state
values, and do further checks against the filled-in co-ordinates, i.e.
that we're not trying to show an offset into the buffer, or to scale the
image.
This now allows cases where the buffer -> surface -> view -> output
transform chain cancels each other out for scaling: previously, we would
never consider a buffer for scanout unless its scale matched the
output's. We now only look at the final result of the buffer -> output
transformation, to check that this does not result in translation or
scaling.
An audit of the error paths found some places where we would leave a
plane state hanging; this makes them all consistent.
Signed-off-by: Daniel Stone <daniels@collabora.com>
Reviewed-by: Pekka Paalanen <pekka.paalanen@collabora.co.uk>
Tested-by: Emre Ucan <eucan@de.adit-jv.com>
When considering a view for placement into an overlay plane, we
previously checked that the buffer's transform and scale were identical
to the output's, and that there were no transformations applied.
We now use a more consistent set of checks through
drm_plane_state_coords_for_view. This checks the complete transformation
chain, allowing only translation and scaling; at the end, we check if
the total buffer -> surface -> view -> output chain requires scaling or
rotation, and disallow it if so.
This allows scaling in the cases where the transformation chain cancels
itself out to produce a 1:1 buffer -> output pixel scale.
An erroneously disallowed case is where buffer -> view -> output
rotations cancel each other out; we prevent a view from being on an
overlay plane if rotation is involved at all. Fixing this would require
a complete analysis of the overall transformation matrix.
Signed-off-by: Daniel Stone <daniels@collabora.com>
Reviewed-by: Pekka Paalanen <pekka.paalanen@collabora.co.uk>
Tested-by: Emre Ucan <eucan@de.adit-jv.com>
In our new and improved helper to determine the src/dest values for a
buffer on a given plane, make sure we account for all buffer
transformations, including viewport clipping.
Rather than badly open-coding it ourselves, just use the helper which
does exactly this.
Signed-off-by: Daniel Stone <daniels@collabora.com>
Reviewed-by: Pekka Paalanen <pekka.paalanen@collabora.co.uk>
Reported-by: Tiago Gomes <tiago.gomes@codethink.co.uk>
Tested-by: Emre Ucan <eucan@de.adit-jv.com>
Pull this into a helper function, so we can use it everywhere.
Signed-off-by: Daniel Stone <daniels@collabora.com>
Reviewed-by: Pekka Paalanen <pekka.paalanen@collabora.co.uk>
Tested-by: Emre Ucan <eucan@de.adit-jv.com>
Rather than a hardcoded ARGB8888 -> XRGB8888 translation inside a
GBM-specific helper, just determine whether or not the view is opaque,
and use the generic helpers to implement the format translation.
As a consequence of reordering the calls in
drm_output_prepare_overlay_view(), we move the GBM BO dereference into a
different failure path, before it gets captured by the plane state.
Signed-off-by: Daniel Stone <daniels@collabora.com>
Reviewed-by: Pekka Paalanen <pekka.paalanen@collabora.co.uk>
Tested-by: Emre Ucan <eucan@de.adit-jv.com>
e2e8013633 fixed the same issue as df573031d0 in a different way.
The latter commit (applied earlier in the upstream tree) adds a variable
to assign_planes to keep track of when we successfully assign a view to
the scanout plane, and doesn't call prepare_scanout_view if we have.
The former commit adds this checking inside prepare_scanout_view: if the
pending output state already has a framebuffer assigned to the scanout
plane, we drop out of prepare_scanout_view early. The picked_scanout
variable inside assign_planes can thus be removed.
Signed-off-by: Daniel Stone <daniels@collabora.com>
Reviewed-by: Pekka Paalanen <pekka.paalanen@collabora.co.uk>
Tested-by: Emre Ucan <eucan@de.adit-jv.com>
Since it doesn't write to the parameter, we can make it const.
Signed-off-by: Daniel Stone <daniels@collabora.com>
Reviewed-by: Pekka Paalanen <pekka.paalanen@collabora.co.uk>
The flag bits 19-22 of the connector modes, provide the aspect-ratio
information. This information can be stored in flags bits of the
weston mode structure, so that it can used for setting a mode with a
particular aspect-ratio.
Currently, DRM layer supports aspect-ratio with atomic-modesetting by
default. For legacy modeset path, the user-space needs to set the
drm client cap for aspect-ratio, if it wants aspect-ratio information
in modes.
This patch:
- preserves aspect-ratio flags from kernel video modes and
accommodates it in wayland mode.
- uses aspect-ratio to pick the appropriate mode during modeset.
- changes the mode format in configuration file weston.ini to
accommodate aspect-ratio information as:
WIDTHxHEIGHT@REFRESH-RATE ASPECT-RATIO
The aspect-ratio can take the following values :
4:3, 16:9, 64:27, 256:135.
v2: As per recommendation from Pekka Paalanen, Quentin Glidic,
Daniel Stone, dropped the aspect-ratio info from wayland protocol,
thereby avoiding exposure of aspect-ratio to the client.
v3: As suggested by Pekka Paalanen, added aspect_ratio field to store
aspect-ratio information from the drm. Also added drm client
capability for aspect-ratio, as recommended by Daniel Vetter.
v4: Minor modifications and fixes as suggested by Pekka Paalanen.
v5: Rebased, fixed some styling issues, and added aspect-ratio
information while printing weston_modes.
v6: Moved the man pages changes to a different patch. Minor
reorganization of code as suggested by Pekka Paalanen.
Signed-off-by: Ankit Nautiyal <ankit.k.nautiyal@intel.com>
[Pekka: replace ARRAY_SIZE with ARRAY_LENGTH]
Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.co.uk>
This is regression apparently introduced in
0de859ede4, which accidentally swapped the
sign of 'delta_width' in the original call site. If one removes an
output, the remaining outputs on the right are getting moved even
further to the right.
The outputs to the right should be moved to the left instead, to close
the gap left by the removed output.
Reported-by: Tomasz Olszak <olszak.tomasz@gmail.com>
Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.co.uk>
Reviewed-by: Ian Ray <ian.ray@ge.com>
Some modeline generators put out e.g. +HSync instead of +hsync. Accept
that too since it's not ambigous.
Signed-off-by: Guido Günther <agx@sigxcpu.org>
Reviewed-by: Pekka Paalanen <pekka.paalanen@collabora.co.uk>
This adds a function to detect the first framebuffer device in the
current seat. Instead of hardcoding /dev/fb0, detect the device
with udev, favoring the boot_vga device, and falling back to the
first framebuffer device in the seat if there is none. This is very
similar to what compositor-drm does to find display devices
Reviewed-by: Pekka Paalanen <pekka.paalanen@collabora.co.uk>
Reviewed-by: Emil Velikov <emil.velikov@collabora.com>
This attempts to wake up secondary framebuffer devices
(/dev/fb1 and up) as usually these devices start powered off, and
the FBIOPUT_VSCREENINFO ioctl turns it on. This was tested on a
qemu system with the options:
-vga none -device VGA,id=video0 -device secondary-vga,id=video1 \
-device secondary-vga,id=video2
Reviewed-by: Pekka Paalanen <pekka.paalanen@collabora.co.uk>
Reviewed-by: Emil Velikov <emil.velikov@collabora.com>
As only seat0 supports TTYs, this changes the logind launcher where
it detects a TTY, only if the seat is seat0. This has only been
tested for logind
Reviewed-by: Pekka Paalanen <pekka.paalanen@collabora.co.uk>
Reviewed-by: Emil Velikov <emil.velikov@collabora.com>
This allows the fbdev backend to run on, and use devices from the
specified seat, similar to the drm backend.
Reviewed-by: Pekka Paalanen <pekka.paalanen@collabora.co.uk>
Reviewed-by: Emil Velikov <emil.velikov@collabora.com>
This will allow the seat to be set by the environment as pam_systemd typically
sets the XDG_SEAT variable
Reviewed-by: Pekka Paalanen <pekka.paalanen@collabora.co.uk>
Reviewed-by: Emil Velikov <emil.velikov@collabora.com>
Rather than having a hardcoded dependency on the build-directory layout,
use an explicit module-map environment variable, which rewrites requests
for modules and helper/libexec binaries to specific paths.
Pekka: This will help with migration to Meson where setting up the paths
according to autotools would be painful and unnecessary.
Emre: This should also help setting up the test suite after a
cross-compile.
Pekka: A caveat here is that this patch makes it slightly easier to load
external backends by abusing the module map. External backends are
specifically not supported in libweston.
Signed-off-by: Daniel Stone <daniels@collabora.com>
v2:
Fixed ivi_layout-test-plugin.c:wet_module_init().
Do not change the lookup name of ivi-layout.ivi.
Improved documentation of weston_module_path_from_env() and made it cope
with map strings that a) do not end with a semicolon, and b) have
multiple consecutive semicolons.
Let WESTON_MODULE_MAP be printed into the test log so that it is easier
to run tests manually.
Reviewed-by: Daniel Stone <daniels@collabora.com>
Reviewed-by: Emre Ucan <eucan@de.adit-jv.com>
Suggested by Emil: Use a variable for strlen(name).
Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.co.uk>
Reviewed-by: Emil Velikov <emil.velikov@collabora.com>
If the user is in group 0, we'd exit the loop early with a failure. Make sure
we run through all groups.
https://gitlab.freedesktop.org/wayland/weston/issues/86
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
[Pekka: fix one whitespace]
Reviewed-by: Pekka Paalanen <pekka.paalanen@collabora.co.uk>
All outputs is canceled repaint when a output repaint is failed. At that
time, the output whose repaint is success is not scheduled because the
repaint status of that is still REPAINT_AWAITING_COMPLETION. Therefore,
we need to reset repaint schedule for all repainted outputs.
Signed-off-by: Tomohito Esaki <etom@igel.co.jp>
Reviewed-by: Pekka Paalanen <pekka.paalanen@collabora.co.uk>
This implements a new global interface weston_touch_calibration, which
allows one client at a time to perform touchscreen calibration. This
also implements the calibrator window management.
A client asks to calibrate a specific physical touch device (not a
wl_seat which may have several physical touch devices aggregated).
Libweston grabs all touch devices and prevents normal touch event
handling during the calibation sequence.
API is added to enable this new global interface, but it not yet called
by anything. Since the implementation allows clients to grab touch devices
arbitrarily, it is not enabled by default. The compositor should take
measures to prevent unexpected access to the interface.
A client may upload a new calibration to the compositor. There is a
vfunc to allow the compositor to reject/accept it and save it to
persistent storage. The persistent storage could be a udev rule
setting LIBINPUT_CALIBRATION_MATRIX, so that all display server would
load the new calibration automatically.
Co-developed by Louis-Francis and Pekka.
v2:
- use struct weston_point2d_device_normalized
- use syspath instead of devpath
- wrong_touch was renamed to invalid_touch
- rename weston_touch_calibrator::cancelled to calibration_cancelled
- send invalid_touch on out-of-bounds touch-down
- cancel touch sequence and send invalid_touch on motion going
out-of-bounds
- rename calcoord_from_double() to wire_uint_from_double()
- send bad_coordinates error in touch_calibrator_convert()
- conversion results in 0,0 if cancelled
Signed-off-by: Louis-Francis Ratté-Boulianne <lfrb@collabora.com>
Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.co.uk>
v1 Tested-by: Matt Hoosier <matt.hoosier@gmail.com>
Reviewed-by: Peter Hutterer <peter.hutterer@who-t.net>
In addition to the normal touch event processing mode, introduce a new
mode for calibrating a touchscreen input device.
In the calibration mode, normal touch event processing is skipped, and
the raw events are forwarded to the calibrator instead. The calibrator
is not yet implemented, so the calls will be added in a following patch.
To switch between modes, two functions are added, one for entering each
mode. The mode switch happens only when no touches are down on any touch
device, to avoid confusing touch grabs and clients. To realise this, the
state machine has four states: prepare and actual state for both normal
and calibrator modes.
At this point nothing will attempt to change the touch event mode.
The new calibrator mode is necessary, because when calibrating a
touchscreen, the touch events must be routed to the calibration client
directly. The touch coordinates are expected to be wrong, so they cannot
go through the normal focus surface picking. The calibrator code also
cannot use the normal touch grab interface, because it needs to be able
to distinguish between different physical touch input devices, even if
they are part of the same weston_seat. This requirement makes
calibration special enough to warrant the new mode, a sort of "super
grab".
Co-developed by Louis-Francis and Pekka.
Signed-off-by: Louis-Francis Ratté-Boulianne <lfrb@collabora.com>
Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.co.uk>
v1 Tested-by: Matt Hoosier <matt.hoosier@gmail.com>
Reviewed-by: Peter Hutterer <peter.hutterer@who-t.net>
Commit a30e29af2e introduced the code to
deal with a touchscreen with touches already down when Weston starts
using it. It fixed the touchpoint counting problem.
However, Weston still should not forward or process the unmatched
touch-ups either. Code inspection says it would confuse the
idle-inhibit counting, and it could probably confuse clients as well.
Hence, just drop unmatched touch-ups.
Enhance the warning message to allow identifying where the event came
from.
v2:
- use syspath instead of devpath
Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.co.uk>
v1 Reviewed-by: Peter Hutterer <peter.hutterer@who-t.net>
v1 Tested-by: Matt Hoosier <matt.hoosier@gmail.com>
Reviewed-by: Peter Hutterer <peter.hutterer@who-t.net>
The touchpoint counting is needed regardless of what we do with the
touch events, so move it out of process_touch_normal() into the caller
notify_touch_normalized().
This is pure refactoring.
Signed-off-by: Louis-Francis Ratté-Boulianne <lfrb@collabora.com>
Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.co.uk>
v1 Tested-by: Matt Hoosier <matt.hoosier@gmail.com>
Reviewed-by: Peter Hutterer <peter.hutterer@who-t.net>
notify_touch_normalized() is an extended form of notify_touch(), adding
normalized touch coordinates which are necessary for calibrating a
touchscreen.
It would be possible to invert the transformation and convert from
global coordinates to normalized device coordinates in input.c without
adding this API, but this way it is more robust against code changes.
Recovering normalized device coordinates is necessary because libinput
calibration matrix must be given in normalized units, and it would be
difficult to compute otherwise. Libinput API does not offer normalized
coordinates directly either, but those can be fetched by pretending the
output resolution is 1x1.
Anticipating touch calibration mode, the old notify_touch() is renamed
into a private process_touch_normal(), and the new
notify_touch_normalized() delegates to it.
Co-developed by Louis-Francis and Pekka.
v2:
- introduce struct weston_point2d_device_normalized
- rename notify_touch_cal() to notify_touch_normalized()
- remove WESTON_INVALID_TOUCH_COORDINATE
Cc: Louis-Francis Ratté-Boulianne <lfrb@collabora.com>
Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.co.uk>
v1 Tested-by: Matt Hoosier <matt.hoosier@gmail.com>
Reviewed-by: Peter Hutterer <peter.hutterer@who-t.net>
Relay touch input events into libweston core through the
weston_touch_device, so that the core can tell which individual physical
device they come from.
This is necessary for supporting touchscreen calibration, where one
needs to process a single physical device at a time instead of the
aggregate of all touch devices on the weston_seat.
Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.co.uk>
v1 Tested-by: Matt Hoosier <matt.hoosier@gmail.com>
Reviewed-by: Peter Hutterer <peter.hutterer@who-t.net>
Move calibration printing here and call do_set_calibration() from
evdev_device_set_calibration() so that all matrix setting paths print
the same way.
Print the matrix values in a matrix style to help readability, and
mention the input device.
v2:
- use 'cal' instead of 'calb' as variable name
Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.co.uk>
v1 Tested-by: Matt Hoosier <matt.hoosier@gmail.com>
Reviewed-by: Peter Hutterer <peter.hutterer@who-t.net>
Introduce weston_touch_device for libweston core to track individual
touchscreen input devices. A weston_seat/weston_touch may be an
aggregation of several physical touchscreen input devices. Separating
the physical devices will be required for implementing touchscreen
calibration. One can only calibrate one device at a time, and we want to
make sure to handle the right one.
Both backends that support touch devices are updated to create
weston_touch_devices. Wayland-backend provides touch devices that cannot
be calibrated, because we have no access to raw touch coordinates from
the device - calibration is the responsibility of the parent display
server. Libinput backend provides touch devices that can be calibrated,
hence implementing the set and get calibration hooks.
Backends need to maintain an output pointer in any case, so we have a
get_output() hook instead of having to maintain an identical field in
weston_touch_device. The same justification applies to
get_calibration_head_name.
Also update the test plugin to manage weston_touch_device objects.
Co-developed by Louis-Francis and Pekka.
v2:
- Consistently use 'cal' instead of 'calb' or 'matrix'.
- change devpath into syspath
- update copyrights
Signed-off-by: Louis-Francis Ratté-Boulianne <lfrb@collabora.com>
Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.co.uk>
v1 Tested-by: Matt Hoosier <matt.hoosier@gmail.com>
Reviewed-by: Peter Hutterer <peter.hutterer@who-t.net>
Rather than segfaulting by attempting to traverse an initially
null log handler pointer, explicitly print a message and abort.
Signed-off-by: Matt Hoosier <matt.hoosier@gmail.com>
Reviewed-by: Ian Ray <ian.ray@ge.com>
[Pekka: coding style fix]
Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.co.uk>
The SURFACE_BITS_COMMAND struct has changed and some members have been moved in the
bmp field.
Reviewed-by: Pekka Paalanen <pekka.paalanen@collabora.co.uk>
Tested-by: Pekka Paalanen <pekka.paalanen@collabora.co.uk>
Allow global control of the pixman shadow buffers. The compositor can
choose whether all output use or do not use a shadow buffer with the
pixman renderer.
The option is added to the end of struct weston_drm_backend_config to
avoid bumping WESTON_DRM_BACKEND_CONFIG_VERSION.
Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.co.uk>
Signed-off-by: Fabien Lahoudere <fabien.lahoudere@collabora.com>
Reviewed-by: Ian Ray <ian.ray@ge.com>
Add a flag to pixman-renderer for initializing the output with a shadow
framebuffer. All backends were getting the shadow implcitly, so all
backends are modified to ask for the shadow explicitly.
Using a shadow buffer is usually beneficial, because read-modify-write
cycles (blending) into a scanout-capable buffer may be very slow. The
scanout framebuffer may also have reduced color depth, making blending
and read-back produce inferior results.
In some use cases though the shadow buffer might be just an extra copy
hurting more than it helps. Whether it helps or hurts depends on the
platform and the workload. Therefore let the backends control whether
pixman-renderer uses a shadow buffer for an output or not.
Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.co.uk>
Signed-off-by: Fabien Lahoudere <fabien.lahoudere@collabora.com>
Reviewed-by: Ian Ray <ian.ray@ge.com>
Pixman-renderer uses a single internal shadow buffer. It is enough to
composite the current damage into shadow, but the copy to hw buffer
needs to include the previous damage because of double-buffering in
DRM-backend.
This patch lets pixman-renderer do exactly that without compositing also
the previous damage on DRM-renderer.
Arguably weston_output should not have field previous_damage to begin
with, because it implies double-buffering, which e.g. EGL does not
guarantee. It would be better for each backend explicitly always provide
any extra damage that should be copied to hw.
Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.co.uk>
Signed-off-by: Fabien Lahoudere <fabien.lahoudere@collabora.com>
Reviewed-by: Ian Ray <ian.ray@ge.com>
This issue was likely introduced by "libweston: add
weston_view_set_output()" which forgot to ensure the output destroy
listener is removed when weston_view is destroyed, leading to freed
memory being left into the list.
This was quite easy to trigger by opening and closing an application
window a few times, leading various memory corruption symptoms.
Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.co.uk>
Reviewed-by: Ian Ray <ian.ray@ge.com>
Instead of desktop shell assigning view outputs directly,
use a new method, weston_view_set_output(). The method can
set up an output destroy listener to make sure that views
do not have stale output pointers.
Without this patch it is possible to end up in a scenario
where, e.g. configure_static_view() accesses memory that
has already been freed. The scenario can be provoked by
repeatedly plugging and unplugging a display. The faulty
memory accesses are reported by valgrind.
Signed-off-by: Semi Malinen <semi.malinen@ge.com>
Signed-off-by: Fabien Lahoudere <fabien.lahoudere@collabora.com>
Reviewed-by: Pekka Paalanen <pekka.paalanen@collabora.co.uk>
Allow cloning up to 4 connectors from the same CRTC. All the
implementation bits support more than one head per output already.
Four is just an arbitary number, small but unlikely to ever be the
limiting factor in cloning since hardware is usually very restricted.
Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.co.uk>
Acked-by: Derek Foreman <derekf@osg.samsung.com>
Reviewed-by: Daniel Stone <daniels@collabora.com>
For the attach on an enabled output to have an effect, we need to go
through drmModeSetCrtc or ATOMIC_ALLOW_MODESET.
v9:
- Add another XXX comment.
Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.co.uk>
Acked-by: Derek Foreman <derekf@osg.samsung.com>
Reviewed-by: Daniel Stone <daniels@collabora.com>
When a head is detached from an enabled output, that output needs to go
through a modeset (drmModeSetCrtc() / ATOMIC_ALLOW_MODESET) so that the
connector is actually removed from the CRTC.
This has not yet been a problem, because an output could only have one
head at a time, and would be automatically disabled on detach. It would
be a problem with clone mode.
Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.co.uk>
Acked-by: Derek Foreman <derekf@osg.samsung.com>
Reviewed-by: Daniel Stone <daniels@collabora.com>
If we are processing a connector that does not have an existing routing,
it is possible we pick a CRTC that was previously routed to a connector
we have not enabled yet. If that happens, the latter connector cannot
preserve its routing.
Check that no other connector we might enable later had this CRTC
before.
Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.co.uk>
Acked-by: Derek Foreman <derekf@osg.samsung.com>
Reviewed-by: Daniel Stone <daniels@collabora.com>
To support shared-CRTC clone mode, the chosen CRTC needs to support
driving all the attached connectors. Replace the old algorithm with a
new one that takes into account all associated connectors.
Ideally it should use possible_clones mask to check which encoders (and
therefore connectors) actually can be in a cloned set. However, the DRM
documentation says about possible_clones and possible_crtcs masks both:
"In reality almost every driver gets this wrong."
- https://01.org/linuxgraphics/gfx-docs/drm/gpu/drm-kms.html#c.drm_encoder
Looking at a target device and its kernel where clone mode is desired,
possible_clones is indeed self-conflicting and would not allow cloning
at all. Therefore the implemented algorithm replaces the checking of
possible_clones with luck. It even goes out of its way to find any CRTC
for a configuration, even if not advertised by the kernel as not
supported.
Libweston would need infrastructure to allow trial-and-error CRTC
allocation: rather than picking one CRTC in advance and do or die, it
should try all available CRTCs one by one. Unfortunately that is not yet
possible, so this patch implements what it can. It is also the DRM
upstream opinion that trial-and-error with ATOMIC_TEST would be the way
to go.
Unlike the old algorithm, the new algorithm prefers routings that were
in place when Weston started instead of when enabling an output. When
you never temporarily disable an output, this makes no difference.
Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.co.uk>
Acked-by: Derek Foreman <derekf@osg.samsung.com>
Reviewed-by: Daniel Stone <daniels@collabora.com>
compositor.c has 'touch', so use 'touch' here as well. It is not a
device to begin with.
Signed-off-by: Louis-Francis Ratté-Boulianne <lfrb@collabora.com>
Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.co.uk>
Reviewed-by: Peter Hutterer <peter.hutterer@who-t.net>
v1 Tested-by: Matt Hoosier <matt.hoosier@gmail.com>
We have weston_seat_{init,release}_{pointer,keyboard,touch}() as the
backend-facing API. There is no need to expose the create/destroy
functions which have been for internal use only for quite a long time.
Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.co.uk>
Reviewed-by: Peter Hutterer <peter.hutterer@who-t.net>
v1 Tested-by: Matt Hoosier <matt.hoosier@gmail.com>
If an input device is associated to an output that then gets disabled,
there is no case where associating to a different output would be
correct.
The output association is used for absolute positioned input devices,
and an input device like a touchscreen cannot ever be automatically
valid for more than one possible output - the touchscreen display
device.
Therefore do not automatically reassing implicitly associated input
devices to another output. This removes some log spam on shutdown.
In fact, if there can be more than one output at any time, absolute
input devices must be explicitly configured to associate with the
correct output, or the results are essentially undefined in any case.
Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.co.uk>
Reviewed-by: Peter Hutterer <peter.hutterer@who-t.net>
The use case driving this change is a clone mode setup, where the user
is hotplugging or unplugging a cloned touchscreen. Even if the output
and head are force-enabled, the touch device should still follow the
connector connection status. If there is no video signal for the
touchscreen (disconnected connector), then the touch input should be
ignored as well.
When the output is force-enabled, we need to trigger
output_heads_changed from connector status changes. If the head or
output are not force-enabled, the compositor will likely attach and
detach the head as appropriate. In clone mode, the attach or detach
needs to trigger output_heads_changed directly. In other cases, it may
be handled through the output getting enabled or disabled which are
different signals.
Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.co.uk>
Reviewed-by: Peter Hutterer <peter.hutterer@who-t.net>
Associating input devices with weston_outputs by the output name fails
when one output has several heads. We need to match against head names
instead of output names to be able to find all names.
This fixes touchscreen output association in shared-CRTC clone mode when
outputs or input devices appear or disappear.
Even though notify_output_create() is called only when new outputs
appear, the implementation is prepared to also remove output
associations. This will be handy in the future when this function will
handle also head detaching from an output that remains enabled.
Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.co.uk>
Reviewed-by: Peter Hutterer <peter.hutterer@who-t.net>
Removing the output association from an evdev_device is more than just
setting the pointer to NULL, one also needs to remove the destroy
listener and flag the destroy listener as unused (notify == NULL).
evdev_device_set_output() can already remove associations, so let it
also handle an assignment to NULL output.
Fix notify_output_destroy() to handle removing an association correctly.
Previously, the listener was left "used", which would mean the next call
to evdev_device_set_output() would have wl_list_remove()'d, accessing
freed memory. This could be triggered by having a touchscreen with a
specified output association, and unplugging then re-plugging the
corresponding output.
Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.co.uk>
Reviewed-by: Peter Hutterer <peter.hutterer@who-t.net>
In the future evdev_device_set_output() will start getting called more
often, redundantly. Short-circuit the setting if the chosen output is
already set for an input device. This reduces churn in the logs.
Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.co.uk>
Reviewed-by: Peter Hutterer <peter.hutterer@who-t.net>
Helps admins ensure the configuration is correct.
Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.co.uk>
Reviewed-by: Peter Hutterer <peter.hutterer@who-t.net>
The udev property WL_CALIBRATION is an old way of giving Weston a
touchscreen calibration matrix. It is Weston-specific.
The recommended way of setting up a calibration is to use the udev
property LIBINPUT_CALIBRATION_MATRIX, which libinput will load
automatically and therefore applies to all libinput using display
servers and applications.
The syntax of WL_CALIBRATION and LIBINPUT_CALIBRATION_MATRIX is
different as well: WL_CALIBRATION uses pixels as the translation part
units, which makes the values depend on the output resolution.
LIBINPUT_CALIBRATION_MATRIX on the other hand uses normalized units.
Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.co.uk>
Reviewed-by: Peter Hutterer <peter.hutterer@who-t.net>
Print a note that calibration got skipped if the input device supports a
calibration matrix but there is no associated output to compute it from.
Helps with debugging touchscreen calibration issues.
The code is reorganized and commented a bit, but this does not change
the behaviour.
Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.co.uk>
Reviewed-by: Peter Hutterer <peter.hutterer@who-t.net>
Struct 'evdev_device' has field 'devnode' which is initialized to NULL,
never assigned, and finally free()'d. Therefore it is useless.
Remove the dead field.
Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.co.uk>
Reviewed-by: Peter Hutterer <peter.hutterer@who-t.net>
The head was just zalloc()'d, there is no need to memset it to zero.
If a function fails, it is preferable it leaves the output arguments
untouched.
Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.co.uk>
Reviewed-by: Daniel Stone <daniels@collabora.com>
Acked-by: Derek Foreman <derekf@osg.samsung.com>
Rename connector_get_current_mode() because it will be useful for
storing not just the current mode on creating a head.
Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.co.uk>
Reviewed-by: Daniel Stone <daniels@collabora.com>
Acked-by: Derek Foreman <derekf@osg.samsung.com>
Stop using a head for printing the mode list, because there could be
multiple heads. We already gather the mode list from all heads.
No need to print the connector id here, because it is logged with DRM
heads, and core prints the head names on output enable.
The "built-in" flag seemed dead, because it could only be printed if the
kernel provided no modes. If we want more detailed info on where modes
come from, we would need to inspect mode_info or add new flags to
drm_mode or weston_mode.
Add printing the pixel clock, because that is used by the video mode
duplicate removal code.
Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.co.uk>
Reviewed-by: Daniel Stone <daniels@collabora.com>
Acked-by: Derek Foreman <derekf@osg.samsung.com>
If an output has multiple (cloned) heads, it should be enough for any
head to support backlight control for DRM-backend to expose it.
Inspect all attached heads for backlight control and improve the
logging.
Pick the initial backlight level from whatever happens to be the "first"
head, because it's simple.
Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.co.uk>
Reviewed-by: Daniel Stone <daniels@collabora.com>
Acked-by: Derek Foreman <derekf@osg.samsung.com>
A single list of modes needs to be combined from the mode lists in each
attached head. We could just concatenate the lists, but that might
introduce duplicates. Try to avoid duplicates instead by using partially
fuzzy matching.
When a duplicate is found, try to figure out which is more suitable to
use in place of both. If one has the preferred flag and the other
doesn't, take the preferred one. Otherwise use the one already in the
list.
Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.co.uk>
Reviewed-by: Daniel Stone <daniels@collabora.com>
Acked-by: Derek Foreman <derekf@osg.samsung.com>
Previously the log contained one line for EDID data and another line for
the head, and you just had to know they belong together. Make it more
obvious to read by putting both head and EDID info on the same line.
We no longer print EDID data every time it is parsed (on every hotplug
event), but only if it changes. I did take a shortcut here and use
weston_head::device_changed as the print condition which relies on the
compositor clearing it, but a failure to do so just means we print stuff
even if it didn't change.
Head info updates also print the head info and not just the EDID data.
Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.co.uk>
Reviewed-by: Daniel Stone <daniels@collabora.com>
Acked-by: Derek Foreman <derekf@osg.samsung.com>
Fix this function to support more than one head per output.
Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.co.uk>
Reviewed-by: Daniel Stone <daniels@collabora.com>
Acked-by: Derek Foreman <derekf@osg.samsung.com>
Fix this function to support more than one head per output.
Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.co.uk>
Reviewed-by: Daniel Stone <daniels@collabora.com>
Acked-by: Derek Foreman <derekf@osg.samsung.com>
Fix this function to support more than one head per output.
v9:
- Change { connectors, 0 } to { NULL, 0 } in drmModeSetCrtc() args.
Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.co.uk>
Reviewed-by: Daniel Stone <daniels@collabora.com>
Acked-by: Derek Foreman <derekf@osg.samsung.com>
Replace the unused_connectors array by iterating through the head list
instead. A head that is not enabled (attached to an enabled output) is
basically an unused connector.
All connectors regardless of their status have a drm_head. This has the
nice effect that drm_pending_state_apply_atomic() does not need to
re-query the connector properties every time, they can be simply looked
up in the drm_head.
Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.co.uk>
Reviewed-by: Daniel Stone <daniels@collabora.com>
Acked-by: Derek Foreman <derekf@osg.samsung.com>
In previous patches, all the appropriate fields from drm_output have
been moved into drm_head, and resource allocation has been moved away
from drm_output creation. It is time to throw the switch: this patch
disconnects the drm_output and drm_head lifetimes.
Previously a drm_output was created for a connected connector and
destroyed on disconnection. A drm_head was tied to the drm_output
lifetime just to accommodate the head-based output configuration API
temporarily.
Now all connectors will get a head created regardless of their
connection status. Heads are created and destroyed as connectors appear
and disappear (MST), not when they get connected or disconnected. This
should allow the compositor to force-enable a disconnected connector.
An "empty" drm_output is created with weston_backend::create_output()
hook. This now follows the intent of the head-based output configuration
API.
On hotplug events, all connectors' information is updated regardless of
their connection status changes. It is theoretically possible for a
monitor to change without going through a disconnected state in between.
Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.co.uk>
Reviewed-by: Daniel Stone <daniels@collabora.com>
Acked-by: Derek Foreman <derekf@osg.samsung.com>
Move the initialization of the drm_output mode list to
drm_output_set_mode() time.
Once we stop creating the drm_head with the drm_output, there will not
be a head to get the mode list from at drm_output creation time.
Furthermore, once DRM-backend starts supporting more than one head per
output, the combined mode list to be exposed to clients (and the
compositor?) must be constructed with all heads attached.
Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.co.uk>
Reviewed-by: Daniel Stone <daniels@collabora.com>
Acked-by: Derek Foreman <derekf@osg.samsung.com>
The inherited mode is the video mode on the connector when we have not
yet reconfigured the connector, if set.
Get the inherited mode the moment we create a drm_head, not when we
determine the mode for a drm_output. This way we are sure to read all
inherited modes before we reconfigure a single CRTC. Enabling one output
may grab the CRTC from another connector, overwriting whatever mode that
connector might have had.
The inherited mode is stored in drm_head, where we can keep it for the
lifetime of the head, rather than relying on re-loading it from the
kernel at set_mode() time.
Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.co.uk>
Reviewed-by: Daniel Stone <daniels@collabora.com>
Acked-by: Derek Foreman <derekf@osg.samsung.com>
As these planes are allocated on output enable and freed on output
disable, there cannot be a match in the pending_output_list.
Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.co.uk>
Reviewed-by: Daniel Stone <daniels@collabora.com>
Acked-by: Derek Foreman <derekf@osg.samsung.com>
As CRTC is allocated on output enable and deallocated on output disable,
there cannot be any matches in find-by-crtc from the
pending_output_list.
Remove the loop over pending_output_list as never finding anything by
definition.
Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.co.uk>
Reviewed-by: Daniel Stone <daniels@collabora.com>
Acked-by: Derek Foreman <derekf@osg.samsung.com>
A drm_output needs a CRTC only when it is in use. Allocating a CRTC on
creation of drm_output will reserve the CRTC regardless of whether the
output is actually used or not. This may cause creating other
drm_outputs to fail if there are not enough CRTCs.
Instead, allocate the CRTC on drm_output enable() time. A drm_output
will have a valid CRTC only while it is enabled.
This allows us to create drm_output objects arbitrarily and without a
head assignment, which is required by the head-based output API for the
backends. The assigned heads will be known only at enable() time.
Now drm_output_enable() has to call drmModeGetResources() to be able to
find a suitable CRTC. We might want to cache the resources somewhere,
but that is it topic for another patch.
v4: Force resetting unused CRTCs on fini.
Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.co.uk>
Reviewed-by: Daniel Stone <daniels@collabora.com>
Acked-by: Derek Foreman <derekf@osg.samsung.com>
Move the connector related fields from drm_output to the drm_head. A
drm_head represents a connector for now.
The code in drm_head_create() to update connector data, monitor
information, etc. is moved into a new function. This will be useful when
DRM-backend starts creating heads for all connectors regardless of their
connection status and will need to update them on hotplug events.
While incurring the churn to move several fields into struct drm_head,
also refactor out drm_head_assign_connector_info(). This function is
needed later when drm_heads will exist regardless of connected status,
as every hotplug event will need to update the state of all connectors.
At that point we will also start handling connector changes that do not
go through an intermediate disconnected state. This refactoring is
trivial enough to be in this patch to reduce the total amount of changes
to be reviewed.
v6:
- adapt to the new places of updating unused_connectors
- free connector in create_output_for_connector() error path
Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.co.uk>
Reviewed-by: Daniel Stone <daniels@collabora.com>
Acked-by: Derek Foreman <derekf@osg.samsung.com>
Backlight is driven per connector, hence it belongs in struct drm_head.
weston_output::set_backlight() API is remains per output so far. There
is no UI to control backlights per head and adding one would be
difficult for an output that has multiple cloned heads.
Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.co.uk>
Reviewed-by: Daniel Stone <daniels@collabora.com>
Acked-by: Derek Foreman <derekf@osg.samsung.com>
Instead of iterating output_list and pending_output_list, iterate
head_list to find outputs whose connectors have been disconnected.
This helps a following patch to move connector fields from drm_output to
drm_head.
Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.co.uk>
Reviewed-by: Daniel Stone <daniels@collabora.com>
Acked-by: Derek Foreman <derekf@osg.samsung.com>
Making this function not depend on drm_head::output field through
drm_output_find_by_connector() will later allow to remove the
drm_head::output field before removing the unused_connectors array. This
helps keeping the commit more fine-grained.
drm_backend_update_unused_outputs() was only interested in enabled
outputs. The new code is 100% equivalent to the old code. The
difference is that weston_head::output is only set for attached heads. A
connector cannot be in use if it is not attached to an output.
Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.co.uk>
Reviewed-by: Daniel Stone <daniels@collabora.com>
Acked-by: Derek Foreman <derekf@osg.samsung.com>
Switch drm_output_find_by_connector() to search for the output by
iterating the compositor's head_list. drm_head_find_by_connector() will
be useful later on its own.
As of "compositor-drm: start migration to head-based output API" the
head list is guaranteed to contain all created drm_outputs through the
automatically created drm_head.
This simplifies the code a little, introduces
drm_head_find_by_connector(), and works towards the eventual removal of
drm_output_find_by_connector().
Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.co.uk>
Reviewed-by: Daniel Stone <daniels@collabora.com>
Acked-by: Derek Foreman <derekf@osg.samsung.com>
Helps debugging.
Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.co.uk>
Reviewed-by: Daniel Stone <daniels@collabora.com>
Acked-by: Derek Foreman <derekf@osg.samsung.com>
Move the responsibility of ensuring the head will work in the enabled
output to the backends.
A compositor cannot enable an output without heads, and removing the
last head from an output automatically disables the output, so attaching
a new head to an enabled output is only possible for clone mode.
Backends headless, rdp, and x11 forbid clone mode by not having an
attach_head hook implemented; fbdev and wayland explicitly deny clone
mode. Only the DRM backend is affected by this change and even that not
yet because MAX_CLONED_CONNECTORS is 1 in the DRM backend.
Also ensure a global is created for the head when attached to an enabled
output, and log it.
Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.co.uk>
Reviewed-by: Daniel Stone <daniels@collabora.com>
Acked-by: Derek Foreman <derekf@osg.samsung.com>
Support attaching custom data to a weston_output by the traditional
destroy listener / wl_signal_get approach.
Needs a new destroy signal, because user data lifetime should be the
lifetime of the weston_output regradless of its enabled status. The old
destroy signal is for output consumers that only care about enabled
outputs in the system and gets emitted on disable, not on destroy.
Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.co.uk>
Reviewed-by: Daniel Stone <daniels@collabora.com>
Acked-by: Derek Foreman <derekf@osg.samsung.com>
To let users pick an arbitrary name for an output, to be used as e.g. a
configuration key, add API to create an output with a given name. For
the same configuration purpose, add a search function as well.
For the search function to be predictable, forbid creating multiple
outputs with the same name. Previously, creating multiple outputs with
the same name would have needed detatching to create outputs from the
same head, now that is forbidden.
Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.co.uk>
Reviewed-by: Daniel Stone <daniels@collabora.com>
Acked-by: Derek Foreman <derekf@osg.samsung.com>
This will be interesting to see when testing clone mode.
Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.co.uk>
Reviewed-by: Daniel Stone <daniels@collabora.com>
Acked-by: Derek Foreman <derekf@osg.samsung.com>
Remove the scaffolding that allowed backends to be converted one by one
to the head-based API. Nothing is using these members anymore.
Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.co.uk>
Reviewed-by: Ian Ray <ian.ray@ge.com>
Reviewed-by: Daniel Stone <daniels@collabora.com>
Acked-by: Derek Foreman <derekf@osg.samsung.com>
Hook up the libweston facing head-based output API by introducing struct
drm_head, but leave it as a fake so that members can be migrated in
pieces in follow-up patches.
The DRM backend continues to create an output for each connected
connector only, and during output creation it also creates a drm_head
for it. This allows it to pretend it supports the head-based output API
as long as there is only one head per output ever attached.
create_output callback is fake, it will only look up the existing
drm_output by the head name.
Clones are not yet supported, hence max is defined to 1.
This unfortunately introduces some temporary code that will be revomed
later, but seems to be necessary to avoid a single big patch.
v6:
- add missing drm_head_destroy() call
Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.co.uk>
Reviewed-by: Ian Ray <ian.ray@ge.com>
Reviewed-by: Daniel Stone <daniels@collabora.com>
Acked-by: Derek Foreman <derekf@osg.samsung.com>
Follow the standard pattern used in the headless and x11 backend
migration, but also cater for the two other backend modes: --sprawl or
fullscreen-shell, and --fullscreen.
Stops relying on the implicit weston_output::head.
Unlike other backends, this uses the attach_head hook to do the
required head setup that is not possible to do without an output, but
must be done before weston_output_enable(). This also requires the
detach_head hook for the one case where the user attaches a --fullscreen
head and then detaches it without enabling the output.
It is a little awkward to fully initialize heads as late as attach, but
aside from the --sprawl/fullscreen-shell case, there is not really a way
to know the head properties without creating the parent wl_surface and
configuring it.
Heads/outputs created for parent outputs now have distinct names instead
of all being called "wlparent".
Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.co.uk>
Reviewed-by: Ian Ray <ian.ray@ge.com>
Acked-by: Derek Foreman <derekf@osg.samsung.com>
Add safeguards to make it painfully obvious if we ever get the pairing
of wayland_backend_create_output_surface() and
wayland_backend_destroy_output_surface() wrong. Helps catching bugs.
Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.co.uk>
Reviewed-by: Ian Ray <ian.ray@ge.com>
Reviewed-by: Daniel Stone <daniels@collabora.com>
Acked-by: Derek Foreman <derekf@osg.samsung.com>
Follow the standard pattern set by the headless backend which also uses
the the window output API.
Stops relying on the implicit weston_output::head.
Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.co.uk>
Reviewed-by: Ian Ray <ian.ray@ge.com>
Reviewed-by: Daniel Stone <daniels@collabora.com>
Acked-by: Derek Foreman <derekf@osg.samsung.com>
Implement the head-based output API in this backend, and stop relying on
the implicit weston_output::head.
The split between fbdev_head and fbdev_output is somewhat arbitrary.
There is no hotplug or unplug, and there is always 1:1 relationship.
Struct fbdev_screeninfo could have been split as well, but it would not
have made much difference.
I chose fbdev_output to carry the mmap details (buffer_length is now
duplicated here), and fbdev_head to carry the display parameters and
device node path. The device node identifies the head, similar to a
connector.
The backend init creates a head. The compositor uses it to create an
output. Libweston core attaches the head automatically after creating
the output. The attach hook is a suitable place to set up the video
modes on the output as they are dictated by the head, it would be too
late at enable() time.
v7:
- use name argument instead of hardcoded "fbdev" in
fbdev_output_create()
Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.co.uk>
Reviewed-by: Ian Ray <ian.ray@ge.com>
Acked-by: Daniel Stone <daniels@collabora.com>
Acked-by: Derek Foreman <derekf@osg.samsung.com>
Destroying the whole output in reenable would cause list walk
corruption: the loop over output_list in session_notify() is not using
wl_list_for_each_safe so output removal would break it.
Creating a new output is also problematic as it needs the compositor to
configure it, but that probably saved us from another list walk failure:
adding the new output to be list while walking the list, possibly
causing it to be destroyed and re-created ad infinitum.
Instead of a complete destroy/create cycle, just do our internal
disable/enable cycle. That will re-open the fbdev, re-read the
parameters, re-create hw_surface, and reinitialize the renderer output.
A problem with this is if fbdev_set_screen_info() fails. We do read the
new parameters, but we don't communicate them to libweston core or old
clients.
However, it is hard to care: to trigger this path, one needs to
VT-switch to another fbdev app which changes the fbdev parameters. That
is quite difficult as VT-switching has been broken for a good while for
fbdev-backend, at least with logind. Also fbdev_set_screen_info() would
have to fail before one should be able to tell something is wrong.
The real reason behind this patch, though, is the migration to the
head-based output API. Destroying and re-creating an output really does
not fit that design. Destroying and re-creating a head would be better,
but again not testable in the current state.
Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.co.uk>
Reviewed-by: Ian Ray <ian.ray@ge.com>
Acked-by: Daniel Stone <daniels@collabora.com>
Acked-by: Derek Foreman <derekf@osg.samsung.com>
Follow the starndard patttern as the other backends, headless and x11 in
particular, to stop relying on the implicit weston_output::head.
Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.co.uk>
Reviewed-by: Ian Ray <ian.ray@ge.com>
Acked-by: Daniel Stone <daniels@collabora.com>
Acked-by: Derek Foreman <derekf@osg.samsung.com>
Implement the head-based output API in this backend, and stop relying on
the implicit weston_output::head.
Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.co.uk>
Reviewed-by: Ian Ray <ian.ray@ge.com>
Reviewed-by: Daniel Stone <daniels@collabora.com>
Acked-by: Derek Foreman <derekf@osg.samsung.com>
If the idle_repaint() callback has been scheduled when a weston_output
gets destroyed, the callback will hit use-after-free. I have encountered
this when migrating the wayland backend to the head-based API, using
--sprawl, and closing/disconnecting one of the parent compositor
outputs.
Store the idle_repaint callback source, and destroy it in
weston_output_release(), ensuring we don't get a stale call to
start_repaint_loop later.
Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.co.uk>
Reviewed-by: Ian Ray <ian.ray@ge.com>
Reviewed-by: Daniel Stone <daniels@collabora.com>
Acked-by: Derek Foreman <derekf@osg.samsung.com>
The functions called here, particularly
weston_output_transform_scale_init(), rely on current mode being set.
The current mode must also be found in the mode list, though we don't
explicitly check it here.
current_mode not being set is a programmer error. It could be a backend
bug, but it could also be a libweston user bug not calling a set size
function.
Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.co.uk>
Reviewed-by: Ian Ray <ian.ray@ge.com>
Reviewed-by: Daniel Stone <daniels@collabora.com>
Acked-by: Derek Foreman <derekf@osg.samsung.com>
Output make and model are not allowed to be NULL in the protocol, so
ensure they are not forgotten when enabling an output.
Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.co.uk>
Reviewed-by: Ian Ray <ian.ray@ge.com>
Reviewed-by: Daniel Stone <daniels@collabora.com>
Acked-by: Derek Foreman <derekf@osg.samsung.com>
All frontends have been converted to the new head-based output
management API, which means that
weston_compositor_create_output_with_head() is calling
weston_output_attach_head(). We will never hit the implicit attach
anymore.
Therefore we can now require that an output has at least one head when
calling weston_output_enable(). An output without heads is useless.
The auto-add code is removed as dead.
Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.co.uk>
Reviewed-by: Ian Ray <ian.ray@ge.com>
Reviewed-by: Daniel Stone <daniels@collabora.com>
Acked-by: Derek Foreman <derekf@osg.samsung.com>
The signal has been replaced with the heads_changed hook and is no
longer useful.
weston_pending_output_coldplug() is renamed to
weston_compositor_flush_heads_changed() for two reasons: it better
describes what it does now, and it serves as an obvious flag that
libweston ABI has been broken.
Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.co.uk>
Reviewed-by: Ian Ray <ian.ray@ge.com>
Reviewed-by: Daniel Stone <daniels@collabora.com>
Acked-by: Derek Foreman <derekf@osg.samsung.com>
Rename the function pointer to create_head() because that is what it
does on backends that are converted to the head-based API. Update the
documentation to match.
Surprisingly this is not an ABI break, as the function behaviour and
signature remain intact. Hence API_NAME is not bumped.
This is only an API break, and main.c is fixed accordingly.
Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.co.uk>
Reviewed-by: Ian Ray <ian.ray@ge.com>
Reviewed-by: Daniel Stone <daniels@collabora.com>
Acked-by: Derek Foreman <derekf@osg.samsung.com>
Reacting to DRM hotplug events is racy. It is theoretically possible to
get hotplug events for a quick swap from one monitor to another and
process both only after the new monitor is connected. Hence it is
possible for display device information to change without going through
a disconnected state for the head.
To support such cases, add API to allow detecting it in the compositor.
v6:
- change str_null_neq() to str_null_eq()
- rename weston_head_condition_device_changed()
- move the condition from weston_head_set_device_changed() to the
callers
Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.co.uk>
Reviewed-by: Ian Ray <ian.ray@ge.com>
Reviewed-by: Daniel Stone <daniels@collabora.com>
Acked-by: Derek Foreman <derekf@osg.samsung.com>
Add support for subscribing to weston_head destruction.
The primary use case for heads being destroyed arbitrarily is the
DRM-backend with MST connectors, which may disappear on unplug. It is
not just the connector becoming disconnected, it is the connector
actually disappearing.
The compositor needs to know about disappearing heads so that it has a
chance to clean up "orphaned" outputs which do get disabled but still
need destroying at run time. Shutdown would destroy them as well.
Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.co.uk>
Reviewed-by: Derek Foreman <derekf@osg.samsung.com>
Reviewed-by: Ian Ray <ian.ray@ge.com>
Reviewed-by: Daniel Stone <daniels@collabora.com>
Acked-by: Derek Foreman <derekf@osg.samsung.com>
Introduce the API for users (compositors) to create an output from a
head, attach and detach heads, and destroy outputs created this way.
This also adds the backend-facing API to libweston.
In the new API design, a backend creates heads, and the compositor
chooses one or more heads (clone mode) to be driven by an output.
In the future backends will be converted to not create outputs directly
but only in the new create_output hook.
The user subscribes to a heads_changed hook and arranges heads into
outputs from there.
Adding the API this way will allow frontends (main.c) and backends to be
converted one by one. This adds compatiblity paths in
weston_compositor_create_output_with_head() and weston_output_destroy()
so that frontends can be converted first to call these, and then
backends can be converted one by one to the new design. Afterwards, the
compatibility paths will be removed along with weston_output::head.
Currently heads can be added to a disabled output only. This is less
than ideal for clone mode hotplug and should be improved on later.
v4: Remove the wl_output global on head detach if output is enabled.
Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.co.uk>
Reviewed-by: Derek Foreman <derekf@osg.samsung.com>
Reviewed-by: Ian Ray <ian.ray@ge.com>
Reviewed-by: Daniel Stone <daniels@collabora.com>
Acked-by: Derek Foreman <derekf@osg.samsung.com>
Add a hook for compositors to get a callback when heads are added or
their connection status changes, to which compositors likely want to
react to by enabling or disabling outputs (API for that to be added
later).
As many head changes as possible should be coalesced into a single
heads_changed call. Therefore the callback is made from an idle task.
This anticipates a future atomic output configuration API, where the
global output configuration is tested and set atomically instead of one
by one.
weston_pending_output_coldplug() needs to manually execute the
heads_changed call so that initial outputs are created before any
plugins get their start-up idle tasks ran. This is especially important
for ivi-shell which does not support output hotplug, and for tests to
guarantee the expected outputs.
v8:
- Change the callback function pointer into a wl_signal. The API is
changed and renamed.
v6:
- fix a typo
- add comment in weston_pending_output_coldplug()
Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.co.uk>
v6 Reviewed-by: Derek Foreman <derekf@osg.samsung.com>
v6 Reviewed-by: Ian Ray <ian.ray@ge.com>
Reviewed-by: Daniel Stone <daniels@collabora.com>
Acked-by: Derek Foreman <derekf@osg.samsung.com>
weston_compositor needs to maintain a list of all available heads, so
that a compositor can pick and choose which heads to take into or out of
use at arbitrary times. The heads may be on or off, and connected or
disconnected.
Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.co.uk>
Reviewed-by: Derek Foreman <derekf@osg.samsung.com>
Reviewed-by: Ian Ray <ian.ray@ge.com>
Reviewed-by: Daniel Stone <daniels@collabora.com>
Acked-by: Derek Foreman <derekf@osg.samsung.com>
Enabled is orthogonal from connected. A connected head could be
disabled, or a disconnected head could in the future be enabled.
Compositors quite likely want to check if a head is already enabled
before starting to take it into use.
Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.co.uk>
Reviewed-by: Derek Foreman <derekf@osg.samsung.com>
Reviewed-by: Ian Ray <ian.ray@ge.com>
Reviewed-by: Daniel Stone <daniels@collabora.com>
Acked-by: Derek Foreman <derekf@osg.samsung.com>
Heads may be disconnected or connected and the compositor needs to be
able to know the state to know which heads to take into use.
Currently a single head is automatically created with an output, and
outputs are only ever created as connected and destroyed on
disconnection, so it suffices to set connected to true. In the future,
backends are expected to create heads for both connected and
disconnected connectors, so that a connector can be forced on without it
being actually connected.
v6:
- split weston_head_is_enabled() to a new patch
Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.co.uk>
Reviewed-by: Derek Foreman <derekf@osg.samsung.com>
Reviewed-by: Ian Ray <ian.ray@ge.com>
Reviewed-by: Daniel Stone <daniels@collabora.com>
Acked-by: Derek Foreman <derekf@osg.samsung.com>
Heads need to be named, so they can be referenced in logs and
configuration sources.
When clone mode is implemented, output and head names may differ.
Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.co.uk>
Reviewed-by: Derek Foreman <derekf@osg.samsung.com>
Reviewed-by: Ian Ray <ian.ray@ge.com>
Reviewed-by: Daniel Stone <daniels@collabora.com>
Acked-by: Derek Foreman <derekf@osg.samsung.com>
The 'head' member of 'struct weston_output' is going to go unused and
then disappear, so stop using it and find a head from the proper list.
However, this leaves a problem in cms-colord: if you have multiple
monitors driver with the same CRTC, what do you say to the color
management system? The monitors could be different, but all the color
LUTs etc. are in the CRTC and are shared, as is the framebuffer.
Do the simple hack here and just use whatever head happens to be the
first in the list.
The warning is printed in get_output_id(), because if heads are added or
removed while the output is enabled, the id could change.
v6:
- add weston_output_get_first_head(), at first use
- add warning message for nr. heads > 1
Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.co.uk>
Reviewed-by: Ian Ray <ian.ray@ge.com>
Reviewed-by: Daniel Stone <daniels@collabora.com>
Acked-by: Derek Foreman <derekf@osg.samsung.com>
Duplicate these strings to decouple their lifetime from whatever the
backends used. This should prevent hard to catch use after frees and
such problems in the future.
Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.co.uk>
v5 Reviewed-by: Derek Foreman <derekf@osg.samsung.com>
Reviewed-by: Ian Ray <ian.ray@ge.com>
Reviewed-by: Daniel Stone <daniels@collabora.com>
Acked-by: Derek Foreman <derekf@osg.samsung.com>
Remove the wl_resource in the head's resource list when we are
removing the wl_output global. We sent global removal events to clients,
the resources should become dummies until clients reap them. Reset user
data so that clients triying to use dummy objects don't hit e.g. a freed
head pointer.
This fixes a theoretical issue: if an enabled output is disabled and
then gets enabled again, mode changes and wl_surface.enter/leave would
still attempt to use the dummy objects. If a client destroyed a dummy
object, we don't have the destructor to remove it from the resource
list, and libweston would hit freed memory.
Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.co.uk>
v5 Reviewed-by: Derek Foreman <derekf@osg.samsung.com>
Reviewed-by: Ian Ray <ian.ray@ge.com>
Reviewed-by: Daniel Stone <daniels@collabora.com>
Acked-by: Derek Foreman <derekf@osg.samsung.com>
The intention is that in the future backends will dynamically allocate
weston_heads based on the resources they have. The lifetime of a
weston_head will be independent of the lifetime of a weston_output it
may be attached to. Backends allocate objects derived from weston_head,
like they currently do for weston_output. Backend will choose when to
destroy a weston_head.
For clone mode, struct weston_output gains head_list member, which is
the list of attached heads that will all show the same framebuffer.
Since heads are growing out of weston_output, management functions are
added.
Detaching a head from an enabled output is allowed to accommodate
disappearing heads. Attaching a head to an enabled output is disallowed
because it may need hardware reconfiguration and testing, and so
requires a weston_output_enable() call.
As a temporary measure, we have one weston_head embedded in
weston_output, so that backends can be migrated individually to the new
allocation scheme.
v8:
- Do not send wp_presentation_feedback.sync_output events for multiple
wl_output globals in weston_presentation_feedback_present().
v6:
- adapt to upstream changes in weston_output_set_transform()
- use wl_list_for_each_safe in weston_output_release()
- removed weston_output_get_first_head() as it's not needed yet
Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.co.uk>
v5 Reviewed-by: Derek Foreman <derekf@osg.samsung.com>
v7 Reviewed-by: Ian Ray <ian.ray@ge.com>
Reviewed-by: Daniel Stone <daniels@collabora.com>
Acked-by: Derek Foreman <derekf@osg.samsung.com>
Split out a new function. This is a pure refactoring, no change in
behaviour.
This helps a following patch that adds a loop over output->head_list.
Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.co.uk>
v5 Reviewed-by: Derek Foreman <derekf@osg.samsung.com>
Reviewed-by: Ian Ray <ian.ray@ge.com>
Reviewed-by: Daniel Stone <daniels@collabora.com>
Acked-by: Derek Foreman <derekf@osg.samsung.com>
The user data of a wl_resource representing a wl_output protocol object
used to be a pointer to weston_output. Now that weston_output is being
split, wl_output more accurately refers to weston_head which is a single
monitor.
Change the wl_output user data to point to weston_head.
weston_output_from_resource() is replaced with
weston_head_from_resource().
This change is not strictly necessary, but architecturally it is the
right thing to do. In the future there might appear the need to refer to
a specific head of a cloned pair, for instance.
Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.co.uk>
v5 Reviewed-by: Derek Foreman <derekf@osg.samsung.com>
Reviewed-by: Ian Ray <ian.ray@ge.com>
Reviewed-by: Daniel Stone <daniels@collabora.com>
Acked-by: Derek Foreman <derekf@osg.samsung.com>
As a wl_output represents weston_head, use a weston_head pointer as the
wl_output global's user data.
Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.co.uk>
v5 Reviewed-by: Derek Foreman <derekf@osg.samsung.com>
Reviewed-by: Ian Ray <ian.ray@ge.com>
Reviewed-by: Daniel Stone <daniels@collabora.com>
Acked-by: Derek Foreman <derekf@osg.samsung.com>
The wl_output protocol interface exposes things like monitor make,
model, sub-pixel layout and physical dimensions. Obviously wl_output is
meant to represent a monitor.
The abstraction of a monitor is weston_head. Therefore move the wl_output
global and the bound resources list into weston_head.
When clone mode gets implemented in the future, this means that monitors
driven by the same CRTC will still be represented as separate wl_output
globals. This allows to accurately represent the hardware.
Clone mode that used separate, not frame-locked, CRTCs to drive two
monitors as clones would necessarily also be exposed as separate
wl_output since they have different timings.
v6:
- adapt to upstream changes in weston_output_set_transform()
Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.co.uk>
v5 Reviewed-by: Derek Foreman <derekf@osg.samsung.com>
Reviewed-by: Ian Ray <ian.ray@ge.com>
Reviewed-by: Daniel Stone <daniels@collabora.com>
Acked-by: Derek Foreman <derekf@osg.samsung.com>
In order to support clone modes, libweston needs the concept of a head
that is separate from weston_output. While weston_output manages buffers
and the repaint state machine, weston_head will represent a single
monitor. In the future it will be possible to have a single
weston_output drive one or more weston_heads for a clone mode that
shares the framebuffers between all cloned heads.
All the fields that are obviously properties of the monitor are moved
from weston_output into weston_head.
As moving the fields requires one to touch all the backends for all the
assingments, introduce setter functions for them while we are here. The
setters are identical to the old assignments, for now.
As a temporary measure, weston_output embeds a single head. Also the
ugly casts in weston_head_set_monitor_strings() will be removed by a
follow-up patch.
Libweston major version is bumped, because weston_output struct layout
is changed.
v7:
- Bump libweston major version.
v6:
- adapt to upstream changes in weston_output_set_transform()
Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.co.uk>
v5 Reviewed-by: Derek Foreman <derekf@osg.samsung.com>
v6 Reviewed-by: Ian Ray <ian.ray@ge.com>
Reviewed-by: Daniel Stone <daniels@collabora.com>
Acked-by: Derek Foreman <derekf@osg.samsung.com>
If output_list of compositor is empty, value of
ret is read without initialization.
Signed-off-by: Emre Ucan <eucan@de.adit-jv.com>
Reviewed-by: Pekka Paalanen <pekka.paalanen@collabora.co.uk>
we have to set num_images after import_simple_dmabuf
call. Otherwise, egl_images will not be correctly
referenced in gl_renderer_attach_dmabuf.
(Found by clang source code analyzer)
Signed-off-by: Emre Ucan <eucan@de.adit-jv.com>
Reviewed-by: Pekka Paalanen <pekka.paalanen@collabora.co.uk>
If the constraint is an one-shot constraint, constraint
is freed in disable_pointer_constraint function.
Therefore, we should not try to read freed memory at
"switch (constraint->lifetime)" statement.
The removed code is anyway superfluous. Because
surface destroy signal is only removed, when constraint
is an one-shot constraint.
(Found by clang source code analyzer)
Signed-off-by: Emre Ucan <eucan@de.adit-jv.com>
Reviewed-by: Pekka Paalanen <pekka.paalanen@collabora.co.uk>
ret is overwritten by drmModeAddFB2 call
(Found by clang source code analyzer)
Signed-off-by: Emre Ucan <eucan@de.adit-jv.com>
Reviewed-by: Pekka Paalanen <pekka.paalanen@collabora.co.uk>
"has_discrete" gets set to true in if/else if, but gets left unset otherwise.
So let's initialize it to false.
(This was caught by valgrind.)
Signed-off-by: Dima Ryazanov <dima@gmail.com>
Reviewed-by: Pekka Paalanen <pekka.paalanen@collabora.co.uk>
This is already done when weston_output_init_geometry() is called.
Actually this is a fix for 8564a0d, because without this patch, the
compositor sometimes crashes when setting output transform
Signed-off-by: Ilia Bozhinov <ammen99@gmail.com>
Reviewed-by: Pekka Paalanen <pekka.paalanen@collabora.co.uk>
The timestamp could be either NULL if there's no mode set, or 0 when output gets
awaken. It either crashes weston or we get vblanks at [0, 0] for that output.
Signed-off-by: Marius Vlad <marius-cristian.vlad@nxp.com>
CC: Pekka Paalanen <pekka.paalanen@collabora.co.uk>
[Pekka: note, most start_repaint_loop pass in current time, not 0]
Reviewed-by: Pekka Paalanen <pekka.paalanen@collabora.co.uk>
Due to race conditions, it is (vanishingly unlikely but) possible to
receive a wl_pointer.enter event referring to a wl_surface we have just
destroyed. If this happens, wl_surface will be NULL. Detect this, clear
out our focus, and return.
Other pointer and keyboard events are robust against destroyed surfaces.
Signed-off-by: Daniel Stone <daniels@collabora.com>
Cc: Pekka Paalanen <pekka.paalanen@collabora.co.uk>
[Pekka: remove call to input_set_cursor()]
Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.co.uk>
Do not attempt to set keyboard focus to a surface that has no
wl_resource. The destroy listener hangs off the wl_resource, so if that
is not present, nothing will clean up the pointer when the
weston_surface gets destroyed and it goes stale.
As keyboard_focus_resource_destroyed() sets the focus to NULL, this
patch should be enough to guarantee that the keyboard focus surface will
always have a wl_resource.
I have confirmed the added branch in weston_keyboard_set_focus() can be
hit, but doing so is hard.
My test case has weston/x11 with two outputs, and weston/wayland
--sprawl running on top of that, then closing the parent compositor
output windows one by one. Sometimes it hits, often it does not. Having
the window closing animation enabled may help to hit it.
Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.co.uk>
Reviewed-by: Daniel Stone <daniels@collabora.com>
Destroying an output (wl_surface) can race against the parent compositor
sending wl_keyboard.enter. When this race is lost, wayland-backend
receives wl_keyboard.enter with a NULL wl_surface for the surface it
just destroyed.
Handle this case by ignoring such enter events. Since it is
theoretically possible to follow enter with key events, drop those too.
The modifiers event is sent before enter, so we cannot drop that on the
same condition.
wl_keyboard.leave handler seems to already handle the NULL focus case,
but there is a question if the notify_keyboard_focus_out() call should
be avoided.
This patch fixes a hard to reproduce crash. I was running weston/x11
with two outputs, and weston/wayland --sprawl inside that, then closing
the parent compositor windows one by one. Sometimes it would trigger
this crash.
Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.co.uk>
Reviewed-by: Daniel Stone <daniels@collabora.com>
EGL_IMG_context_priority allows the client to request that their
rendering be considered high priority. For ourselves, this is important
as we are interactive and any delay in our rendering causes input-output
jitter; a less than smooth user interactive. So if the driver supports
setting the context priority, try and create our EGLContext as high
priority. The driver may reject our request due to system restrictions,
in which case it will fallback to normal priority, but if successful it
will reschedule our rendering and all of its dependencies to execute
earlier, especially important when the GPU is being hogged by background
clients.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Reviewed-by: Daniel Stone <daniels@collabora.com>
Acked-by: Pekka Paalanen <pekka.paalanen@collabora.co.uk>
If AddFB2 ever fails for any reason, we fall back to legacy AddFB, which
doesn't support the same swathe of formats, or multi-planar formats, or
modifiers.
This can happen with arbitrary client buffers, condemning us to the
fallback forever more. Remove this, at the cost of an unnecessary ioctl
for users on old kernels without AddFB2; unfortunately, we cannot detect
the complete absence of the ioctl, as the return here is -EINVAL rather
than -ENOTTY.
A check for whether or not the format is valid has been replaced with an
assert, as its callers either check that the format is non-zero, return
a FourCC format code from GBM, or use a static FourCC format.
Signed-off-by: Daniel Stone <daniels@collabora.com>
Reviewed-by: Pekka Paalanen <pekka.paalanen@collabora.co.uk>
Make it a bit more clear what the purpose of the variable is.
Signed-off-by: Daniel Stone <daniels@collabora.com>
Reviewed-by: Pekka Paalanen <pekka.paalanen@collabora.co.uk>
Nothing in this loop reorders views within the compositor's view_list.
Signed-off-by: Daniel Stone <daniels@collabora.com>
Reviewed-by: Pekka Paalanen <pekka.paalanen@collabora.co.uk>
The direction of scrolling in the RDP compositor appears to be inverted.
When using Weston directly in X, sending X11 button 4 cuases window
contents to scroll up and button 4 to be reported to xwayland clients.
Conversely, when using Weston through RDP (xfreerdp client), sending
X11 button 4 causes window contents to scroll down and button 5 to be
reported to xwayland clients. The xfreerdp client does not seem to be
the cause of this since scrolling works correctly when connecting to
a Windows host.
Signed-off-by: Jason Gerecke <jason.gerecke@wacom.com>
Reviewed-by: David Fort <contact@hardening-consulting.com>
Pekka Paalanen