Commits on Source (18)
-
Daniel Stone authoredWe could overflow a local buffer if there were more than ten million concurrently active displays within the current user's session. This seems vanishingly unlikely, and harmless, but does at least squash a compiler warning emitted by gcc 12+. Signed-off-by:Daniel Stone <daniels@collabora.com>
f48cf18a -
Daniel Stone authored
XYUV8888 support was added to gl-renderer in 30104bd8, but not to pixel-formats. Oops. Signed-off-by:
c8a2fb7a -
Daniel Stone authored
desktop_shell_removed() won't get called when we shut down, so explicitly destroy the fullscreen black view. Signed-off-by:7059ec78 -
Daniel Stone authored
create_solid_color_surface actually returns a weston_view that it creates internally. Since weston_solid_color_view is long and dull, rename it to weston_curtain. Signed-off-by:b77c2374 -
Daniel Stone authored
The name implied that it was a surface in and of itself, rather than parameters used by a helper to create a surface and view. Rename it now that we have weston_curtain as a name, and clean up initialisers. Signed-off-by:3a298b0b -
Daniel Stone authored
Given that we have a struct for argument params, we might as well use it rather than have them split between the struct and native params. For consistency between the implementations, this also includes a shift from float to int positioning for the base offset within the compositor's global co-ordinate space. Signed-off-by:d2156336 -
Daniel Stone authored
Not all solid-colour views want to be opaque: sometimes we use them with non-opaque alpha values in order to shade views underneath them. Signed-off-by:e81b8d7c -
Daniel Stone authored
Opaque regions are in surface co-ordinate space, not global co-ordinate space, so the region should be anchored to (0,0). Signed-off-by:791e8b1c -
Daniel Stone authored
Dirtying the geometry only sets a flag on the view saying that the geometry is dirty, so we don't need to do it twice back-to-back. Signed-off-by:de0cd532 -
Daniel Stone authored
Rationalise it a little bit so we don't need pre-declarations of static functions, and the order of creation more closely matches the others, including making the same calls to explicitly set the output. Doing this makes the behaviour match the other users of the same code pattern. In making them the same, we make desktop-shell code a little less magically divergent where people might wonder what the correct pattern is to use. After we have moved all users to a uniform pattern, later commits are then able to migrate these users to common helper code, which reduces code duplication, improves code clarity as it is no longer necessary to wonder about the exact semantics of every special-case user of this common pattern, and makes it easier to make interface changes which improve and clarify the patterns which are prevalent throughout the desktop-shell code. Signed-off-by:64ef8755 -
Daniel Stone authored
desktop-shell's focus surfaces want to reuse this, but they don't want to capture the input, instead allowing it to fall through. Signed-off-by:bd9b0676 -
Daniel Stone authored
Just as we do for fullscreen backgrounds, reuse the curtain infrastructure for focus animations. This introduces a small functional change, in that the surface's output is no longer directly assigned. Instead, we call weston_view_set_output() ourselves. As setting the weston_view's position (done from the common helper function of weston_curtain_create which has been introduced in previous commits) will call weston_view_set_position(), the view's geometry will be dirtied as a result. When the geometry of a weston_view is dirty, it is marked to be updated, which will occur whilst traversing the view list during output repaint. This occurs for every view which is currently assigned to a layer; when building the view list, any view reachable through the view list whose geometry is dirty will have its position recalculated and an output assigned. Doing so results in the surface's current output being updated. It is believed that there is no functional impact from the weston_surface not having a primary output assigned between creation and output repaint being called. Signed-off-by:e031397e -
Daniel Stone authored
This will allow us to create a solid weston_buffer as well, since we need to store that separately. Signed-off-by:dc0f73bc -
Daniel Stone authored
Use the common infrastructure we have, rather than open-coding again. In changing to the common weston_curtain infrastructure which was introduced in a previous commit, there are two small functional derivations. After adding the view to a layer, we explicitly call weston_view_geometry_dirty(). This is believed to have no functional impact, as weston_views have their geometry-dirty flag set when they are created. weston_surface_damage() is also called to ensure that the surface is scheduled for a repaint. As there is currently no good common mechanic in the common code to ensure that output repaint will occur, due to the damage propagating outwards from the weston_surface, we are forced to call this to predictably ensure that the output will be repainted after we have made this change to the scene graph which should result in the user observing the new content being repainted. It is possible that these changes are not strictly required in order for the correct behaviour to occur. However, it is felt that explicitly adding these calls is perhaps the least fragile way to ensure that the behaviour continues to be correct and breakage is not observed, especially with both view mapping and surface damage identified as areas for future work which could be beneficial to Weston. If it is felt that these calls can be removed, then this is certainly possible at a later stage. Lastly, there are many users within desktop-shell of the common pattern of creating a weston_curtain and inserting it into the scene graph to be painted. These users have been an area of both theoretical concern and real-life observed fragility and breakage recently. By making each user follow a common and predictable pattern of usage, each user is no longer its own special case. This should make it easier to make the desktop-shell codebase more robust, not only simplifying the codebase, but improving observed behaviour. In doing this, it is hoped that future structural and interface changes become easier to make, allowing us to improve some of the more difficult corners of the libweston API. Signed-off-by:15a55305 -
Daniel Stone authored
shell-utils contains a number of helpers which are currently in use by both desktop-shell and kiosk-shell. In order to extend this use to fullscreen-shell as well (which can benefit from reusing the weston_curtain infrastructure to be able to create solid-colour views which may or may not be opaque, as well as one function within fullscreen-shell which was copied wholesale to shell-utils), we need to create a separate Meson dependency object, and avoid the existing pattern of including the source from shared/ within the source list for each shell. This requires creating a new top-level directory for these shared helper functions which are required by each shell, but are not part of libweston in and of itself. shell-utils depends on libweston-desktop; libweston-desktop depends on libweston; libweston depends on shared. Thus it is not possible to expose a dependency object from the shared/ directory which declares a dependency on the libweston-desktop dependency, as Meson processes directories in order and resolves variable references as they are parsed. In order to break this deadlock, this commit creates a new top-level directory called 'shell-utils' containing only this file, which can be parsed by Meson after libweston-desktop (making the libweston-desktop Meson dependency variable available to the build file to declare a dependency on that), but before the shells (making the new Meson depenendency object available to each shell which wishes to use it). This commit contains no functional changes to any observable code. Signed-off-by:6cb2526b -
Daniel Stone authored
Use the helper we have for these, rather than open-coding. This commit is not believed to result in any functional changes. Signed-off-by:577a832f -
Daniel Stone authored
Unlike desktop-shell and kiosk-shell, the fullscreen-shell does not link with the common shell-utils helpers. This is largely because fullscreen-shell is largely in 'maintenance mode', seeing little more than occasional bug fixes or changes required to accommodate new interfaces. This commit adds a dependency from fullscreen-shell to use the shell-utils helper, in order to allow fullscreen-shell to use the new weston_curtain infrastructure, rather than continuing to open-code the common pattern of creating a surface and view consisting only of a solid colour for the background of fullscreen surfaces which do not wholly cover the output. In doing this, the 'surface_subsurfaces_boundingbox()' function is removed, as this has been duplicated between the fullscreen-shell and the common helper 'library'. There is no functional change within this commit, as the two functions were identical, other than a change to the comment which identifies a known bug within this helper. Signed-off-by:b94d69b9 -
Daniel Stone authored
Use the common helper provided by the shell-utils helper dependency, rather than rolling our own. This commit currently introduces no functional change to fullscreen-shell, as the 'curtain' provided by shell-utils behaves identically to the previous solid-color surface created by fullscreen-shell, given the parameters provided to weston_curtain_create(). However, now that a common weston_curtain implementation is being used rather than an open-coded variant, future changes to the implementation of weston_curtain will result in changes to this code called by fullscreen-shell, although it is intended that these will not result in any user-visible behavioural changes. Signed-off-by:c3415aed
shell-utils/meson.build
0 → 100644