In the Windows SDK, PSECURITY_DESCRIPTOR is void* and
PISECURITY_DESCRIPTOR is SECURITY_DESCRIPTOR*. PSECURITY_DESCRIPTOR is
defined in winnt.h and PISECURITY_DESCRIPTOR is defined in
wbasetypes.idl.
This corresponds to vkd3d as of commit
acd3ed97dc8e1ac192b2ec6fc19596831a6b61c6.
The cpp_quoted #include directive is fixed up to match the file
naming outside of vkd3d, renaming the reference to
vkd3d_d3d12sdklayers.h back to d3d12sdklayers.h.
This matches other renamings that are done at the start of the
file for vkd3d renamed idl files as well.
Signed-off-by: Martin Storsjö <martin@martin.st>
Store and compare against the wl_seat global id (aka name) during
global_remove, since the global id is distinct from the wl_proxy id
which we were previously checking.
When we are notified by Wine core that the user wants to interactively
resize the window, forward the request to compositor, so it can take
over and resize the window according to user input.
In the process of the interactive resize we receive a stream of
xdg_toplevel configure events informing us about the updated window
sizes.
When we are notified by Wine core that the user wants to interactively
move the window, forward the request to compositor, so it can take over
and move the window according to user input.
Note that the move does *not* affect the position of the window in the
Wine virtual screen space.
A request for the maximized state has two potential origins:
1. The compositor, through an xdg_toplevel configure event. In this case
we update the window state and size accordingly.
2. The application or Wine itself, by changing the window style. When
we detect such a style, we make a request to the compositor to set
the maximized state. The compositor will then eventually reply with
a configure event, and we continue with case (1). Note that the
compositor may deny our request, in which case we will also sync
the window style accordingly.
An acknowledged maximized state imposes very strict constraints on the
size of surface content we can present. We are careful to not violate
these constraints, since otherwise the compositor will disconnect us.
Use the size hint provided by the compositor to resize the window
associated with a Wayland toplevel surface.
A surface config moves through the following stages (each stage may hold
a different event):
1. Pending: In the process of being populated from separate Wayland
events.
2. Requested: A fully formed config which hasn't been handled yet. A new
finalized Pending event will always be promoted to a Requested event
(so we will skip previous events if new ones arrive quickly enough).
3. Processing: A config that is being processed. When processing is
done, we mark it with `wayland_surface_config.processed = TRUE`.
4. Current: The config has been acknowledged, i.e., we are promising to
respect any implied content constraints.
Ignoring the possibility of HWND recycling allows us to use a simpler
scheme to ensure valid access to the wayland_surface associated with an
xdg_surface during event handling. The scheme involves setting HWND as
the xdg_surface user data and using that to get to the wayland_surface.
The prerequisite for this code to be correct is that the wayland surface
destruction for a HWND must be performed under the wayland_win_data
mutex.
