- Sep 17, 2018
-
-
This is better than running Weston with WAYLAND_DEBUG=server: - It is enabled on demand, no unnecessary flooding and no need to restart the compositor if debug was enabled. - It prints client pointers so that messages with different clients can be seen apart. Signed-off-by:
Pekka Paalanen <pq@iki.fi> parse and print message arguments in protocol_log_fn Signed-off-by:
Maniraj Devadoss <Maniraj.Devadoss@in.bosch.com> Reviewed-by:
Pekka Paalanen <pekka.paalanen@collabora.co.uk> Reviewed-by:
Daniel Stone <daniels@collabora.com>
-
Instead of a compile time choice, offer the XWM debugging messages through the weston-debug protocol and tool on demand. Users will not need to recompile weston to get XWM debugging, and it won't flood the weston log. The debug scope needs to be initialized in launcher.c for it be available from start, before the first X11 client tries to connect and initializes XWM. Signed-off-by:
-
This is preparation for using the weston-debug infrastructure for WM_DEBUG. dump_property() may be called from different debugging contexts and often needs to be prefixed with more information. An alternative to this patch would be to pass in the weston_debug_scope as an argument to dump_property(), but then all callers would need to be converted to weston-debug infra in a single commit. Therefore require the callers to provide the FILE* to print to. Signed-off-by:
-
Write the output of dump_property() out in one log call. When multiple processes (weston and Xwayland) are writing to the same file, this will keep the property dump uninterrupted by Xwayland debug prints. This is also preparation for more development in the same direction. Signed-off-by:
-
This registers a new weston-debug scope "log" through which one can get live log output interspersed with possible other debugging prints. This is implemented by passing the format and varargs received in our usual logging entrypoints through to the debug scope as well. Anywhere where the varargs set is used twice (once for vfprintf, another for the debug scope), we copy the va_list in order to avoid reusing it, which leads to memory safety issues. Signed-off-by:
-
A tool for accessing the zcompositor_debug_v1 interface features. Installed along weston-info, because it should be potentially useful for people running libweston-based compositors. Signed-off-by:
Emre Ucan <eucan@de.adit-jv.com>
-
Let users enable the compositor debug protocol on the compositor command line. This allows weston-debug tool to work. Signed-off-by:
-
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:
-
- Sep 11, 2018
-
-
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:
-
- Aug 31, 2018
-
-
Matteo Valdina authoredThis fix a crash, when gl-renderer uploads the 2^ texture for YUYV. The pixels buffer was offset of a random value.
-
- Aug 28, 2018
-
-
Daniel Stone authoredAttempt to answer the question on everyone's lips. Signed-off-by:
-
- Aug 27, 2018
-
-
Change format of substituted variables to follow the pattern used by configure_file() in Meson. This helps the migration to Meson, making man/meson.build much cleaner. Signed-off-by:
-
- Aug 24, 2018
-
-
Derek Foreman authored
-
-
- Aug 20, 2018
-
-
Stefan Agner authored
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>
-
- Aug 17, 2018
-
-
-
Derek Foreman authored
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: -
Derek Foreman authored
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:
-
- Aug 10, 2018
-
-
-
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:
-
- Aug 08, 2018
-
-
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:
-
- Aug 07, 2018
-
-
Will Thompson authored
* 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>
-
Daniel Stone authored
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:
Quentin Glidic <sardemff7+git@sardemff7.net> Reviewed-by:
-
Daniel Stone authored
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:
-
- Aug 06, 2018
-
-
Daniel Stone authored
Change some Wayland-specific references to instead refer to Weston. Signed-off-by:
-
Taken from Pekka's wayland/wayland@630c25f4 and follow-ups, use Wayland's CONTRIBUTING document as a basis for Weston. Signed-off-by:
-
- Jul 27, 2018
-
-
-
Daniel Stone authored
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:
Derek Foreman <derek.foreman.samsung@gmail.com>
-
Daniel Stone authored
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 authored
The backend begins with a series of #defines of libdrm tokens, in case the libdrm we build against is too old. Commit efdebbc4 ("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:
-
- Jul 22, 2018
-
-
Happened mostly with neovim's xclip usage. [daniels: Added more cases.] Reviewed-by: -
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:
Emil Velikov <emil.velikov@collabora.com> Reviewed-by:
-
If compositor wakes up from sleep state, we have to trigger repaint for all outputs. Signed-off-by:
-
- Jul 13, 2018
-
-
-
Just rely on getting the supported formats through the dmabuf extension. Signed-off-by:
Emilio Pozuelo Monfort <emilio.pozuelo@collabora.co.uk> Reviewed-by:
-
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:
-
- Jul 11, 2018
-
-
Daniel Stone authored
Now that we can sensibly test proposed plane configurations with atomic, sprites are not broken. Signed-off-by:
-
Daniel Stone authored
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 authored
a0f8276f ("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 authored
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:
-
