Commit Graph

6485 Commits

Author SHA1 Message Date
Derek Foreman
f8f7fd69df input: add weston_keyboard_send_keymap helper function
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>
2018-08-17 09:25:21 -05:00
Derek Foreman
dc1418ae8e configure.ac: bump to version 4.0.93 for the RC1 release 2018-08-10 13:03:57 -05:00
Harsha M M
46cbd0a7f5 ivi-shell: Remove the compositor destory listener from list during de-init
During de-init ensure removal of compositor destroy notification
from list. Otherwise a dongling pointer is left behind which will
affect other plugins.

Signed-off-by: Harsha M M <harsha.manjulamallikarjun@in.bosch.com>
Reviewed-by: Pekka Paalanen <pekka.paalanen@collabora.co.uk>
2018-08-10 13:23:14 +03:00
Harsha M M
b8b2c72709 libweston: Remove signals from the list during de-init
During de-init ensure removal of added signals from list. Otherwise
a dongling pointer is left behind which will affect other plugins.

Signed-off-by: Harsha M M <harsha.manjulamallikarjun@in.bosch.com>
Reviewed-by: Pekka Paalanen <pekka.paalanen@collabora.co.uk>
2018-08-08 12:22:24 +03:00
Will Thompson
103dc42b5e
doc: fix typos in CONTRIBUTING.md
* Cover letters are no more; presumably the changes since the previous
  revision should be summarised in the MR
* Code should be indented with tabs, not implemented with tabs

Signed-off-by: Will Thompson <will@willthompson.co.uk>
2018-08-07 15:19:01 +01:00
Daniel Stone
8798fa7fdf doc: Use GitLab MRs for patches, not the list
Though Wayland and the protocols still use mail-based patch review,
Weston can now move to GitLab MRs with review through that system.

Add some documentation on how to submit patches through GitLab,
specifically targeted at people who may be familiar with GitLab review,
but not familiar with our rebasing microcommit workflow.

Signed-off-by: Daniel Stone <daniels@collabora.com>
Reviewed-by: Quentin Glidic <sardemff7+git@sardemff7.net>
Reviewed-by: Pekka Paalanen <pekka.paalanen@collabora.co.uk>
2018-08-07 14:38:38 +01:00
Daniel Stone
f987cb98ef README: Move to Markdown, rewrite introduction
Move the README file to Markdown, and update it to attempt to explain
the current status and use of Weston.

The first sections are user-facing, so they can quickly understand what
Weston is, what it does, what it doesn't do, and how to go about using
it. The following sections on libweston and for distribution packagers
are left intact, but should probably be moved to separate documents.

This includes a screenshot of Weston running weston-terminal, Chrome and
simple-egl, which was taken by myself and subject to the same licensing
terms as the rest of the tree.

Signed-off-by: Daniel Stone <daniels@collabora.com>
Reviewed-by: Quentin Glidic <sardemff7+git@sardemff7.net>
Reviewed-by: Pekka Paalanen <pekka.paalanen@collabora.co.uk>
2018-08-07 14:38:24 +01:00
Daniel Stone
3a6fa200b7 doc: Update CONTRIBUTING for Weston
Change some Wayland-specific references to instead refer to Weston.

Signed-off-by: Daniel Stone <daniels@collabora.com>
Reviewed-by: Quentin Glidic <sardemff7+git@sardemff7.net>
Reviewed-by: Pekka Paalanen <pekka.paalanen@collabora.co.uk>
2018-08-06 11:55:43 +01:00
Pekka Paalanen
2e3915f1bf Add CONTRIBUTING.md document
Taken from Pekka's wayland/wayland@630c25f4c1 and follow-ups, use
Wayland's CONTRIBUTING document as a basis for Weston.

