June 2022 - Wine-Devel - list.winehq.org

[PATCH 0/1] MR164: winex11.drv: Avoid adding duplicate GPUs.

by Paul Gofman (＠gofman)

On certain dual GPU configurations (AMD integrated / discrete GPU laptop in my case) vkGetRandROutputDisplayEXT() doesn't work the way we currently expect. That is, it returns success and a valid VkDisplay handler for any randr provider and GPU combination. The configuration ends up broken in various aspects, the same GPU gets added twice with identical parameters while another GPU is not represented at all. I think it is not a Vulkan or xrandr bug, this behaviour probably reflects the fact that one can present from any of Vulkan devices to the displays plugged to any of those outputs. The patch avoids adding the device twice and also another device gets represented as well. The relation between the added GPUs and monitors ends up being somewhat arbitrary but then it doesn't affect much in the case when displays are accessible though any of adapters. The alternative to consider would be to have a completely separate path to be taken if Vulkan is available which instead of attaching Vulkan device info to xrandr-driven GPUs list would have GPU device spawned by Vulkan device and use xrandr to link the adapters and displays to GPUs. This way it would also help Wayland where we don't have real xrandr providers (only one WAYLAND provider with all the displays) and end up without creating proper GPU devices. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/164

June 1, 2022

[PATCH 1/1] avicap32: Add fallback Unixlib function and thunk to use when V4L is unavailable.

by Brendan Shanks

From: Brendan Shanks <bshanks(a)codeweavers.com> Signed-off-by: Brendan Shanks <bshanks(a)codeweavers.com> --- dlls/avicap32/v4l.c | 26 ++++++++++++++++++++++++-- 1 file changed, 24 insertions(+), 2 deletions(-) diff --git a/dlls/avicap32/v4l.c b/dlls/avicap32/v4l.c index 4f3a162c838..792aa5732f6 100644 --- a/dlls/avicap32/v4l.c +++ b/dlls/avicap32/v4l.c @@ -42,10 +42,10 @@ #include "unixlib.h" -#ifdef HAVE_LINUX_VIDEODEV2_H - WINE_DEFAULT_DEBUG_CHANNEL(avicap); +#ifdef HAVE_LINUX_VIDEODEV2_H + static int xioctl(int fd, int request, void *arg) { int ret; @@ -139,4 +139,26 @@ const unixlib_entry_t __wine_unix_call_wow64_funcs[] = #endif /* _WIN64 */ +#else /* HAVE_LINUX_VIDEODEV2_H */ + +static NTSTATUS get_device_desc(void *args) +{ + ERR("Video4Linux support not enabled\n"); + return STATUS_UNSUCCESSFUL; +} + +const unixlib_entry_t __wine_unix_call_funcs[] = +{ + get_device_desc, +}; + +#ifdef _WIN64 + +const unixlib_entry_t __wine_unix_call_wow64_funcs[] = +{ + get_device_desc, +}; + +#endif /* _WIN64 */ + #endif /* HAVE_LINUX_VIDEODEV2_H */ -- GitLab https://gitlab.winehq.org/wine/wine/-/merge_requests/163

June 1, 2022

[PATCH 0/1] MR163: avicap32: Add fallback Unixlib function and thunk to use when V4L is unavailable.

by Brendan Shanks (＠bshanks)

-- https://gitlab.winehq.org/wine/wine/-/merge_requests/163

June 1, 2022

Re: [PATCH v2 2/3] jscript: Don't execute any functions if script state does not allow it.

by Jacek Caban

On 5/31/22 16:56, Gabriel Ivăncescu wrote: > Instead of only interpreted functions. Property retrievals or setters are > allowed though, as long as they are not accessors. > > Signed-off-by: Gabriel Ivăncescu<gabrielopcode(a)gmail.com> > --- > > Note that native GetDispID seem to fail when retrieving builtin/prototype > functions (?) if script is uninitialized, but retrieving the DISPID before and > using it after it's uninitialized still works, though (that's what the tests > do). I don't think it's worth replicating this GetDispID quirk for the moment. I'm not really concerned about GetDispID quirks, but implication of your choice for the next patch. I think that releasing objects sooner is better, so it would be good to have a better argument for moving that. Your reasoning there is based on details of how you decided to not follow native here. More generally, creating function objects in response for property get is an implementation detail that supposed to be transparent. If it's causing problems elsewhere, I'd first look at making it more transparent. In this case, maybe we should create function objects sooner, in response to GetDispID. This would both match all tests and allow us to release function constructor sooner. Jacek

June 1, 2022