- Feb 24, 2023
-
-
Alexandros Frantzis authored
Implement functions to find the IDropTarget for a particular point in a window. Signed-off-by:
Alexandros Frantzis <alexandros.frantzis@collabora.com>
-
Alexandros Frantzis authored
For each mime type of the associated data offer we provid a FORMATETC entry with the matching Windows clipboard format. We ensure that there are no duplicate FORMATETC entries. Signed-off-by:
Alexandros Frantzis <alexandros.frantzis@collabora.com>
-
Alexandros Frantzis authored
If the associated data offer has a mime type matching the requested Windows clipboard format, import the data into a HGLOBAL memory object. Signed-off-by:
Alexandros Frantzis <alexandros.frantzis@collabora.com>
-
Alexandros Frantzis authored
Check if for any of the available mime types of the associated data offer we support converting from that mime type to the requested Windows clipboard format. Signed-off-by:
Alexandros Frantzis <alexandros.frantzis@collabora.com>
-
Alexandros Frantzis authored
This IDataObject will be used to integrate with drag-and-drop from other Wayland clients. Signed-off-by:
Alexandros Frantzis <alexandros.frantzis@collabora.com>
-
Alexandros Frantzis authored
Handle the Wayland event which informs us of the new current clipboard selection. We use the provided event information to update the available formats in the Windows clipboard, without populating them with any actual data. We populate the clipboard data on demand through the handling of the WM_RENDERFORMAT message. Signed-off-by:
Alexandros Frantzis <alexandros.frantzis@collabora.com>
-
Alexandros Frantzis authored
Signed-off-by:
Alexandros Frantzis <alexandros.frantzis@collabora.com>
-
Alexandros Frantzis authored
Import into Windows clipboard data we got from other Wayland clients, for a particular Windows clipboard format. This allow us to fetch clipboard data and populate the Windows clipboard contents on demand. Signed-off-by:
Alexandros Frantzis <alexandros.frantzis@collabora.com>
-
Alexandros Frantzis authored
When the Windows clipboard is updated, create a new Wayland data source that exports the update clipboard data, and make it the current Wayland data selection. Signed-off-by:
Alexandros Frantzis <alexandros.frantzis@collabora.com>
-
Alexandros Frantzis authored
Import and export TIFF, PNG, JPEG and GIF image formats. Signed-off-by:
Alexandros Frantzis <alexandros.frantzis@collabora.com>
-
Alexandros Frantzis authored
Convert between CF_HDROP Windows clipboard format and "text/uri-list" Wayland clipboard format. Signed-off-by:
Alexandros Frantzis <alexandros.frantzis@collabora.com>
-
Alexandros Frantzis authored
Import and export RTF clipboard/drag-and-drop data. Signed-off-by:
Alexandros Frantzis <alexandros.frantzis@collabora.com>
-
Alexandros Frantzis authored
Convert between CF_UNICODETEXT clipboard format and common "text/plain" Wayland clipboard formats. Signed-off-by:
Alexandros Frantzis <alexandros.frantzis@collabora.com>
-
Alexandros Frantzis authored
Add a function that ensures that all data is written to a file descriptor, resuming in case of interruptions or partial writes. Signed-off-by:
Alexandros Frantzis <alexandros.frantzis@collabora.com>
-
Alexandros Frantzis authored
Introduce infrastructure to convert clipboard/drag-and-drop data between what Wayland understands and what Wine understands. Signed-off-by:
Alexandros Frantzis <alexandros.frantzis@collabora.com>
-
Alexandros Frantzis authored
The clipboard window is created in the PE code, initiated by a driver kernel callback invoked from the unixlib side. Clipboard messages are received in the PE side and forwarded to the unixlib side to be handled there. Signed-off-by:
Alexandros Frantzis <alexandros.frantzis@collabora.com>
-
Alexandros Frantzis authored
This mechanism allows the unixlib code of the driver to call back into the PE code. Signed-off-by:
Alexandros Frantzis <alexandros.frantzis@collabora.com>
-
Alexandros Frantzis authored
Keep track of the wl_data_offer objects sent by the Wayland compositor, and their properties. Signed-off-by:
Alexandros Frantzis <alexandros.frantzis@collabora.com>
-
Alexandros Frantzis authored
This will evolve to support clipboard and drag-and-drop operations in upcoming commits. Signed-off-by:
Alexandros Frantzis <alexandros.frantzis@collabora.com>
-
Now that we have all the pieces together, allow applications to render using the cross-process Vulkan swapchain. Signed-off-by:
Leandro Ribeiro <leandro.ribeiro@collabora.com>
-
Signed-off-by:
Leandro Ribeiro <leandro.ribeiro@collabora.com> Signed-off-by:
Alexandros Frantzis <alexandros.frantzis@collabora.com>
-
Signed-off-by:
Alexandros Frantzis <alexandros.frantzis@collabora.com>
-
Signed-off-by:
Leandro Ribeiro <leandro.ribeiro@collabora.com> Signed-off-by:
Alexandros Frantzis <alexandros.frantzis@collabora.com>
-
Signed-off-by:
Leandro Ribeiro <leandro.ribeiro@collabora.com> Signed-off-by:
Alexandros Frantzis <alexandros.frantzis@collabora.com>
-
Signed-off-by:
Leandro Ribeiro <leandro.ribeiro@collabora.com> Signed-off-by:
Alexandros Frantzis <alexandros.frantzis@collabora.com>
-
This is a simple passthrough implementation to the native Vulkan driver, but will be extended to support cross-process rendering. Signed-off-by:
Leandro Ribeiro <leandro.ribeiro@collabora.com> Signed-off-by:
Alexandros Frantzis <alexandros.frantzis@collabora.com>
-
Create images to be used for cross-process Vulkan rendering, and return them through vkGetSwapchainImagesKHR. Signed-off-by:
Leandro Ribeiro <leandro.ribeiro@collabora.com> Signed-off-by:
Alexandros Frantzis <alexandros.frantzis@collabora.com>
-
Introduce the remote swapchain object, currently with a stub implementation, that we are going to use for cross-process Vulkan rendering. Signed-off-by:
Leandro Ribeiro <leandro.ribeiro@collabora.com> Signed-off-by:
Alexandros Frantzis <alexandros.frantzis@collabora.com>
-
When the target window for a Win32 VkSurfaceKHR is not owned by the current process, we don't have access to the corresponding wayland surface to use as the target for creating the host VkSurfaceKHR. In such cases create a dummy wl_surface and use it to allow VkSurfaceKHR to conclude successfully. Note that no content targeting this dummy wl_surface will ever become visible, but we will fix this in upcoming commits when we introduce a cross-process swapchain implementation that forwards images to the right process for presentation. For now the cross-process code path is not used (notice the constant allowed_to_create_remote_swapchain in the code), because we still don't have all the pieces to make the cross-process swapchain work. So we won't even allow the dummy wl_surface to be created. When we put all the pieces together, we'll drop this constant and allow the code to run. Signed-off-by:
Leandro Ribeiro <leandro.ribeiro@collabora.com> Signed-off-by:
Alexandros Frantzis <alexandros.frantzis@collabora.com>
-
Introduce a mechanism to check and enable VkInstance extensions required to support cross-process rendering in upcoming commits. Signed-off-by:
Alexandros Frantzis <alexandros.frantzis@collabora.com>
-
Introduce a mechanism to check and enable VkDevice extensions required to support cross-process rendering in upcoming commits. Signed-off-by:
Leandro Ribeiro <leandro.ribeiro@collabora.com> Signed-off-by:
Alexandros Frantzis <alexandros.frantzis@collabora.com>
-
Implement vkCreateDevice and vkDestroyDevice so that: 1. We can track the mapping between physical and logical Vulkan devices. 2. We can enable some additional host VkDevice extensions. Both of the above are required to support cross-process rendering in upcoming commits. Signed-off-by:
Leandro Ribeiro <leandro.ribeiro@collabora.com>
-
In the following commits we'll introduce an internal swapchain in order to support Vulkan cross-process rendering. In order to do that, we'll need to create wl_surface objects from the per-process instance. So bind to wl_compositor on the per-process instance as well. Signed-off-by:
Leandro Ribeiro <leandro.ribeiro@collabora.com>
-
This makes some Vulkan extensions available to driver and allows them to override a few more Vulkan functions. This will be needed by the Wine Wayland driver in the following commits, in which we introduce support for cross-process Vulkan rendering. Extensions: VK_EXT_external_memory_dma_buf VK_EXT_image_drm_format_modifier VK_KHR_external_fence_fd VK_KHR_external_memory_fd VK_KHR_external_semaphore_fd Functions: vkCreateDevice vkDestroyDevice vkAcquireNextImageKHR Signed-off-by:
Leandro Ribeiro <leandro.ribeiro@collabora.com>
-
With this change we don't need to implement all the functions from struct vulkan_funcs on the X11 driver. This is safe to do because Wine has fallbacks for them. Signed-off-by:
Leandro Ribeiro <leandro.ribeiro@collabora.com>
-
Alexandros Frantzis authored
When the Wayland surface is updated (including when it changes to NULL, i.e., when it is destroyed), we need to notify the application so that it can deal with it accordingly. Signed-off-by:
Alexandros Frantzis <alexandros.frantzis@collabora.com>
-
Alexandros Frantzis authored
The VkSurfaceKHR we return in wayland_vkCreateWin32SurfaceKHR *is* the native VkSurfaceKHR, so the implementation is trivial. Signed-off-by:
Alexandros Frantzis <alexandros.frantzis@collabora.com>
-
Alexandros Frantzis authored
This is a simple passthrough implementation to the native Vulkan driver. Signed-off-by:
Alexandros Frantzis <alexandros.frantzis@collabora.com>
-
Alexandros Frantzis authored
This is a simple passthrough implementation to the corresponding Vulkan Wayland extension. Signed-off-by:
Alexandros Frantzis <alexandros.frantzis@collabora.com>
-
Alexandros Frantzis authored
This is a simple passthrough implementation to the native Vulkan driver, with the addition of a VkSurfaceKHR invalidation check. Signed-off-by:
Alexandros Frantzis <alexandros.frantzis@collabora.com>
-