Signed-off-by: Daniel Stone <daniels@collabora.com>
Reviewed-by: Quentin Glidic <sardemff7+git@sardemff7.net>
Reviewed-by: Pekka Paalanen <pekka.paalanen@collabora.co.uk>
2018-08-06 11:55:40 +01:00
Derek Foreman
0335e44731 configure.ac: bump to version 4.0.92 for the beta release 2018-07-27 11:45:59 -05:00
Daniel Stone
48687982b5 compositor-drm: Remove addfb warning for user buffers
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>
2018-07-27 11:21:10 -05:00
Daniel Stone
1178922590 compositor-drm: Don't test render-only atomic configuration
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>
2018-07-27 11:20:47 -05:00
Daniel Stone
8c9556c57d compositor-drm: Remove unnecessary libdrm defines
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>
2018-07-27 11:20:25 -05:00
Greg V
3ea5437dbd xwayland/selection: do not remove NULL property_source
Happened mostly with neovim's xclip usage.

[daniels: Added more cases.]

Reviewed-by: Daniel Stone <daniels@collabora.com>
2018-07-22 11:37:58 +01:00
Emre Ucan
67546bed04 ivi-shell: use install paths in example config
The example weston.ini file uses source and build
directory paths. Therefore, it is only useful when
used on the same system that is used to build Weston.

We can use install paths instead of build/source paths
to fix this problem.

v2 changes:
- use $(westondatadir) instead of $(datadir)

Reported-by: Michael Tretter <m.tretter@pengutronix.de>
Signed-off-by: Emre Ucan <eucan@de.adit-jv.com>
Reviewed-by: Michael Tretter <m.tretter@pengutronix.de>
Reviewed-by: Emil Velikov <emil.velikov@collabora.com>
Reviewed-by: Daniel Stone <daniels@collabora.com>
2018-07-22 11:17:40 +01:00
Emre Ucan
cf4113c629 ivi-shell: listen compositor wake_signal
If compositor wakes up from sleep state, we have
to trigger repaint for all outputs.

Signed-off-by: Emre Ucan <eucan@de.adit-jv.com>
Reviewed-by: Daniel Stone <daniels@collabora.com>
2018-07-22 11:06:38 +01:00
Derek Foreman
280b730144 configure.ac: bump to version 4.0.91 for the alpha release 2018-07-13 11:32:29 -05:00
Emilio Pozuelo Monfort
cce820dcaf simple-dmabuf-drm: fix build with --disable-egl
Just rely on getting the supported formats through the dmabuf
extension.

Signed-off-by: Emilio Pozuelo Monfort <emilio.pozuelo@collabora.co.uk>
Reviewed-by: Daniel Stone <daniels@collabora.com>
2018-07-13 16:13:32 +01:00
Emilio Pozuelo Monfort
1166f8e9a1 simple-dmabuf-drm: require zwp_linux_dmabuf_v1 v3
We effectively require it as we don't react to dmabuf_format,
only to dmabuf_modifiers, so there's a chance we may not get
the supported formats information at all.

Signed-off-by: Emilio Pozuelo Monfort <emilio.pozuelo@collabora.co.uk>
Reviewed-by: Daniel Stone <daniels@collabora.com>
2018-07-13 16:13:23 +01:00
Daniel Stone
678aabe829 compositor-drm: Enable planes for atomic
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>
2018-07-11 14:17:52 +01:00
Daniel Stone
9fe4bf8863 compositor-drm: Relax plane restrictions for atomic
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>
2018-07-11 14:17:52 +01:00
Daniel Stone
b41abf9c84 compositor-drm: Allow scanout plane to be occluded by overlay
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>
2018-07-11 14:17:52 +01:00
Daniel Stone
a284d271f1 compositor-drm: Incrementally test plane states in mixed mode
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>
2018-07-11 14:17:52 +01:00
Daniel Stone
d12e51646a compositor-drm: Add planes-only mode to state proposal
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>
2018-07-11 13:08:57 +01:00
Daniel Stone
ca6fbe3c93 compositor-drm: Never lift solid surfaces to planes
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>
2018-07-11 12:50:23 +01:00
Daniel Stone
bb6c19f7bb compositor-drm: Add test-only mode to state application
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>
2018-07-11 12:49:53 +01:00
Daniel Stone
f829062ef4 compositor-drm: Return plane state from plane preparation
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>
2018-07-11 12:45:07 +01:00
Daniel Stone
f7a2f835ae compositor-drm: Add modes to drm_output_propose_state
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>
2018-07-11 12:24:55 +01:00
Daniel Stone
44abfaaffd compositor-drm: Use sprites_are_broken for scanout plane
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>
2018-07-11 12:24:55 +01:00
Daniel Stone
a0f8276fe8 compositor-drm: Disallow overlapping overlay planes
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>
2018-07-11 12:24:55 +01:00
Tomohito Esaki
ddaf95c5a1 libweston: Fix clear timing of output repainted flag
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>
2018-07-10 15:40:52 +03:00
Daniel Stone
8108239c39 compositor-drm: Ignore occluded views
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>
2018-07-10 11:12:27 +01:00
Daniel Stone
231ae2f33b compositor-drm: Ignore views on other outputs
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>
2018-07-10 11:12:27 +01:00
Daniel Stone
ee1aea7cd1 compositor-drm: Split drm_assign_planes in two
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>
2018-07-10 11:12:27 +01:00
Daniel Stone
244244d11b compositor-drm: Use GBM modifier API
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>
2018-07-09 15:39:32 +01:00
Sergi Granell
f4456221db compositor-drm: Support plane IN_FORMATS
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>
2018-07-09 15:39:32 +01:00
Daniel Stone
f522e22611 compositor-drm: Add modifiers to GBM dmabuf import
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
2018-07-09 15:39:32 +01:00
Daniel Stone
11f91bbd36 helpers: Move static_assert definition to shared
Collect the fallback definitions of static_assert() from desktop-shell
and the test shell, and move them to helpers.h. This allows code
throughout the tree to use static_assert() for build-time assertions,
where it is supported by the compiler.

