Weston extension to assure clients that the dmabuf buffer will be
forwarded directly to the display controller.
Signed-off-by: Marius Vlad <marius.vlad@collabora.com>
This comment was added in 230f3b1bf8 with the
intent that if we had an information table about pixel formats (which we do
have today), we could implement more sanity checks like ensuring that width
pixels fit into stride.
Daniel Vetter said on #dri-devel IRC recently:
< danvet> since userspace shouldn't look at stride for buffers with
modifiers, only pass it around unchanged
I asked for clarification. It was expected that userspace would not do any kind
of sanity checks as modifiers could change everything.
Let's remove the misleading code comment so that people don't get the idea of
adding more well-intended but ill-advised sanity checks. If more checks are
added, they must take the modifier into account, which the existing checks do
not do.
After 5 years, it is far too late to remove our existing sanity checks, but we
can attempt to not cause any more damage that would restrict what people can do
in the kernel.
Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.com>
Increase the buf size such it can accomodate sufficiently large local
buffers. Spotted whilst looking for something else.
../compositor/main.c:157:22: warning: ‘%s’ directive output may be
truncated writing up to 511 bytes into a region of size 128
[-Wformat-truncation=]
157 | snprintf(buf, len, "%s[%s.%03li]", datestr,
| ^~ ~~~~~~~
../compositor/main.c:157:21: note: directive argument in the range
[-9223372036854775, 9223372036854775]
157 | snprintf(buf, len, "%s[%s.%03li]", datestr,
| ^~~~~~~~~~~~~~
../compositor/main.c:157:2: note: ‘snprintf’ output between 7 and 659
bytes into a destination of size 128
157 | snprintf(buf, len, "%s[%s.%03li]", datestr,
| ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
158 | timestr, (tv.tv_usec / 1000));
| ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Signed-off-by: Marius Vlad <marius.vlad@collabora.com>
It makes much more sense to be there. It adds some additional drm_debug()
statements to provide reason for failing to place the view in the HW
plane. Makes the reason for failing more accurate.
Signed-off-by: Marius Vlad <marius.vlad@collabora.com>
Suggested-by: Daniel Stone <daniel.stone@collabora.com>
Avoids the need to retrieve the DRM framebuffer in each function and
re-uses the one got before constructing the zpos candidate list.
Takes another reference for the scanout as to live the state, like
there's one for the overlay bit.
Signed-off-by: Marius Vlad <marius.vlad@collabora.com>
As we already have a potential plane available to use, pass it
over the _prepare_overlay_view instead of trying to find one
from the backend plane list.
Signed-off-by: Marius Vlad <marius.vlad@collabora.com>
Suggested-by: Daniel Stone <daniel.stone@collabora.com>
In this manner we will allow views to reach the overlay (or underlays)
even if the damage tracking will detect that the new view will
occlude the view underneath it.
Renames occluded_region to planes_region, and uses occluded_region
to represent the region where we add each view's visible-and-opaque region.
Sprinkle some comments about each region.
Re-uses the view's clipped region to determine visible-and-opaque region
which is accumulated (for both renderer and HW planes cases) into
occluded_region. The current view's clipped_region is then checked against
occluded_region.
Signed-off-by: Marius Vlad <marius.vlad@collabora.com>
Suggested-by: Daniel Stone <daniel.stone@collabora.com>
We can determine if the pixel format used by the clients buffer is
scan-out capable much sooner, so do it when constructing the zpos
candidate list. It also removes the checks in their respective
prepare_ functions.
Avoids the situation where we'd need to retrieve the DRM framebuffer each time
when checking the pixel format.
Signed-off-by: Marius Vlad <marius.vlad@collabora.com>
function
The idea is to place pixel the format checks in a common part and until
then, to make it available as a function so we can re-use easily.
Signed-off-by: Marius Vlad <marius.vlad@collabora.com>
In order to better optimize view assignment to HW planes, we construct
an intermediary zpos candidate list which is used aggregate all suitable
planes for handling scan-out capable client buffers.
We go over it twice: once to construct it and once to pick-and-choose a
suitable plane based its highest zpos position.
In order to maintain the view order correctly we track current zpos
value being applied to the plane state and use it when trying to place
a view into a plane.
Pass the computed zpos value to be applied to the plane state.
Signed-off-by: Marius Vlad <marius.vlad@collabora.com>
Suggested-by: Daniel Stone <daniel.stone@collabora.com>
This is based on the assumption that overlays are in between cursor and
primary plane and it is required to be able to assign views to planes,
even if the driver doesn't not expose such property.
As we hard-code them as immutable the commit part would not need any
further modifications.
Signed-off-by: Marius Vlad <marius.vlad@collabora.com>
Suggested-by: Daniel Stone <daniel.stone@collabora.com>
Functional no change, as nobody makes use of it. Only apply the zpos
value if the zpos property is mutable (that is, zpos_max and zpos_min
are not the same).
Signed-off-by: Marius Vlad <marius.vlad@collabora.com>
Due to an error in driving GitLab, this commit erroneously contained the
entirety of !267 (zpos support in the KMS backend) squashed into one
single commit, pushed into master.
In order to keep the history clean, this is being reverted; a rebased
version of !267 with the clear individual commits which were already
present will be applied in its place.
This reverts commit 95e3b0deae.
The remoting plugin currently has a set_gbm_format() hook, which accepts
GBM_FORMAT_* tokens from the host to set as a supported format.
GBM_FORMAT_* values are strictly aliased with DRM_FORMAT_*.
In order to avoid an extra unnecessary dependency from the remoting
plugin on GBM, switch to using the formats from libdrm instead.
This fixes a compile error seen when the remoting plugin is enabled:
../remoting/remoting-plugin.c:39:10: fatal error: gbm.h: No such file or directory
39 | #include <gbm.h>
| ^~~~~~~
compilation terminated.
The error was caused by not having any dependency at all on GBM from
the remoting backend, which is fixed here by adding a new dependency on
the libdrm headers for drm_fourcc.h.
Signed-off-by: Daniel Stone <daniels@collabora.com>
Use exec to make sure the direct child process of weston-launch is
weston. This makes sure that signal delivery (SIGINT/SIGTERM) is
properly forwarded to weston.
Fixes ff3230952a ("weston-launch: Run weston in the user login shell")
Signed-off-by: Stefan Agner <stefan@agner.ch>
pending subscription
It limits to scope name to an exact match.
Signed-off-by: Marius Vlad <marius.vlad@collabora.com>
Reported-by: Pekka Paalanen <pekka.paalanen@collabora.com>
This fixes the situation where the same logger scope is passed multiple
times and the timestamp is being sent before the log mesasge.
Signed-off-by: Marius Vlad <marius.vlad@collabora.com>
Reported-by: Pekka Paalanen <pekka.paalanen@collabora.com>
timeline subscription
When subscribing over the command line to the 'timeline' scope we hit
the situation where we could emit a timeline message but without the
weston_output object being (fully) enabled. The timeline subscription
object requires to install its own callback on the 'destroy_signal' but
at that time, the 'destroy_signal' is not initialized.
This moves 'destroy_signal' initialization before timeline has a chance
to emit a timeline subscription message for that weston_output.
While at it, move also 'frame_signal' initialization before any function
call to keep them nicely organized.
Signed-off-by: Marius Vlad <marius.vlad@collabora.com>
This wasn't intentional it just kept the way it was done before.
Signed-off-by: Marius Vlad <marius.vlad@collabora.com>
Reported-by: Pekka Paalanen <pekka.paalanen@collabora.com>
Since version 7 clients must use MAP_PRIVATE to map the keymap fd so we
can use memfd_create in os_ro_anonymous_file_get_ref using
RO_ANONYMOUS_FILE_MAPMODE_PRIVATE, for older version we use
RO_ANONYMOUS_FILE_MAPMODE_SHARED to be compatibile with MAP_SHARED.
Signed-off-by: Sebastian Wick <sebastian@sebastianwick.net>
New in version 6 are touch shape, touch orientation and axis source
wheel tilt. Weston doesn't support any of them yet but simply not
sending the new events and new enum value is sufficient to claim to
support this version.
Also bump the Wayland requirement to 1.17 to ensure both version 6 and 7
definitions are in the XML.
The reason for bumping to v6 without implementing the new features is
that we must support v7 to make use of struct ro_anonymous_file
introduced in the previous commit.
Signed-off-by: Sebastian Wick <sebastian@sebastianwick.net>
The next commit bumps the required Wayland version beyond what the repo
version supports.
Build wayland 1.17 into the docker image.
Signed-off-by: Sebastian Wick <sebastian@sebastianwick.net>
The ro_anonymous_file is an abstraction around anonymous read-only files.
os_ro_anonymous_file_create creates such a file with the contents passed
in data. Subsequent calls to os_ro_anonymous_file_get_fd return a fd
that's ready to be send over the socket.
When mapmode is RO_ANONYMOUS_FILE_MAPMODE_PRIVATE the fd is only
guaranteed to be mmap-able readonly with MAP_PRIVATE but does not
require duplicating the file for each resource when memfd_create is
available. RO_ANONYMOUS_FILE_MAPMODE_SHARED may be used when the client
must be able to map the file with MAP_SHARED but it also means that the
file has to be duplicated even when memfd_create is available.
See also:
weston commit 76829fc4ea
wayland commit 905c0a341ddf0a885811d19e2b79c65a3f1d210c
Signed-off-by: Sebastian Wick <sebastian@sebastianwick.net>
Make GBM optional in case GL renderer is disabled. This allows to
build Weston with DRM backend without Mesa dependencies.
Signed-off-by: Stefan Agner <stefan@agner.ch>
Move DRM virtual support into a separate file. Use the remoting
compile time option to disable DRM virtual support since this is the
only user of DRM virtual support currently. This will make it easier
to build the DRM backend without GBM support.
Signed-off-by: Stefan Agner <stefan@agner.ch>
The remoting plug-in requires DRM virtual support which depends on
the GL renderer. Make sure the option is enabled.
Signed-off-by: Stefan Agner <stefan@agner.ch>
Now that all cases of unresolved symbols have been either fixed or worked
around pending for a proper fix, we can switch the project to disallow
unresolved symbols during build. This will help catch programming mistakes
earlier.
Note, that existing Meson build directories will not automatically apply this
change. If you have an existing build directory, you must issue
meson configure -Db_lundef=true
in it.
Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.com>
surface-screenshot-test.c uses file_create_dated() provided by libshared, so it
needs to link libshared.
This was not a problem when unresolved symbols during build were allowed and
the symbols was provided by the weston executable which accidentally exported
all libshared symbols. This would become a problem when we disallow unresolved
symbols project-wide, so fix it.
Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.com>
All these plugins use symbols that were exported by the weston executable and
are now exported by libexec-weston.so. Linking these to libexec-weston.so fixes
unresolved symbols.
Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.com>
This is preparation for disallowing unresolved symbols project-wide.
This is a temporary fix that should be reverted and fixed properly later.
/usr/bin/ld: libweston/backend-rdp/13a5658@@rdp-backend@sha/rdp.c.o: in function `rdp_peer_context_new':
/home/pq/build/weston-meson/../../git/weston/libweston/backend-rdp/rdp.c:748: undefined reference to `Stream_New'
/usr/bin/ld: libweston/backend-rdp/13a5658@@rdp-backend@sha/rdp.c.o: in function `rdp_peer_context_free':
/home/pq/build/weston-meson/../../git/weston/libweston/backend-rdp/rdp.c:781: undefined reference to `Stream_Free'
/usr/bin/ld: libweston/backend-rdp/13a5658@@rdp-backend@sha/rdp.c.o: in function `xf_input_keyboard_event':
/home/pq/build/weston-meson/../../git/weston/libweston/backend-rdp/rdp.c:1220: undefined reference to `GetVirtualKeyCodeFromVirtualScanCode'
/usr/bin/ld: /home/pq/build/weston-meson/../../git/weston/libweston/backend-rdp/rdp.c:1224: undefined reference to `GetKeycodeFromVirtualKeyCode'
/usr/bin/ld: libweston/backend-rdp/13a5658@@rdp-backend@sha/rdp.c.o: in function `weston_backend_init':
/home/pq/build/weston-meson/../../git/weston/libweston/backend-rdp/rdp.c:1469: undefined reference to `winpr_InitializeSSL'
See also #262
Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.com>
This is preparation for disallowing unresolved symbols project-wide.
This is a temporary fix that should be reverted and fixed properly later.
/usr/bin/ld: compositor/fb12c4d@@cms-colord@sha/cms-helper.c.o: in function `weston_cms_set_color_profile':
/home/pq/build/weston-meson/../../git/weston/compositor/cms-helper.c:79: undefined reference to `cmsReadTag'
/usr/bin/ld: /home/pq/build/weston-meson/../../git/weston/compositor/cms-helper.c:91: undefined reference to `cmsEvalToneCurveFloat'
/usr/bin/ld: /home/pq/build/weston-meson/../../git/weston/compositor/cms-helper.c:92: undefined reference to `cmsEvalToneCurveFloat'
/usr/bin/ld: /home/pq/build/weston-meson/../../git/weston/compositor/cms-helper.c:93: undefined reference to `cmsEvalToneCurveFloat'
/usr/bin/ld: compositor/fb12c4d@@cms-colord@sha/cms-helper.c.o: in function `weston_cms_destroy_profile':
/home/pq/build/weston-meson/../../git/weston/compositor/cms-helper.c:108: undefined reference to `cmsCloseProfile'
/usr/bin/ld: compositor/fb12c4d@@cms-colord@sha/cms-helper.c.o: in function `weston_cms_load_profile':
/home/pq/build/weston-meson/../../git/weston/compositor/cms-helper.c:131: undefined reference to `cmsOpenProfileFromFile'
See also #263
Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.com>
This takes everything that was in 'weston' the executable a turns it into
library. A new trivial 'weston' executable is written.
Creating the library will allow future improvements:
- we can link weston plugins against the library, meaning that they no longer
need unresolved symbols to be allowed during linking
- tests do not have to fork() and exec() 'weston', they can just link to the
library and call wet_main() after setting things up; this will help with
using a debugger
install_rpath is set so that we can install the library into weston's module
directory, away from the normal libraries in a system. This is one library we
do not intend for others to use.
The library has no stable ABI and is not versioned.
Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.com>
