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.
* Buffer submit now ignores duplicate buffer submit again.
* Frame callback is cleaned up in the callback function now.
* Damage region is currently ignored as there are screen artifacts otherwise.
The wayland buffer size always matches the current window size.
That might be different from the actual remote framebuffer size,
to when copying always use the correct strides to avoid distorted
screen content.
