GStreamer can accept up to four planes for a buffer; gcc isn't _quite_
smart enough to figure out that only the first plane of offset/stride
will be accessed and so throws a warning that the params are too small.
Fix that by making them arrays.

Signed-off-by: Daniel Stone <daniels@collabora.com>

Simple client to test the dma-buf feedback implementation. This does not
replace the need to implement a dma-buf feedback test that can be run in
the CI. But as we still don't know exactly how to do this, this client
can be helpful to run tests manually.

Signed-off-by: Leandro Ribeiro <leandro.ribeiro@collabora.com>
Reviewed-by: Daniel Stone <daniels@collabora.com>

In commit "libweston: add initial dma-buf feedback implementation" we've
added initial support to dma-buf feedback, but it was not using the
feedback from DRM-backend to add useful per-surface feedback.

In this patch we add this. The scanout tranche of the per-surface
feedback is based on the union of formats/modifiers of the primary and
overlay planes available. These are intersected with the
formats/modifiers supported by the renderer device.

Also, it's important to mention that the scene can change a lot and we
can't predict much. So this patch also adds hysteresis to the dma-buf
feedback. We wait a few seconds to be sure that we reached stability
before adding or removing the scanout tranche from dma-buf feedback and
resending them. This help us to avoid spamming clients and leading to
unnecessary buffer reallocations on their end.

Here's an example of what we want to avoid:

1. We detect that a view was not placed in a plane only because its
   format is not supported by the plane, so we add the scanout tranche
   to the feedback and send the events.

2. A few milliseconds after, the view gets occluded. So now the view
   can't be placed in a plane anymore. We need to remove the scanout
   tranche and resend the feedback with formats/modifiers optimal for
   the renderer device. The client will then reallocate its buffers.

3. A few milliseconds after, the view that was causing the occlusion
   gets minimized. So we got back to the first situation, in which the
   format of the view is not compatible with the plane. Then we need to
   add a scanout tranche and resend the feedback...

This patch is based on previous work of Scott Anderson (@ascent).

Signed-off-by: Leandro Ribeiro <leandro.ribeiro@collabora.com>
Signed-off-by: Scott Anderson <scott.anderson@collabora.com>
Reviewed-by: Daniel Stone <daniels@collabora.com>

Add enum try_view_on_plane_failure_reasons to help us to keep track of
the reason why promoting view to a plane failed. We also add a variable
to struct weston_paint_node so that we can update this information in
each output repaint.

This will be used in the next commits, in which we add proper surface
dma-buf feedback support.

Signed-off-by: Leandro Ribeiro <leandro.ribeiro@collabora.com>
Reviewed-by: Daniel Stone <daniels@collabora.com>

This adds the initial dma-buf feedback implementation, following the
changes in the dma-buf protocol extension.

The initial dma-buf feedback implementation gives support to send
default feedback and per-surface feedback. For now the per-surface
feedback support is very basic and is still not implemented in the
DRM-backend, what basically means that KMS plane's formats/modifiers are
not being exposed to clients. In the next commits of this series we add
the DRM-backend implementation.

This patch is based on previous work of Scott Anderson (@ascent).

Signed-off-by: Leandro Ribeiro <leandro.ribeiro@collabora.com>
Signed-off-by: Scott Anderson <scott.anderson@collabora.com>
Reviewed-by: Daniel Stone <daniels@collabora.com>

This just documents why we can be sure that
renderer->get_supported_formats() is set in bind_linux_dmabuf().

Signed-off-by: Leandro Ribeiro <leandro.ribeiro@collabora.com>
Reviewed-by: Daniel Stone <daniels@collabora.com>

It simply returns the number of format/modifier pairs in the array. This
will be useful for the next commits, in which we add support for dma-buf
feedback.

Signed-off-by: Leandro Ribeiro <leandro.ribeiro@collabora.com>
Reviewed-by: Daniel Stone <daniels@collabora.com>

Scott Anderson authored 4 years ago and Leandro Ribeiro committed 3 years ago

Add function to query the DRM device given an EGLDisplay. It is the
device being used by the compositor to perform composition.

This will be useful in the next commits of this series, where we add
support for dma-buf feedback.

Signed-off-by: Scott Anderson <scott.anderson@collabora.com>
Signed-off-by: Leandro Ribeiro <leandro.ribeiro@collabora.com>
Reviewed-by: Daniel Stone <daniels@collabora.com>

