Commit 09c12699 ("[uwac] window: fix damage region dimensions (rounding
errors)") added a 1-pixel expansion to the damage rect passed to
wl_surface_damage() (i.e. x-=1, y-=1, w+=2, h+=2) to guard against
rounding errors when a display scale factor is in use.
This causes visible rectangular glitches around every updated region.
The Wayland compositor re-composites exactly the declared damage region
from the attached buffer onto the screen. Because wlf_copy_image() only
writes pixels for the exact update rectangle, the 1-pixel border in the
buffer is never updated. With double-buffering the border pixels contain
stale data from the last time that buffer was used, and the compositor
faithfully composites those stale pixels, producing the artifact.
The floor/ceil rounding applied before the expansion is already
sufficient to cover any sub-pixel precision lost when converting from
buffer coordinates to surface coordinates. Remove the extra ±1 padding.
Parameters passed to wp_viewport_set_destination was scaled instead of
the actual window size. In fact I noticed this problem when I was
testing the initial change (c29ba7985) but was not sure about how to fix
this and moreover, the tiling manager which I am using (sway) is
immediatelly tiling the window and all seems fine in day-to-day use
with tiled window.
The problem was only visible when the window was changed to floating:
the window content was scaled properly but the viewport was twice as
big (thus a whole window). What is worse it seems that the scaling was
done multiple times making a huge window size in some circumstances.
Now in new sway version 1.9 authors added an assert which prevents from
having a window which overlaps different renderers and this also trigger
this problem in FreeRDP, because when starting the window size was too
big.
This was leading to:
wp_viewport@31: error 2: source rectangle out of buffer bounds
or even sway crash
This commit is fixing this problem by using a proper window size values
(initially passed to a function and saved to additional variables before
scaling calculation).
Window size is now correct even when changed to a floating window.
Wayland compositors can support the wp_viewporter protocol,
which allows for the mapping of arbitrarily sized buffer
regions to output surfaces.
This result in correct scaling on HiDPI outputs with scaling
enabled.
The ivi surface-id is made configurable by fetching it from the
environment variables. An environment variable IVI_SURFACE_ID needs to
be set to the required surface-id. In case it is not set then the code
will take 1 as the default surface-id.
Signed-off-by: Kshitij Kadam <Kshitij.Kadam@ifm.com>
The current order of protocol selection is xdg_base followed by
ivi_application followed by fullscreen_shell. As a result xdg_base
protocol will be selected even if ivi_application protocol is needed.
The order is now changed to ivi_application followed by fullscreen_shell
followed by xdg_base. It is now possible to select any one of the three
protocols by appropriately defining BUILD_IVI and BUILD_FULLSCREEN_SHELL
macro.
Signed-off-by: Kshitij Kadam <Kshitij.Kadam@ifm.com>
pass window and buffer index to buffer_release listener, so that it
fetches actual pointer to released buffer by wayland, instead of
directly passing a pointer to the UwacBuffer, which could result in
heap-use-after-free
`UwacWindowShmAllocBuffers()` allocates memory with `mmap` and never frees it
resulting in SIGBUS errors and running out of memory after some time.
Adding a corresponding `munmap` fixes this issue.
If pendingBuffer is set when it was otherwise NULL, then
UwacWindowSubmitBuffer will forever bail early, waiting for a frame
callback that will never come.