As GCC goes out of its way to only add static_assert() when C11 has been
explicitly requested - which we don't do - make sure to use the more
widely available _Static_assert() if that is provided.

This will be used in future patches to ensure two array lengths don't go
out of sync.

Signed-off-by: Daniel Stone <daniels@collabora.com>
Reviewed-by: Pekka Paalanen <pekka.paalanen@collabora.co.uk>
2018-07-09 15:39:20 +01:00
Daniel Stone
bdebc3170e compositor-drm: Don't set fb->size for non-dumb buffers
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>
2018-07-09 15:20:11 +01:00
Daniel Stone
dc082cb071 compositor-drm: Avoid cast by using unsigned loop index
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>
2018-07-09 15:20:11 +01:00
Daniel Stone
7625577a4f compositor-drm: Define DPMS property as an enum
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>
2018-07-09 15:30:03 +03:00
Ankit Nautiyal
79e95cb995 man: Remove description of DRM specific mode-options from weston.ini.man
The weston.ini.man describes the mode-formats that a user can specify
for selecting a video mode. The DRM specific examples are already
provided in weston-drm.man, so this inofrmation is redundant and can
be removed.

This patch removes the DRM specific mode option details from the
description of mode configuration in weston.ini.man.
A pointer to weston-drm.man is given, which has complete information
about the mode-format options supported by DRM backend.

Signed-off-by: Ankit Nautiyal <ankit.k.nautiyal@intel.com>
Reviewed-by: Pekka Paalanen <pekka.paalanen@collabora.co.uk>
2018-07-09 15:14:47 +03:00
Daniel Stone
65a4dbcc14 compositor-drm: Support modifiers for drm_fb
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>
2018-07-06 15:04:52 +01:00
Daniel Stone
8eece0c2e7 compositor-drm: Extract drm_fb_addfb into a helper
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>
2018-07-06 15:04:52 +01:00
Daniel Stone
bdf3e7e356 compositor-drm: Use plane FB-import helper for scanout
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>
2018-07-06 15:04:52 +01:00
Daniel Stone
f11ec02cad compositor-drm: Extract overlay FB import to helper
... 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>
2018-07-06 15:04:52 +01:00
Daniel Stone
9b56038417 compositor-drm: Use plane_state_coords_for_view for cursor
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
2018-07-06 14:56:16 +01:00
Daniel Stone
7cdf231c76 compositor-drm: Use plane_state_coords_for_view for scanout
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>
2018-07-06 14:52:05 +01:00
Daniel Stone
ce137472fa compositor-drm: Only check final co-ordinates for overlay scaling
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>
2018-07-06 14:52:05 +01:00
Daniel Stone
df2726a089 compositor-drm: Fully account for buffer transformation
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>
2018-07-06 14:52:05 +01:00