weston merge requestshttps://gitlab.freedesktop.org/wayland/weston/-/merge_requests2024-02-22T03:35:46Zhttps://gitlab.freedesktop.org/wayland/weston/-/merge_requests/1457libweston: Cleanup output's animation list when removing it2024-02-22T03:35:46ZJeffyChenjeffy.chen@rock-chips.comlibweston: Cleanup output's animation list when removing itAvoid memory use-after-free when the animation try to delete itself
from an already freed list in it's destruction.
Signed-off-by: Jeffy Chen <jeffy.chen@rock-chips.com>Avoid memory use-after-free when the animation try to delete itself
from an already freed list in it's destruction.
Signed-off-by: Jeffy Chen <jeffy.chen@rock-chips.com>https://gitlab.freedesktop.org/wayland/weston/-/merge_requests/1449Draft: compositor: Don't lift planes out of scene graph entirely2024-01-29T15:05:28ZDerek ForemanDraft: compositor: Don't lift planes out of scene graph entirelyWhen reviewing !1258 I thought that some of that patch series could be much simpler if our pnode visibility calculations weren't per-plane.
I threw this together to see what global visibility in pnodes would look like, and am curious if...When reviewing !1258 I thought that some of that patch series could be much simpler if our pnode visibility calculations weren't per-plane.
I threw this together to see what global visibility in pnodes would look like, and am curious if anyone agrees/disagrees with my supposition that it's better to do damage when moving planes than to render damage that's fully occluded beneath them.
I think there's still room for more optimization. Translucent planes need not trigger additional redraw on move - this would clean up the mouse cursor? And we can perhaps take more care not to redraw under the still-occluded parts of opaque regions of planes.
This is not a bug fix, and it may introduce new damage tracking bugs. :)https://gitlab.freedesktop.org/wayland/weston/-/merge_requests/1400compositor: fix crash in xdg_output_manager_get_xdg_output after head removal2024-01-19T16:49:04ZArnaud Vraccompositor: fix crash in xdg_output_manager_get_xdg_output after head removalWhen a head is removed and destroyed, the associated wl_output resources user
data is reset to null.
When a client calls zxdg_output_manager_v1::get_xdg_output on a removed
wl_output (which the client might not be aware of yet), this co...When a head is removed and destroyed, the associated wl_output resources user
data is reset to null.
When a client calls zxdg_output_manager_v1::get_xdg_output on a removed
wl_output (which the client might not be aware of yet), this could trigger a
crash as the output resource would be assumed to still represent a valid head.https://gitlab.freedesktop.org/wayland/weston/-/merge_requests/1399compositor: fix crash when repaint fails with pending presentation feedback2024-02-15T13:35:00ZArnaud Vraccompositor: fix crash when repaint fails with pending presentation feedbackNext idle repaint will assert because repaint starts with a non-empty presentation feedback list for the output.Next idle repaint will assert because repaint starts with a non-empty presentation feedback list for the output.https://gitlab.freedesktop.org/wayland/weston/-/merge_requests/1195Add support for FreeBSD2023-04-17T11:23:54ZAudrey DutcherAdd support for FreeBSDConfigured as follows: `meson setup _build -Dsystemd=false -Dbackend-rdp=false -Dbackend-vnc=false -Dsimple-clients=damage,im,egl,shm,touch -Db_lundef=false`. There are _probably_ ways to get rdp/vnc support to compile on FreeBSD, but ju...Configured as follows: `meson setup _build -Dsystemd=false -Dbackend-rdp=false -Dbackend-vnc=false -Dsimple-clients=damage,im,egl,shm,touch -Db_lundef=false`. There are _probably_ ways to get rdp/vnc support to compile on FreeBSD, but just installing the appropriate packages from the default package manager did not satisfy meson :smile:
Not all testcases pass on FreeBSD, but I triaged the failures and I think they're all just due to my system configuration being bad (zfs not supporting posix_fallocate, etc).
I drove this for a bit with the drm backend and --use-pixman (my graphics driver is in a bad state so kms is a no-go, even for wlroots stuff). I encountered some segfaults, but I was stressing it pretty hard (monitor hotplug mostly).
If this is merged, I plan on submitting this to the FreeBSD package repository with no patches :grin: As this is my first contribution, please let me know if there are any issues!https://gitlab.freedesktop.org/wayland/weston/-/merge_requests/762libweston: Use weston_signal_emit_mutable for all destroy signals2023-10-05T13:52:42ZMarius Vladlibweston: Use weston_signal_emit_mutable for all destroy signalsA left over from our switch to weston_signal_emit_mutable().
Signed-off-by: Marius Vlad <marius.vlad@collabora.com>A left over from our switch to weston_signal_emit_mutable().
Signed-off-by: Marius Vlad <marius.vlad@collabora.com>14.0.0https://gitlab.freedesktop.org/wayland/weston/-/merge_requests/545WIP:RFC:improve weston_surface/view identification for debugging2023-04-06T08:15:18ZVeeresh Kadasaniveereshkadasani88@gmail.comWIP:RFC:improve weston_surface/view identification for debuggingissue :#334
This is work in progress based on inputs provided
in the issue. the code includes queries which will
be removed once clarified. I am creating this MR
to get some early comments and then parallely fix
along with the community...issue :#334
This is work in progress based on inputs provided
in the issue. the code includes queries which will
be removed once clarified. I am creating this MR
to get some early comments and then parallely fix
along with the community support.
Signed-off-by: Veeresh Kadasani <veeresh.kadasani@huawei.com>https://gitlab.freedesktop.org/wayland/weston/-/merge_requests/531Add Missing check for buffer size divisible by scale2022-05-06T19:38:12ZVeeresh Kadasaniveereshkadasani88@gmail.comAdd Missing check for buffer size divisible by scaleFixes: #367
wl_surface.attach specification says:
> "The new size of the surface is calculated based on the
> buffer size transformed by the inverse buffer_transform
> and the inverse buffer_scale. This means that the supplied
> buffer...Fixes: #367
wl_surface.attach specification says:
> "The new size of the surface is calculated based on the
> buffer size transformed by the inverse buffer_transform
> and the inverse buffer_scale. This means that the supplied
> buffer must be an integer multiple of the buffer_scale."
Since the specification is worded "must", this implements
the check in weston and raise a protocol error if the
requirement is violated. Note, that if wp_viewport is
used to explicitly set the destination size, then the
buffer size requirement is lifted.
Also adds test to check this error is raised.
when specification is violated.https://gitlab.freedesktop.org/wayland/weston/-/merge_requests/480Dynamic output orientation2024-02-01T10:20:09ZMarius VladDynamic output orientationThis is a follow-up work done by @linkmauve started quite a while back at [1].
The protocol has a few changes most noticeable being that it allows users to use the cmdline
to change the output besides using an IIO device. The design mo...This is a follow-up work done by @linkmauve started quite a while back at [1].
The protocol has a few changes most noticeable being that it allows users to use the cmdline
to change the output besides using an IIO device. The design mostly follows that of [1], the implementation
being a weston plug-in, as the IIO API doesn't have any poll reading mechanism, such that the compositor will
spawn the client to handle reading out data.
The IIO device reading sampling rate and channel names are there as well. ~~Some further
filtering might be necessary to smooth out rapid changes of the sensors/device and causes spurious
orientation changes.~~ Added now an additional 'cumulative_reads' reads which is used to control how many
reads should be taken. From there, it allows to retrieve the highest occurrance of the transform value, and passed on
as the 'proposed'/new transform value. Useful when the sampling rate is quite high.
I've tested it using an lsm6dsox IMU which contains multiple IIO devices, among the accelerometer required
here.
Supports desktop-shell and kiosk-shell. kiosk-shell patch shows that bits/pieces be needed to add rotator support in other shells.
/cc @afrantzis there's a small patch wrt configured fullscreen state which you've introduced a while back
/cc @linkmauve
[1] https://lists.freedesktop.org/archives/wayland-devel/2016-August/030396.htmlhttps://gitlab.freedesktop.org/wayland/weston/-/merge_requests/453libweston: Introduce weston-clock to support fake time2022-04-27T22:18:10ZAlexandros Frantzislibweston: Introduce weston-clock to support fake timeweston-clock is a component that abstracts time related functionality
and allows us to replace real time with fake time that can be controlled
by test clients.
On the server side we replace calls to relevant time related functions
with ...weston-clock is a component that abstracts time related functionality
and allows us to replace real time with fake time that can be controlled
by test clients.
On the server side we replace calls to relevant time related functions
with weston_clock_* functions. These functions use either real time (by default)
or fake time if configured to do so. On the compositor level this configuration
is performed with a weston_testsuite_quirks entry.
weston-clock uses the same fake time for all clocks, since we don't
have a current testing need for more independent clocks and it makes the code
simpler, but it's not hard to change this in the future if required.
weston-clock also provides the weston_clock internal protocol which can be
used by test clients to control the passage of time.
As an example of using fake time with weston-clock, presentation-test is updated
to use fake time and verify the presentation time returned from the presentation
feedback protocol. This verification requires knowledge of specific delays employed
by weston core and the headless backend, so a future improvement would be to configure
these parameters from within the test, to remove any such assumptions about the
code under test.
v2:
- Made weston-clock related state local/per-compositor, encapsulated in an opaque `struct weston_clock`
- Provided weston_compositor_* convenience functions for timers that wrap around the internal weston_clock.
- Changed client_advance_time() test helper function to use struct timespec.
- Added a more complex weston-clock test verifying correct behavior with a long chain of dependent events.
- Modified test infrastructure to provide the compositor in client tests, and used this feature to verify the compositor repaint state in presentation-test (see last two commits). If these modifications turn out to be a point of contention we may want to move them to a separate MR for further discussion.
v3:
- Use a weston_testsuite_quirks entry for configuring fake timehttps://gitlab.freedesktop.org/wayland/weston/-/merge_requests/450libweston: improve frame callback handling with surfaces on multiple outputs2023-10-02T10:46:54ZMichael Olbrichlibweston: improve frame callback handling with surfaces on multiple outputsRight now, the frame callback of a surface is handled when the output assigned
to the surface is repainted. With one view that spans multiple outputs, the
output with the largest area is chosen. For multiple views it depends on which
vie...Right now, the frame callback of a surface is handled when the output assigned
to the surface is repainted. With one view that spans multiple outputs, the
output with the largest area is chosen. For multiple views it depends on which
view changes last.
In either case, this can be a problem, when the outputs have different
framerates.
For example, there are two outputs, one with 30fps and another with 60fps.
The surface for an application is visible on both outputs. If the output with
30fps is 'selected' as the output for the surface, then the application may
produce only 30pfs even though the other output could show the full 60fps.
So handle the frame callbacks for all surfaces that are visible on an output,
not just those where the output is explicitly assigned.
Signed-off-by: Michael Olbrich <m.olbrich@pengutronix.de>https://gitlab.freedesktop.org/wayland/weston/-/merge_requests/426data-device: avoid duplicating data offer for the same client2021-04-27T17:46:06Zxichendata-device: avoid duplicating data offer for the same client`weston_data_source_send_offer` is called to create a new data offer every time
when the seat focuses a surface. This patch will evite create a new data offer
for the same client for the same source, it fixes the bug of #376, where the
d...`weston_data_source_send_offer` is called to create a new data offer every time
when the seat focuses a surface. This patch will evite create a new data offer
for the same client for the same source, it fixes the bug of #376, where the
data device duplicates data offers thus it never been pasted to firefox.
Closes #376
Signed-off-by: xichen zhou <sichem.zh@gmail.com>https://gitlab.freedesktop.org/wayland/weston/-/merge_requests/356RFC: Screenshot to DMA fd2021-07-31T14:26:06ZK J RajendraprasadRFC: Screenshot to DMA fdThe existing screenshot implementation makes use of glReadPixels and dumps the contents to a file.
This method seems to be less performant and cannot be used for the following:
1) 60 fps use case: As glReadPixels is not H/W accelerated,...The existing screenshot implementation makes use of glReadPixels and dumps the contents to a file.
This method seems to be less performant and cannot be used for the following:
1) 60 fps use case: As glReadPixels is not H/W accelerated, the current implementation takes more than
16.6 ms to generate a screenshot.
2) 3D animations between applications: It is not currently possible to reuse the screenshot of application
surfaces in a performant way as the contents are now dumped to a file.
e.g. window manager should be able to take the screenshot of all application surfaces and create a 3D
animation which shows the tiled(stacked) view of all running applications.
One way to address the above use cases is to copy the screenshot content to a DMA buffer. The window manager
should allocate a DMA buffer and sent it to the compositor. The compositor then copies the surface/output
content to the DMA buffer and returns it.
I have provided a sample implementation and test based on ivi-shell.https://gitlab.freedesktop.org/wayland/weston/-/merge_requests/341Scene-graph improvements2021-07-31T16:03:10ZMarius VladScene-graph improvementsOne of the things missing in scene-graph was having a reason (contextual human-form like)
as to why the view could not been placed/assigned into a HW plane.
This series tries to address some the comment raised in #244, and, in some ext...One of the things missing in scene-graph was having a reason (contextual human-form like)
as to why the view could not been placed/assigned into a HW plane.
This series tries to address some the comment raised in #244, and, in some extent it should supersede
!333, but only on the display part not the calculations further discussed there (specifically by https://gitlab.freedesktop.org/wayland/weston/commit/e90d7bfbd9223a5263f90ea63ab96c05c6a63961).
This series:
- adds a new callback into `weston_output` which can be installed by the backend than can be called from
libweston: `weston_compositor_print_scene_graph()`.
- we hang off a `uint32_t` reason into `weston_view` and use front-end `weston_view_set_reason_for_compositing()` in the backend set the reason
- the human-form strings are completely opaque to the front-end
- the backend-drm contains the string related reasons
Further it also adds a new scene-graph, `scene-graph-by-output` which only changes a bit how the views are displayed, by grouping the views first by the output, then in layers. It shows views for each output, but still keeps the layers numbering. Arguably it should be much more easy to get a sense of the scene-graph in multiple output set-ups. This might require some cleanup as it adds some duplicate parts, but not really sure if it makes to see how to do it better in case this is not something that seems good to have.https://gitlab.freedesktop.org/wayland/weston/-/merge_requests/333backend-drm: Allow to discern which views make do not make it to a HW plane2022-04-27T11:56:27ZMarius Vladbackend-drm: Allow to discern which views make do not make it to a HW planeThere could be views which can't make it to a HW plane or the
renderer (those occluded by other views) so add a way to tag easily
and display it properly.
Signed-off-by: Marius Vlad <marius.vlad@collabora.com>There could be views which can't make it to a HW plane or the
renderer (those occluded by other views) so add a way to tag easily
and display it properly.
Signed-off-by: Marius Vlad <marius.vlad@collabora.com>https://gitlab.freedesktop.org/wayland/weston/-/merge_requests/250Upstream weston memory leak fixes2021-07-31T14:25:28ZLujin Wangluwang@nvidia.comUpstream weston memory leak fixesPlease help review these six changes to fix memory leaks. ThanksPlease help review these six changes to fix memory leaks. Thankshttps://gitlab.freedesktop.org/wayland/weston/-/merge_requests/202Timing debug2021-04-27T17:44:58ZRobert BeckettTiming debugHere is some timing debug that proved useful. It may be useful to others.Here is some timing debug that proved useful. It may be useful to others.https://gitlab.freedesktop.org/wayland/weston/-/merge_requests/154compositor: Remove fully occluded views from scene2021-07-31T14:21:55ZHarish Krupocompositor: Remove fully occluded views from sceneIdentify a view's occlusion status. A view can have one of these occlusion states:
* NOT_OCCLUDED
* PARTIALLY_OCCLUDED
* FULLY_OCCLUDED
This information could be used to disable sending wl_callback for the
views which are currently FULL...Identify a view's occlusion status. A view can have one of these occlusion states:
* NOT_OCCLUDED
* PARTIALLY_OCCLUDED
* FULLY_OCCLUDED
This information could be used to disable sending wl_callback for the
views which are currently FULLY_OCCLUDED. These views can also be ignored while repainting a scene.
Implements: https://gitlab.freedesktop.org/wayland/weston/issues/198
Test:
* Open `weston-terminal`
* Run `WAYLAND_DEBUG=1 weston-simple-egl`
* Run another instance of `weston-terminal`
* Move the second terminal so as to cover the egl app's full surface
* Observe that the wl_callback is not sent for the app.
Signed-off-by: Harish Krupo <harish.krupo.kps@intel.com>https://gitlab.freedesktop.org/wayland/weston/-/merge_requests/53WIP: Alpha compositing v12022-05-04T13:20:58ZScott AndersonWIP: Alpha compositing v1This implements the `zwp_alpha_compositing_v1` protocol: https://lists.freedesktop.org/archives/wayland-devel/2018-November/039671.html
Marked as WIP until it is merged upstream.This implements the `zwp_alpha_compositing_v1` protocol: https://lists.freedesktop.org/archives/wayland-devel/2018-November/039671.html
Marked as WIP until it is merged upstream.https://gitlab.freedesktop.org/wayland/weston/-/merge_requests/50WIP: Multi gpu pixman support2021-04-27T17:44:50ZVasilis LiaskovitisWIP: Multi gpu pixman supportThis is a WIP patch implementing support for multiple drm devices
when using the pixman renderer. A new config option "multi-drm" is
introduced in the drm backend. When specified, the backend will try
to use all available drm devices fou...This is a WIP patch implementing support for multiple drm devices
when using the pixman renderer. A new config option "multi-drm" is
introduced in the drm backend. When specified, the backend will try
to use all available drm devices found.
Tested with:
weston --multi-drm --use-pixman --backend=drm-backend.so
on a dual-GPU desktop, each GPU connected to a single display.
- A new struct drm_dev stores the drm-device specific fields. The
drm_backend keeps a wl_list of these devices.
- structs drm_head, drm_output have a pointer to the appropriate drm_device.
- capabilities (atomic modesetting, clock setting, cursor width and height,
universal planes, aspect ratio) are backend-global and have to be set
after checking the respective cap on all drm devices.
- Should cursor width and height be drm-specific? What other drm_backend
struct fields should be drm-device specific?
- There is code in the patch concerning gl-renderer/egl/gbm but of course
it does not work yet with the multi-drm option. The question is whether
the approach this patch takes will be suitable for supporting gl
or other renderers in the future.
Again this is RFC/WIP, to see if this approach is sane to continue developing.
Comments welcome. Formatting and style are not thoroughly checked, and comments
are still sparse, apologies.
wayland/weston#76