On Sat Nov 1 18:46:55 2025 +0000, QwertyChouskie wrote:
> > Good point, thanks. It does seem possible to use that extension, but I
> think we also need to support Nvidia. We could maybe have it as an
> alternative, though I’m not sure there are cases where it would actually
> help (that is, cases where the extension is available but a sufficient
> Vulkan driver isn’t).
> r600 (assuming it supports this extension) is certainly one case that
> comes to mind for something that is reasonably performant for older
> games but doesn't support Vulkan.
It also turned out that llvmpipe doesn’t support VK_EXT_map_memory_placed, and GL_AMD_pinned_memory would be a good fit for it. I plan to give that a try.
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/9032#note_120365
The TWAIN data sources sane.ds and gpoto.ds create progress dialogs with the WIN32 CreateDialog API in files ui.c
When they need to destroy these windows, they call EndDialog. But EndDialog is meant for Modal Dialogs created by DialogBox, DialogBoxParam, DialogBoxInd and the like. Calling it for dialogs created by CreateDialog is undocumented behaviour.
In the end, those progress dialogs are not destroyed (immediatly?) and can still be open when the application program closes the data source with the message.
DG_CONTROL / DAT_IDENTITY / MSG_CLOSEDS
This can then later cause a segfault if the sane.ds/gpoto2.ds gets unloaded with FreeLibrary so the dialog box procedure is no longer in memory. There is a workaround for this in dlls/twain_32/dsm_ctrl.c:220:
```
/* This causes crashes due to still open Windows, so leave out for now.
* FreeLibrary (currentDS->hmod);
*/
```
But the TWAIN organization offers their own DSM-Library twaindsm.dll, that does not contain this workaround so segfaults after an otherwise successful scan:
https://github.com/twain/twain-dsm
Using this patch, progress dialogs are closed with DestroyWindow instead of EndDialog and these segfaults do not occur any more. This would also allow to change the code in dsm_ctrl.c:220 to FreeLibrary the DS module again. I've tested that it works. But there is no evidence that that change would have benefits and it might have other disadvantages.
Compatibility of twaindsm.dll with sane.ds requires one of my previous merge requests that are not yet in wine main tree.
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/9329
When the sane.ds TWAIN data source displays it's user interface, it auto-generates a proprties dialog from the sane options for the current scanner.
Oftenly this dialog contains windows ComboBox controls to choose between scan modes (gray / color) or resolutions.
The ComboBox controls created are too flat to properly drop down, they only open about half a line height. This is difficult to use.
This patch makes the control about 10 times the height of a string. The combox will not occupy more height than the elements that are filled in anyway.
Behaviour before the patch:
{width=305 height=244}
Behaviour after the patch:
{width=308 height=246}
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/9328