wlroots.git - fork of wlroots with action binder support

Age	Commit message (Collapse)	Author
2022-11-15	render/vulkan: add wlr_vk_texture_has_alpha	zccrs
	Allow to get whether has alpha channel of the VkImage, it can help an optimization to disable blending when the texture doesn't have alpha. Because the VkFormat isn't enough because it's always set to VK_FORMAT_B8G8R8A8_SRGB or VK_FORMAT_R8G8B8A8_SRGB.
2022-11-11	render/texture: constify wlr_texture_update_from_buffer()	Simon Ser

2022-11-11	render/vulkan: use initializer for VkBufferImageCopy	Simon Ser
	Missed that one it seems.
2022-11-08	render/vulkan: add some interfaces to allow compositors to integrate	zccrs
	Added wlr_vk_renderer_get_* functions to allow get the VkInstance, VkPhysicalDevice, VkDevice, queue family of a wlr_vk_renderer. Added wlr_vk_renderer_get_current_image_attribs function to allow get the VkImage of current renderer buffer to use on compositors. Added wlr_renderer_is_vk function, it's like the wlr_renderer_is_gles2, returns true if the wlr_renderer is a wlr_vk_renderer. Added wlr_vk_image_get_attribs function to get a VkImage and it's extras information (e.g. a VkImageLayout and VkImageFormat of the VkImage) from a wlr_texture.
2022-11-06	render/vulkan: use struct initializers	Simon Ser
	Instead of filling the fields one by one, use a struct initializer. This avoids repeating the name of the variable and is more consistent with the wlroots code style.
2022-10-07	render/vulkan: Implement vulkan_read_pixels	David96

2022-09-30	render/vulkan: use addon for wlr_vk_texture	Simon Ser
	Avoids having to walk the list of all textures.
2022-09-07	render/vulkan: remove unnecessary casts	Simon Ser
	No need to go back to the generic wlr_renderer/wlr_texture when passing a Vulkan renderer/texture to an internal function.
2022-08-28	render/vulkan: fix memory type detection	Bernardo Meurer
	From a comment by emersion: > There is a logic error here: we pass 0xFFFFFFFF to vulkan_find_mem_type, which > returns an index, and then we logical-and that with mem_reqs.memoryTypeBits. > Instead we should pass mem_reqs.memoryTypeBits to vulkan_find_mem_type and use > the result for the memoryTypeIndex field directly. Ideally checking for errors > (-1 return value) in case no memory type is suitable. Closes: #3470
2022-08-12	render: replace wlr_texture_write_pixels with update_from_buffer	Simon Ser
	This lets the renderer handle the wlr_buffer directly, just like it does in texture_from_buffer. This also allows the renderer to batch the rectangle updates, and update more than the damage region if desirable (e.g. too many rects), so can be more efficient.
2022-06-16	render/texture: drop wlr_texture_is_opaque	Simon Ser
	Whether a texture is opaque or not doesn't depend on the renderer at all, it just depends on the source buffer. Instead of forcing all renderers to implement wlr_texture_impl.is_opaque, let's move this in common code and use the wlr_buffer format to know whether a texture will be opaque.
2022-05-01	render/vulkan: fix undefined reference to wlr_texture_is_vk	zccrs
	Added the implement of wlr_texture_is_vk. Fixes: https://gitlab.freedesktop.org/wlroots/wlroots/-/issues/3419
2021-12-26	vulkan: Fix imported image layout	nyorain

2021-11-17	Remove support for DMA-BUF flags	Simon Ser
	They are never used in practice, which makes all of our flag handling effectively dead code. Also, APIs such as KMS don't provide a good way to deal with the flags. Let's just fail the DMA-BUF import when clients provide flags.
2021-10-18	render/vulkan: Use image view swizzles instead of shader hack	Joshua Ashton
	Signed-off-by: Joshua Ashton <joshua@froggi.es>
2021-10-18	render/vulkan: add Vulkan renderer	nyorain
	This new renderer is implemented with the existing wlr_renderer API (which is known to be sub-optimal for some operations). It's not used by default, but users can opt-in by setting WLR_RENDERER=vulkan. The renderer depends on VK_EXT_image_drm_format_modifier and VK_EXT_physical_device_drm. Co-authored-by: Simon Ser <contact@emersion.fr> Co-authored-by: Jan Beich <jbeich@FreeBSD.org>