Now that we can sensibly test proposed plane configurations with atomic,
sprites are not broken.

Signed-off-by: Daniel Stone <daniels@collabora.com>
Tested-by: Emre Ucan <eucan@de.adit-jv.com>

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>
Tested-by: Emre Ucan <eucan@de.adit-jv.com>

The atomic API can allow us to test state before we apply it, to see if
it will be valid. Add support for this, which we will later use in
assign_planes to ensure our plane configuration is valid.

Signed-off-by: Daniel Stone <daniels@collabora.com>
Tested-by: Emre Ucan <eucan@de.adit-jv.com>

Return a pointer to the plane state, rather than indirecting via a
weston_plane.

Signed-off-by: Daniel Stone <daniels@collabora.com>
Tested-by: Emre Ucan <eucan@de.adit-jv.com>

Add support for multiple modes: toggling whether or not the renderer
and/or planes are acceptable. This will be used to implement a smarter
plane-placement heuristic when we have support for testing output
states.

Signed-off-by: Daniel Stone <daniels@collabora.com>
Tested-by: Emre Ucan <eucan@de.adit-jv.com>

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>
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>

Meson is a Python-based build system with multiple output backends,
including Ninja and Make. It's really very fast.

More information at http://mesonbuild.com



Signed-off-by: Daniel Stone <daniels@collabora.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>

Sergi Granell authored Jan 12, 2017 and Daniel Stone committed Jul 09, 2018

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 f11ec02c ("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

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>

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>

Daniel Stone authored Jul 06, 2018 and Pekka Paalanen committed Jul 09, 2018

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>

Ankit Nautiyal authored Jul 06, 2018 and Pekka Paalanen committed Jul 09, 2018

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>

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>

e2e80136 fixed the same issue as df573031 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>

Ankit Nautiyal authored Mar 19, 2097 and Pekka Paalanen committed Jul 06, 2018

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>

Ankit Nautiyal authored Mar 19, 2097 and Pekka Paalanen committed Jul 06, 2018

This patch adds information about the new resolution-format that can
be specified by a user in weston.ini to select a CEA mode. CEA defines
timing of a video mode, which is considered as a standard for
HDMI certification and compliance testing. It defines each and every
parameter, of  a video mode, like h/vactive,h/vfront h/vback etc.,
including aspect-ratio information. The drm layer, specifies the
aspect-ratio information in user-mode flag bits 19-22. For the non-CEA
modes a value of 0 is given in the aspect-ratio flag bits. Each
CEA-mode is identified by a unique, Video Identification Code (VIC).
For example, VIC=4 is 1280x720@60 aspect-ratio 16:9.
This mode will be different than a non-CEA mode 1280x720@60 0:0.

The new mode-format helps to differentiate between the CEA and
non-CEA modes, by letting user specify aspect-ratio along with other
paremeters: mode=widthxheight@rr ratio.

This helps when certification testing is done, in tests like 7-27,
the HDMI analyzer applies a particular CEA mode, and expects the
applied mode to be with exactly same timings, including the
aspect-ratio and VIC field.

Signed-off-by: Ankit Nautiyal <ankit.k.nautiyal@intel.com>
Reviewed-by: Pekka Paalanen <pekka.paalanen@collabora.co.uk>

This is regression apparently introduced in
0de859ed, 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>

When the compositor has multiple outputs (not clones) and one of them is
removed, the ones remaining to the right will be moved to close the gap.
Because reflowing the remaining outputs happens before removing the
wl_output global, we get the new output x,y before the removal. This
causes us to consider the remaining output immediately to the right of
the removed output to be a clone of the removed output whose x,y don't
get updated. That will then hit the two assertions this patch removes.

The reason the assertions were not actually hit is because of a
compositor bug which moved the remaining outputs in the wrong direction.
The next patch will fix the reflow, so we need this patch first to avoid
the asserts.

Remove the assertions and hand over the background and panel if the
"clone" does not already have them. If the clone already has them, we
destroy the unnecessary background and panel.

Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.co.uk>
Reviewed-by: Marius Vlad <marius-cristian.vlad@nxp.com>

Guido Günther authored Jun 26, 2018 and Pekka Paalanen committed Jul 03, 2018

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>

nerdopolis authored Jun 29, 2018 and Pekka Paalanen committed Jul 02, 2018

The framebuffer backend now detects the framebuffer device
dynamically. Don't assume that the framebuffer device is /dev/fb0

Reviewed-by: Pekka Paalanen <pekka.paalanen@collabora.co.uk>
Reviewed-by: Emil Velikov <emil.velikov@collabora.com>

nerdopolis authored Jun 29, 2018 and Pekka Paalanen committed Jul 02, 2018

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>

nerdopolis authored Jun 29, 2018 and Pekka Paalanen committed Jul 02, 2018

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>

nerdopolis authored Jun 29, 2018 and Pekka Paalanen committed Jul 02, 2018

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>

nerdopolis authored Jun 29, 2018 and Pekka Paalanen committed Jul 02, 2018

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>