Bump the wayland-protocol dependency version in order to include dma-buf
feedback, whose support in Weston is added in the next commits.

Also, as we need the newer EGL extension EGL_EXT_device_drm_render_node
to add the support for dma-buf feedback, bump the Mesa dependency
version as well.

It also includes some minor changes in order to keep build-deps.sh more
consistent.

Signed-off-by: Leandro Ribeiro <leandro.ribeiro@collabora.com>

Manuel Stoeckl authored 3 years ago and Marius Vlad committed 3 years ago

Constraining the buffer size of an EGLConfig to 32 means that
the sum of red, green, blue, and alpha channels must equal 32.
This constraint prevented weston-simple-egl from picking an
RGBX pixel format when an opaque surface was asked for, since
the typical RGBX pixel formats have buffer sizes of 30, 24,
and 16.

Signed-off-by: Manuel Stoeckl <code@mstoeckl.com>

Daniel Stone authored 3 years ago and Marius Vlad committed 3 years ago

Now Debian 11 (Bullseye) has been released, shift our CI builds to using
that instead of the older Buster.

Due to dependency-chain changes, we have to install a lot more packages
explicitly and retain more at runtime. This is exacerbated by pkg-config
now requiring the entire chain to be installed, not just the immediate
dependencies.

Our documentation toolchain also gets bumped to a higher version to deal
with Doxygen changes.

Signed-off-by: Daniel Stone <daniels@collabora.com>

Daniel Stone authored 3 years ago and Marius Vlad committed 3 years ago

Older kernels cannot be built and booted with GCC 10+, as included in
Debian bullseye, due to unfortunate stack-canary issues:
    https://lore.kernel.org/lkml/20200314164451.346497-1-slyfox@gentoo.org/T/



Upgrade to the last-released kernel, 5.14, to fix this.

Signed-off-by: Daniel Stone <daniels@collabora.com>

Daniel Stone authored 3 years ago and Marius Vlad committed 3 years ago

Rather than aliasing it with our existing 'pipewire' directory.

Signed-off-by: Daniel Stone <daniels@collabora.com>

Daniel Stone authored 3 years ago and Marius Vlad committed 3 years ago

We don't need to keep it around.

Signed-off-by: Daniel Stone <daniels@collabora.com>

Errors happening to devices being added or removed shouldn't fail
silently so exit if any of that happens.

Sprinkle some debug logs for other cases as well.

Signed-off-by: Marius Vlad <marius.vlad@collabora.com>
Suggested-by: Daniel Stone <daniel.stone@collabora.com>

Marius Vlad authored 3 years ago and Pekka Paalanen committed 3 years ago

Starting with commit 'desktop-shell: Embed keyboard focus handle code
when activating' we are iterating over all the seats when removing a
weston_desktop_surface to be able to invalidate the activate surface.

Upon compositor tear down the shell destroy might invalidate seats
before removal of the weston_desktop_surface making the shell_seat
itself invalid. This wasn't apparent at that time because we're not
handling at that the removal of surfaces from layers.

Signed-off-by: Marius Vlad <marius.vlad@collabora.com>

Pekka Paalanen authored 3 years ago and Pekka Paalanen committed 3 years ago

This adds "icc_profile" key support in [output] sections for backends
headless, x11, wayland, and drm, and also for remoted and pipewire
outputs FWIW. On the other hand, RDP-backend does not use output
sections from weston.ini, and fbdev-backend does not deserve anything
new (it wouldn't support color management anyway due to no GL-renderer).

This allows one to configure an ICC v2 or v4 file to be used as an
output profile. However, color-lcms does not actually use output
profiles yet, so trying this will fail until support is implemented.

The parent_winsys_profile argument is reserved for using the color
profile from a parent window system where applicable, if nothing else is
set in weston.ini. None of the nested backends provide an output color
profile yet. It is more of a reminder of a missing feature than a
serious implementation.

Note: cms-static Weston plugin uses the exact same weston.ini key for
loading VCGT from ICC profiles. If "color-management" option is set to
false, this new use of "icc_profile" is disabled and the old behavior
with cms-static is kept.

Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.com>

Pekka Paalanen authored 3 years ago and Pekka Paalanen committed 3 years ago

Add API to set an output's color profile. This new function can also be
called while the output is enabled. This allows changing the output
color profile even at runtime if desired.

color-noop has no way of creating weston_color_profile objects, so it
just asserts that no color profile is set.

color-lcms does not yet implement taking the output color profile into
account, so for now it just fails everything if a profile is set.

weston_surface_color_transform_fini() was previously used only prior to
freeing the struct, but now it is used also to just clear the struct,
hence it needs to reset the fields.

Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.com>

Pekka Paalanen authored 3 years ago and Pekka Paalanen committed 3 years ago

Move the code into a new function that either succeeds in setting all
the color transformations or does not change anything. This will be
useful when implementing output color profiles changes while the output
is enabled.

Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.com>

Pekka Paalanen authored 3 years ago and Pekka Paalanen committed 3 years ago

This function will be useful for Weston to load output ICC profiles from
weston.ini.

Co-authored-by: Sebastian Wick <sebastian@sebastianwick.net>
Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.com>

Pekka Paalanen authored 3 years ago and Pekka Paalanen committed 3 years ago

Roughly speaking, a color profile describes the color space of content
or an output. Under the hood, the description includes one or more ways
to map colors between the profile space and some standard profile
connecting space (PCS).

This object is not called a color space. A color space has a unique
definition, while a color profile may contain multiple different
mappings depending on render intent. Some of these mappings may be
subjective, with an artistic touch.

When a source color profile and a destination color profile are combined
under a specific render intent, they produce a color transformation.
Color transformations are already preresented by weston_color_transform.

This patch adds the basic API for color profile objects. Everything
worthwhile of these objects is implemented in the color managers:
color-noop never creates these, and in color-lcms they are basically a
container for cmsHPROFILE, the Little CMS object for color profiles.
Color profile objects will not be interpreted outside of the color
managers, unlike color transformations.

For a start, the color manager API has one function to create color
profiles: from ICC profile data. More creation functions for other
sources will be added later.

The API has errmsg return parameter for error messages. These are not
simply weston_log()'d, because CM&HDR protocol will allow clients to
trigger errors and the protocol handles that gracefully. Therefore
instead of flooding the compositor logs, the error messages will
probably need to be relayed back to clients.

Color-lcms is expected to create a cmsHPROFILE for all kinds of color
profiles, not just for those created from ICC profile data. Hence,
color-lcms will fingerprint color profiles by the MD5 hash which Little
CMS computes for us. The fingerprint is used for de-duplication: instead
of creating copies, reference existing color profiles.

This code is very much based on Sebastian Wick's earlier work on Weston
color management, but structured and named differently.

Co-authored-by: Sebastian Wick <sebastian@sebastianwick.net>
Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.com>

Takuro Ashie authored 3 years ago and Marius Vlad committed 3 years ago

It will cause on following situation:

* Enable weston-simple-im
  * It's also reproducible with IBus or Fcitx5
* Connect a mouse or a touch panel
* Don't connect keyboad
* Launch weston-editor and touch the text area

It doesn't reproduce with weston-keyboard because it doesn't use
grab_keyboard of input-method-context-v1.

Signed-off-by: Takuro Ashie <ashie@clear-code.com>

Alyssa Ross authored 3 years ago and Marius Vlad committed 3 years ago

The "sans" and "mono" aliases for "sans-serif" and "monospace" are
deprecated[1].  Let's standardize on the non-deprecated versions, which were
already in use in some places.

[1]: https://gitlab.freedesktop.org/fontconfig/fontconfig/-/blob/be453bd1590b545d490aa024ef267948419b4d3a/fonts.conf.in#L33-67



Signed-off-by: Alyssa Ross <hi@alyssa.is>

Alyssa Ross authored 3 years ago and Marius Vlad committed 3 years ago

When trying to get Weston to run on a new system I was building up bit
by bit, I encountered a problem: when I started weston-terminal, it
would close a split second later.  This turned out to be because
weston-terminal defaults to trying to spawn /bin/bash, which my
busybox-based system didn't have.

I can configure the terminal to use a shell I do have, of course, but I
think /bin/sh is a much friendlier default, because it's more likely to
exist (POSIX requires it), and will save people just trying to get
started with Weston from the confusing experience I had.  I think it's
better overall that somebody who specifically wants /bin/bash has to
configure that (if they even have to — depending on how they're running
Weston, $SHELL might already be /bin/bash) than somebody who just wants
to see the terminal working debug why it won't launch at all.

I realise there might be a (small) backward compatibility concern here
as well, but I hope I've made the case for a friendlier default.

Signed-off-by: Alyssa Ross <hi@alyssa.is>

Simon Ser authored 3 years ago and Pekka Paalanen committed 3 years ago

The doc website is currently hidden in the Wayland homepage. Add
an explicit link in the README.

While at it, rename the section about documentation. "Weston" is
already in the repository name and the top oif the README, so no
need to repeat here.

Signed-off-by: Simon Ser <contact@emersion.fr>

No functional change. Moved color processing
functions into shared files which can be used
between different tests.

Signed-off-by: Vitaly Prosyak <vitaly.prosyak@amd.com>

The seat_cap listener was to register a signal for keyboard_focus, which
we no longer use. Remove it entirely to avoid dead code.

Signed-off-by: Marius Vlad <marius.vlad@collabora.com>
Suggested-by: Derek Foreman <derek.foreman@collabora.com>

As kiosk-shell can't cope with multiple seat add a warning and avoid
creating any new seats. With it, this guards against potentially
receiving an invalid seat.

Signed-off-by: Marius Vlad <marius.vlad@collabora.com>

With the seperation of surface activation and keyboard input, a special
corner case arose for child top-level windows when surfaces are being
destroyed. To make sure we never pick the wrong window to activate upon
destruction, we verify if the current focused surface is different than
the one being destroyed.

Signed-off-by: Marius Vlad <marius.vlad@collabora.com>

Just like desktop-shell, we shouldn't be dependent on having a keyboard
be present in order to activate a window/surface.

This adds a libweston helper to retrieve the first available seat, and
to use it in order to avoid going over the seat list.

We also encapsulate the activation of the surface in one place, and use
it on surface removal, when the surface has been committed, or for
touch/pointer events. With it we also deal with the keyboard focus and
shell activation in one place.

Signed-off-by: Marius Vlad <marius.vlad@collabora.com>

These formats will be eventually be useful for color managed clients
using wl_shm that wish to submit buffers encoding high dynamic range
images.

While the minimum requirement for linearly filterable half float
textures is GL ES 2.0 + GL_OES_texture_half_float_linear, to keep
the code simple, this commit only enables the new formats when
the requirements for color management (notably including GL ES 3.0
and GL_EXT_color_buffer_half_float) are available.

Signed-off-by: Manuel Stoeckl <code@mstoeckl.com>

This fixes the tear-down and the destroying part in case RDP back-end
couldn't be initialized. The first issue is the rdp_output which will
not be created in some circumstances (can't open the socket for
instance) and requires a guard check, and secondly, the
rdp_head being created above of that, wasn't removed and tripped an
assert when destroying the compositor instance.

Signed-off-by: Marius Vlad <marius.vlad@collabora.com>

Attempting to perform a switch on a surface (already) closed will trip
the assert in activate(), so check if we have a weston_desktop_surface
before trying to activate it.

Fixes #543

Signed-off-by: Marius Vlad <marius.vlad@collabora.com>

Nothing special, but allows scene-graph to display surface labels.

Signed-off-by: Marius Vlad <marius.vlad@collabora.com>

Incidentally fixes #553

Signed-off-by: Marius Vlad <marius.vlad@collabora.com>

Group common functions found in both kiosk-shell and deskop-shell to
a shared utils file.

Signed-off-by: Marius Vlad <marius.vlad@collabora.com>

This way, we try to differentiate between input focus and window/surface
activation.

Signed-off-by: Marius Vlad <marius.vlad@collabora.com>

We no longer make use of the keyboard_focus_listener so remove it
entirely.

Signed-off-by: Marius Vlad <marius.vlad@collabora.com>
Suggested-by: Derek Foreman <derek.foreman@collabora.com>

We shouldn't be constrained by having a keyboard plugged-in, so avoid
activating/de-activating the window/surface in the keyboard focus
handler and embed it straight into the window activation part.

Signed-off-by: Marius Vlad <marius.vlad@collabora.com>

This way it better reflects that it handles activation rather that input
focus.

Signed-off-by: Marius Vlad <marius.vlad@collabora.com>