January 2023 - Wine-Devel - list.winehq.org

Re: How should one report GitLab CI bugs?

by Francois Gouget

On Thu, 19 Jan 2023, Alexandre Julliard wrote: [...] > Would it mean failures that only happen on Gitlab CI? Or failures that > happen in CI but also elsewhere? Either way, the distinction doesn't > seem all that useful to me. The idea was that some Wine developers may be more interested in fixing bugs causing false positives in the new CI system (GitLab CI) than in the old one (TestBot). So identifying those in Bugzilla may help them find targets to work on. But of course that assumes that set of developers is non-empty. -- Francois Gouget <fgouget(a)codeweavers.com>

Jan. 26, 2023

Re: Alexandre Julliard : shell32: Allocate a full SHITEMID to avoid a compiler warning.

by Eric Pouech

Le 25/01/2023 à 22:22, Alexandre Julliard a écrit : > Module: wine > Branch: master > Commit: c844ebdb0ae8994ee4f3d1d3c1697ece06f52a4e > URL: https://gitlab.winehq.org/wine/wine/-/commit/c844ebdb0ae8994ee4f3d1d3c1697e… > > Author: Alexandre Julliard <julliard(a)winehq.org> > Date: Tue Jan 24 22:22:52 2023 +0100 > > shell32: Allocate a full SHITEMID to avoid a compiler warning. > > --- > > dlls/shell32/shfldr_fs.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/dlls/shell32/shfldr_fs.c b/dlls/shell32/shfldr_fs.c > index 662d8b52d5b..d47911dbef7 100644 > --- a/dlls/shell32/shfldr_fs.c > +++ b/dlls/shell32/shfldr_fs.c > @@ -347,7 +347,7 @@ IShellFolder_fnParseDisplayName (IShellFolder2 * iface, > /* Special case for the root folder. */ > if (!wcsicmp( szPath, L"\\\\?\\unix\\" )) > { > - *ppidl = SHAlloc(sizeof(USHORT)); > + *ppidl = SHAlloc(sizeof(*ppidl)); shouldn't it be sizeof(**ppidl) instead to better match the patch description?

Jan. 26, 2023

Re: Problem with the wine-gitlab mailing list archive?

by Jeremy Newman

Restarted the daemon, that will get it going again until it just stops processing due to a mysql bug in the archiver code. -N On 1/25/2023 8:18 PM, Francois Gouget wrote: > On Tue, 1 Nov 2022, Francois Gouget wrote: > [...] >> It looks like the DB / Hyperkitty is acting up again: the >> last wine-gitlab email in the archives dates back to Oct 28. > > Bad Kitty! > According to the archives the last messages were sent on Jan 15th for > wine-devel and Jan 18th for wine-gitlab :-( > So seems like something's amiss. >

Jan. 26, 2023

Re: dmloader:dmloader crash on gitlab-debian-64

by Francois Gouget

On Fri, 20 Jan 2023, Austin English wrote: > On Fri, Jan 20, 2023 at 9:36 AM Francois Gouget <fgouget(a)codeweavers.com> > wrote: > > > * The test report on test.winehq.org only has the test output, not > > Wine's stderr traces which is where a backtrace would be. > > > > http://winetest.dolphin/data/047118247ce489a7138428c8b2cd5692ed04337e/linux… > > > > That link isn't publicly accessible (I suspect it may be an internal > CodeWeavers' address?). No, that's from my development test.winehq.org server (which I like despite the 30MB page because it has 6 months of history). Sometimes I copy/paste from the wrong browser window :-( In such cases it's just a matter of replacing the hostname. The link below should work: https://test.winehq.org/data/047118247ce489a7138428c8b2cd5692ed04337e/linux… -- Francois Gouget <fgouget(a)codeweavers.com>

Jan. 26, 2023

Re: Problem with the wine-gitlab mailing list archive?

by Francois Gouget

On Tue, 1 Nov 2022, Francois Gouget wrote: [...] > It looks like the DB / Hyperkitty is acting up again: the > last wine-gitlab email in the archives dates back to Oct 28. Bad Kitty! According to the archives the last messages were sent on Jan 15th for wine-devel and Jan 18th for wine-gitlab :-( So seems like something's amiss. -- Francois Gouget <fgouget(a)codeweavers.com>

Jan. 26, 2023

Re: 8.0 release notes (draft)

by Eric Pouech

Le 23/01/2023 à 17:37, Alexandre Julliard a écrit : > Folks, > > The final 8.0 will be released shortly. Thanks to everybody who helped > fix regressions! We didn't quite make it back to the 7.0 count, but > we've still made very good progress, with over 160 bugs fixed during > code freeze. > > Below is the draft of the release notes, please have a look and let me > know if anything is incorrect or missing. Thanks to Jacek, Nikolay, Rémi > and Zeb for their help with this! > a couple of remarks: from *** WoW64 - WoW64 thunks are implemented for essentially all Unix libraries, enabling a 32-bit PE module to call a 64-bit Unix library. Once the remaining direct PE/Unix calls have been removed, this will make it possible to run 32-bit Windows applications without any 32-bit Unix library. and *** Build infrastructure - PE binaries can be built for multiple architectures from the same build tree, using the '--enable-archs' option to configure, for example '--enable-archs=i386,x86_64'. This can be used to enable the experimental WoW64 mode, where 32-bit applications can run without any 32-bit host libraries. shouldn't the second paragraph mention the fact that running without 32bit host lib will only be avail after the removal of direct calls? I also found that the part: Since in case of configuration errors it is possible for it to be triggered inadvertently, applications started in this mode print the warning "starting in experimental wow64 mode". is strangely stated... it could perhaps state that this is still WIP and shouldn't recommend using it for now (even if the "starting in experimental wow64 mode" could infer that) from a support perspective, are we confident enough that we'll have enough information to detect it? - we have the "starting in experimental wow64 mode" - absence of ELF libs in 32bit backtrace in winedbg is a good sign of it *** Miscellaneous - C++11 syntax is supported in function name demangling. I'd rather say that (not sure if syntax refers to C++11 or the mangled names...): - name demangling better supports C++11 features

Jan. 26, 2023

Re: 8.0 release notes (draft)

by Huw Davies

On Mon, Jan 23, 2023 at 05:37:33PM +0100, Alexandre Julliard wrote: > - Force feedback effect support is improved, specifically with driving wheels > controllers. s/wheels/wheel/

Jan. 26, 2023

8.0 release notes (draft)

by Alexandre Julliard

Folks, The final 8.0 will be released shortly. Thanks to everybody who helped fix regressions! We didn't quite make it back to the 7.0 count, but we've still made very good progress, with over 160 bugs fixed during code freeze. Below is the draft of the release notes, please have a look and let me know if anything is incorrect or missing. Thanks to Jacek, Nikolay, Rémi and Zeb for their help with this! -- Alexandre Julliard julliard(a)winehq.org ---------------------------------------------------------------- What's new in Wine 8.0 ====================== *** PE modules - After 4 years of work, the PE conversion is finally complete: all modules can be built in PE format. This is an important milestone on the road to supporting various features such as copy protection, 32-bit applications on 64-bit hosts, Windows debuggers, x86 applications on ARM, etc. However, some modules still perform direct calls between the PE and the Unix part, instead of going through the NT system call interface. The remaining direct calls will be removed during the Wine 8.x development phase. - A special syscall dispatcher is used for PE -> Unix transitions, to avoid the overhead of a full NT system call. This minimizes the performance impact of the new architecture, in particular for the OpenGL and Vulkan libraries. - Building mixed Windows/Unix libraries in ELF format (.dll.so libraries) is still supported for use in Winelib applications. However, such applications won't support features enabled by the NT syscall interface, such as WoW64 without 32-bit libraries. *** WoW64 - WoW64 thunks are implemented for essentially all Unix libraries, enabling a 32-bit PE module to call a 64-bit Unix library. Once the remaining direct PE/Unix calls have been removed, this will make it possible to run 32-bit Windows applications without any 32-bit Unix library. - When the 32-bit Wine loader isn't found, 32-bit applications are started in the new "Windows-like" WoW64 mode (where 32-bit code runs inside a 64-bit host process). This mode can be enabled by building with the '--enable-archs' configure option. Since in case of configuration errors it is possible for it to be triggered inadvertently, applications started in this mode print the warning "starting in experimental wow64 mode". *** Graphics - The "Light" theme is enabled in the default configuration, for a more modern look. Other themes can still be configured through WineCfg. - The graphics drivers (winex11.drv, winemac.drv, wineandroid.drv) are converted to run on the Unix side of the syscall boundary, and interface with the Unix side of the Win32u library. - The Print Processor architecture is implemented. This will be used to avoid direct PE<->Unix calls in the printer driver. - Effects are supported in Direct2D, including description parsing and a number of core objects. - Command lists recording and playback are implemented in Direct2D. - The Vulkan driver supports up to version 1.3.237 of the Vulkan spec. *** Direct3D - Many optimizations related to streaming map acceleration are implemented, in common code as well as in the GL renderer. Depending on the application, this may result in major performance improvements. - Adapter video memory budget change notifications are implemented. - The Vulkan renderer supports setting multiple viewports and scissor rectangles. - Several Direct3D 10 and 11 features, which were already implemented, are accurately reported through capability flags: - Per-format support for vertex and index buffers. - Per-format support for all capabilities via D3D11_FEATURE_FORMAT_SUPPORT. - No-overwrite maps on shader resources and constant buffers. - Partial range binding of constant buffers. - For convenience, a new WINE_D3D_CONFIG environment variable may be used instead of modifying the HKEY_CURRENT_USER\Software\Wine\Direct3D registry key. The value is a comma- or semicolon-separated list of key-value pairs, e.g.: WINE_D3D_CONFIG="renderer=vulkan;VideoPciVendorID=0xc0de" If an individual setting is specified in both the environment variable and the registry, the former takes precedence. - The Direct3D graphics card database recognizes more graphics cards. - The Vulkan renderer limits the maximum Direct3D feature level based on available Vulkan features. *** Audio / Video - The MPEG-1 audio decoder filter for layers 1 and 2, and the separate filter for layer 3, are both implemented on top of GStreamer. - The ASF reader filter is implemented. - The OpenAL32.dll wrapper library is removed, in favor of the native OpenAL32.dll library shipped by Windows applications. *** Media Foundation - Content type resolution is improved in the Media Foundation Player. - Rate control is implemented. - The Enhanced Video Renderer default mixer and presenter are better supported. - The DirectShow filter is implemented in the Enhanced Video Renderer. - An initial framework is implemented for the Writer encoding API. - The topology loader is better supported. *** Input devices - Controller hotplug support is greatly improved, and controller removal and insertion are correctly dispatched to applications. - Driving wheel device detection and reporting is better implemented, using the SDL library and HID usages as hints for the device types. - Force feedback effect support is improved, specifically with driving wheels controllers. - The HID Haptics specification is used for left / right motor rumble and trigger rumble. It makes it possible for device drivers to expose haptics support over HidRaw, and overcome EvDev limitations. - The Joystick Control Panel is redesigned, with new graphics and a dedicated view for XInput gamepads. - Sony DualShock and DualSense controllers are supported when the hidraw backend is used, and exposed to applications in the same way as they are on Windows. - The Windows.Gaming.Input module is introduced, one of the first WinRT modules in Wine, implementing a new programming interface to access gamepads, joysticks and driving wheel devices. For this new input API, hotplug notifications are also implemented, as well as force feedback effects and haptics. This API is the first one to support trigger rumble. *** Internationalization - A proper locale database, in Windows locale.nls format, is generated from the Unicode CLDR database. The list of supported locales is essentially identical to that of the latest Windows version. - Unicode string comparison is based on the Windows Sortkey database and algorithms instead of the Unicode Collation Algorithm, yielding more compatible results. - Characters from high Unicode planes (in UTF-16 encoding) are supported in most functions, in particular for case mappings, BiDi formatting, and character shaping. - The UTF-8 encoding is supported as Ansi codepage. It is enabled when requested by the application's manifest. - Unicode character tables are based on version 15.0.0 of the Unicode Standard. - The timezone data is generated from the IANA timezone database version 2022g. *** Text and fonts - Font linking is enabled for most system fonts, which should fix missing glyphs in CJK locales. - Font fallback in DirectWrite is reworked, with additional support for an large number of scripts. *** Kernel - The ApiSetSchema database is implemented, replacing all the api-ms-* forwarding modules. This reduces both disk space and address space usage. - DOS file attributes are persistent, and stored on disk using the filesystem's extended attributes, in a format compatible with Samba. *** Internet and networking - The Online Certificate Status Protocol (OCSP) is implemented. - More EcmaScript features are supported in JScript standard-compliant mode. - The JScript garbage collector is implemented. - Accessibility support is enabled in Wine Gecko package. - Web Storage, Performance object and more event objects are implemented in MSHTML. *** Mono / .NET - The Mono engine is updated to version 7.4.0. The list of changes can be viewed at https://github.com/madewokherd/wine-mono/releases/tag/wine-mono-7.4.0 *** Builtin applications - All the builtin applications use Common Controls version 6, which enables theming and high-DPI rendering by default. - The Wine Debugger (winedbg) prints thread names in the 'info thread' listing, for applications that set the names of their threads. All internal Wine threads also set their own name. - The QWORD type is supported in the REGEDIT and REG registry tools. - Notepad has a status bar displaying the current cursor position. The Goto Line functionality is also implemented. - The builtin console programs print data in the OEM codepage, for better compatibility with applications reading their output. - The Service Control tool (sc.exe) supports the 'query' command. *** Development tools - The PE conversion has made it necessary to implement a new mechanism to run static C++ constructors in Winelib ELF applications. Unfortunately, this requires the corresponding modules to be rebuilt with Wine 8.0. The rebuilt modules will still run correctly on older Wine versions, but older modules will no longer execute static constructors when run on Wine 8.0. - In regression tests, individual checks can be marked as "flaky". This is useful for checks that depend on external factors such as network timings. The errors are still reported but not counted as failures. - Test failure messages can be printed in color by setting the WINETEST_COLOR environment variable, to make them easier to spot in the test log. - The Resource Compiler (WRC) and Message Compiler (WMC) use the locale.nls database to detect languages and codepages, and thus support all the Windows locales. - The WineDump tool supports printing the contents of Enhanced Metafile spool files, as well as more contents from PDB files. *** Build infrastructure - PE binaries can be built for multiple architectures from the same build tree, using the '--enable-archs' option to configure, for example '--enable-archs=i386,x86_64'. This can be used to enable the experimental WoW64 mode, where 32-bit applications can run without any 32-bit host libraries. - Data types that are defined as 'long' on Windows are defined as 'long' instead of 'int' on all platforms with a 32-bit long type. This is more compatible, but it can cause printf format warnings with Unix compilers. In Winelib code, it can be disabled by defining WINE_NO_LONG_TYPES. - Import libraries can be generated without using dlltool, by passing the '--without-dlltool' option to winebuild. This is used to avoid dlltool bugs with delay import libraries. - Libraries that contain only resources and no code can be built with the '--data-only' option to winegcc, which makes them smaller and more efficient to load. *** Bundled libraries - Faudio is updated to the upstream release 22.11. - LCMS2 is updated to the upstream release 2.14. - LibJPEG is updated to the upstream release 9e. - LibMPG123 is updated to the upstream release 1.31.1. - LibPng is updated to the upstream release 1.6.39. - LibTiff is updated to the upstream release 4.4.0. - LibXml2 is updated to the upstream release 2.10.3. - LibXslt is updated to the upstream release 1.1.37. - Zlib is updated to the upstream release 1.2.13. *** Platform-specific features - The experimental WoW64 architecture is supported on macOS versions from 10.15. - 64-bit time_t is supported on 32-bit Linux with recent Glibc versions. - Exception unwinding on ARM platforms is extended with EHABI support on ARM32 and Dwarf support on ARM64. *** Miscellaneous - RSA encryption and the RSA-PSS signing algorithm are implemented. - An initial version of the UI Automation API is implemented. - C++11 syntax is supported in function name demangling. *** External dependencies - The vkd3d and LDAP libraries are bundled in the source tree and built as PE. The corresponding Unix libraries are no longer needed. - The OpenAL library is no longer used.

Jan. 26, 2023

Wine staging 8.0-rc5 release

by Alistair Leslie-Hughes

Binary packages for various distributions will be available from: https://www.winehq.org/download Summary since last release * Rebased to current wine 8.0-rc5 (478 patches are applied to wine vanilla) Upstreamed (Either directly from staging or fixed with a similar patch). * None Added: * None Updated: * None Where can you help * Run Steam/Battle.net/GOG/UPlay/Epic * Test your favorite game. * Test your favorite applications. * Improve staging patches and get them accepted upstream. * Suggest patches to be included in staging. As always, if you find a bug, please report it via https://bugs.winehq.org Best Regards Alistair.

Jan. 26, 2023

Re: dmloader:dmloader crash on gitlab-debian-64

by Austin English

On Fri, Jan 20, 2023 at 9:36 AM Francois Gouget <fgouget(a)codeweavers.com> wrote: > * The test report on test.winehq.org only has the test output, not > Wine's stderr traces which is where a backtrace would be. > > http://winetest.dolphin/data/047118247ce489a7138428c8b2cd5692ed04337e/linux… > That link isn't publicly accessible (I suspect it may be an internal CodeWeavers' address?). -- -Austin GPG: 267B CC1F 053F 0749 (expires 2024/02/17)

Jan. 26, 2023

dmloader:dmloader crash on gitlab-debian-64

by Francois Gouget

On test.winehq.org I see that dmloader:dmloader crashed on gitlab-debian-64 due to an assertion (2023-01-12): 060c:loader: 104 tests executed (0 marked as todo, 0 as flaky, 0 failures), 0 skipped. dmloader:loader:060c done (-2147483391) in 0s 88B Test failed: crash (80000101) https://test.winehq.org/data/patterns.html#dmloader:loader I'd like to know if this is caused by the one assert() in stream_get_chunk(). A backtrace could help in that regard but: * The test report on test.winehq.org only has the test output, not Wine's stderr traces which is where a backtrace would be. http://winetest.dolphin/data/047118247ce489a7138428c8b2cd5692ed04337e/linux… * And the GitLab log has neither the test output nor the Wine traces. https://gitlab.winehq.org/wine/wine/-/jobs/8996 So are the Wine traces available somewhere for GitLab's nightly WineTest runs? -- Francois Gouget <fgouget(a)codeweavers.com>

Jan. 26, 2023

Re: [WINE-CE] Wine-CE Can Run Cross Instruction Architecture Windows App

by Stefan Dösinger

Hi, I'm a co-author of https://github.com/andrerh/hangover , which had similar goals. I haven't tried to build your code yet. Sadly gitee doesn't let me look at anything without creating an account, although I could do an actual checkout of your Wine modifications. qemu is still making its way through my slow internet conenction. >From your description it sounds like you are using Wine's under-development windows-style multilib support to run parts of Wine as arm-native code and the rest as x86. You might be interested to know that we have similar plans. The idea is to handle this the same way windows on arm handles this by having an xtajit.dll instead of wow64cpu.dll that does the emulation entry/exit at the wine fake syscall level. André started looking into this and had some success. I don't know if he published his code yet. Upstreaming something for that goal will likely happen after Wine 8.0 is released. The big challenge is emulation speed. Games are a somewhat special case because a lot of CPU time is spent in drivers, which remain ARM native in Wine's hybrid approach or hangover (but not if you use qemu-linux-user). qemu is terribly slow, too slow to run most applications at acceptable speed. Other than d3d and maybe sound mixing, the windows DLLs do relatively little work and all CPU time is spent in the application's code, which remains x86 code and needs to be emulated. Stefan > Am 18.01.2023 um 16:57 schrieb fanwj(a)mail.ustc.edu.cn: > > Wine-CE (Chimera Edition) is a compatibility layer capable of running Windows applications on Cross-architecture paltform of Linux. It is base on Wine Project and Qemu Project. > > Project Address: https://gitee.com/fanwenjie/wine-ce > > TEST App: Sword and Fairy 3 > > Demonstration: https://www.bilibili.com/video/BV1Kd4y157Lm > >

Jan. 26, 2023

[WINE-CE] Wine-CE Can Run Cross Instruction Architecture Windows App

by fanwj＠mail.ustc.edu.cn

Wine-CE (Chimera Edition) is a compatibility layer capable of running Windows applications on Cross-architecture paltform of Linux. It is base on Wine Project and Qemu Project. Project Address: https://gitee.com/fanwenjie/wine-ce TEST App: Sword and Fairy 3 Demonstration: https://www.bilibili.com/video/BV1Kd4y157Lm

Jan. 26, 2023

How should one report GitLab CI bugs?

by Francois Gouget

How should one report GitLab CI bugs? I'm thinking of two types of bugs. 1. Wine test bugs that specifically happen on the GitLab CI infrastructure. See for instance bug 54334 which describes a set of qasf:asfreader failures that has, so far, only been seen in the Linux GitLab CI. I'm thinking some Wine developers may be particularly interested in getting such bugs fixed and thus would want to have a way to find them. Would a 'gitlabci' or just 'ci' keyword be appropriate? 2. Bugs and missing features in the GitLab CI infrastructure itself. For instance the failures that gitlab-win10-21h2 gets in the ole32:clipboard, riched20:richole and user32:msg tests strongly suggest that the AMD driver was installed with its Adrenalin GUI. Since it is known to interfere with the clipboard this could be considered a bug in that Windows 10 VM configuration. (Alternatively one could argue the tests should be modified to be resistant to such interference which would move this issue to the first category.) Which product should one pick in Bugzilla for reporting such bugs? They would not fit in 'Wine' product or any of the other existing products except 'Wine-Testbot' if one considers the GitLab CI to be the new TestBot (though I think that would be quite confusing). -- Francois Gouget <fgouget(a)codeweavers.com>

Jan. 26, 2023

Wine staging 8.0 release

by Alistair Leslie-Hughes

Binary packages for various distributions will be available from: https://www.winehq.org/download Summary since last release * Rebased to current wine 8.0 (478 patches are applied to wine vanilla) Upstreamed (Either directly from staging or fixed with a similar patch). * None Added: * None Updated: * None Where can you help * Run Steam/Battle.net/GOG/UPlay/Epic * Test your favorite game. * Test your favorite applications. * Improve staging patches and get them accepted upstream. * Suggest patches to be included in staging. As always, if you find a bug, please report it via https://bugs.winehq.org Best Regards Alistair.

Jan. 25, 2023

Wine staging 8.0-rc4 release

by Alistair Leslie-Hughes

Binary packages for various distributions will be available from: https://www.winehq.org/download Summary since last release * Rebased to current wine 8.0-rc4 (478 patches are applied to wine vanilla) Upstreamed (Either directly from staging or fixed with a similar patch). * none Added: * None Updated: * msxml3-FreeThreadedXMLHTTP60 Where can you help * Run Steam/Battle.net/GOG/UPlay/Epic * Test your favorite game. * Test your favorite applications. * Improve staging patches and get them accepted upstream. * Suggest patches to be included in staging. As always, if you find a bug, please report it via https://bugs.winehq.org Best Regards Alistair.

Jan. 15, 2023

Re: TestBot News: Missing dlls and VM updates

by Francois Gouget

On Thu, 12 Jan 2023, Francois Gouget wrote: [...] > > And does it happen on a specific wine test? > > It's enough to run the amstream:amstream test. More precisely it crashes in the gst_init_check() call! That is, the test works till line 464: 464 check_interface(filter, &IID_IMediaSeeking, FALSE); And the crash happens in dlls/winegstreamer/wg_parser.c in init_gstreamer_once(): 1673 if (!gst_init_check(&argc, &argv, &err)) I guess the good news is that I can crash the X server with: gst-play-1.0 no-such-file.avi And it turns out to be caused by the Xv support so a workaround is to uninstall the gstreamer1.0-vaapi package. Given that it's pretty basic functionality that's broken (though maybe it's a bad interaction with QXL) there's hope that it will be fixed in time. -- Francois Gouget <fgouget(a)codeweavers.com>

Jan. 12, 2023

Re: TestBot News: Missing dlls and VM updates

by Francois Gouget

On Tue, 10 Jan 2023, Bernhard Übelacker wrote: [...] > I tried to run a Xephyr server and run the tests of 8.0rc3 inside of it, > on top of a current Debian testing. > > Could you share more details if Xephyr is started with some parameters, > does it give a backtrace or core, and do you have a window manager running > inside Xephyr? The TestBot does not use Xephyr. It uses a regular X server with the QXL driver. ii xserver-common 2:21.1.6-1 all common files used by various X servers ii xserver-xorg 1:7.7+23 amd64 X.Org X server ii xserver-xorg-core 2:21.1.6-1 amd64 Xorg X server - core server ii xserver-xorg-video-qxl 0.1.5+git20200331-3 amd64 X.Org X server -- QXL display driver It also runs the fvwm window manager as described on the page below: https://wiki.winehq.org/Wine_TestBot_VMs#Unix_configuration ii fvwm 1:2.7.0-1 amd64 F(?) Virtual Window Manager Normally the tests run in a multi-monitor configuration but the crash also happens with a single monitor. There is a backtrace in /var/log/Xorg.0.log: [ 71.406] (EE) [ 71.406] (EE) Backtrace: [ 71.406] (EE) 0: /usr/lib/xorg/Xorg (OsLookupColor+0x139) [0x5648efd6bcc9] [ 71.406] (EE) 1: /lib/x86_64-linux-gnu/libc.so.6 (__sigaction+0x40) [0x7f807185af90] [ 71.406] (EE) 2: /lib/x86_64-linux-gnu/libc.so.6 (pthread_key_delete+0x14c) [0x7f80718a9ccc] [ 71.406] (EE) 3: /lib/x86_64-linux-gnu/libc.so.6 (gsignal+0x12) [0x7f807185aef2] [ 71.407] (EE) 4: /lib/x86_64-linux-gnu/libc.so.6 (abort+0xd3) [0x7f8071845472] [ 71.407] (EE) unw_get_proc_name failed: no unwind info found [-10] [ 71.407] (EE) 5: /lib/x86_64-linux-gnu/libc.so.6 (?+0x0) [0x7f8071845395] [ 71.407] (EE) 6: /lib/x86_64-linux-gnu/libc.so.6 (__assert_fail+0x42) [0x7f8071853df2] [ 71.407] (EE) 7: /usr/lib/xorg/Xorg (DRIMoveBuffersHelper+0xc33) [0x5648efd241e3] [ 71.407] (EE) 8: /usr/lib/xorg/Xorg (DRI2Authenticate+0xad) [0x5648efd2647d] [ 71.407] (EE) 9: /usr/lib/xorg/Xorg (DRI2GetParam+0x6cb) [0x5648efd271fb] [ 71.407] (EE) 10: /usr/lib/xorg/Xorg (SendErrorToClient+0x3d4) [0x5648efbf8734] [ 71.407] (EE) 11: /usr/lib/xorg/Xorg (InitFonts+0x3bc) [0x5648efbfc6cc] [ 71.407] (EE) 12: /lib/x86_64-linux-gnu/libc.so.6 (__libc_init_first+0x8a) [0x7f807184618a] [ 71.407] (EE) 13: /lib/x86_64-linux-gnu/libc.so.6 (__libc_start_main+0x85) [0x7f8071846245] [ 71.407] (EE) 14: /usr/lib/xorg/Xorg (_start+0x21) [0x5648efbe5b71] [ 71.407] (EE) [ 71.407] (EE) Fatal server error: [ 71.407] (EE) Caught signal 6 (Aborted). Server aborting > And does it happen on a specific wine test? It's enough to run the amstream:amstream test. -- Francois Gouget <fgouget(a)codeweavers.com>

Jan. 12, 2023

Re: TestBot News: Missing dlls and VM updates

by Bernhard Übelacker

Am 09.01.23 um 11:32 schrieb Francois Gouget: > On Fri, 6 Jan 2023, Bernhard Übelacker wrote: >> Does the X server still crash? > > It does. I also upgraded to unstable and it still crashed :-( > > [...] > 0454:fixme:d3d:wined3d_guess_card No card selector available for card vendor 0000 (using GL_RENDERER "llvmpipe (LLVM 15.0.6, 256 bits)"). > 0454:err:winediag:MIDIMAP_drvOpen No software synthesizer midi port found, Midi sound output probably won't work. > X connection to :0.0 broken (explicit kill or server shutdown). > X connection to :0.0 broken (explicit kill or server shutdown). > X connection to :0.0 broken (explicit kill or server shutdown). > X connection to :0.0 broken (explicit kill or server shutdown). > X connection to :0.0 broken (explicit kill or server shutdown). > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1027026 The Debian bug given seems not directly connected to a crashing X server, is there another report known? I tried to run a Xephyr server and run the tests of 8.0rc3 inside of it, on top of a current Debian testing. Could you share more details if Xephyr is started with some parameters, does it give a backtrace or core, and do you have a window manager running inside Xephyr? And does it happen on a specific wine test? I am currently running the test suite with "make test -k", but received no crash, but am currently just in dlls/k* tests. Kind regards, Bernhard

Jan. 10, 2023

Re: FOSDEM 2023

by Gijs Vermeulen

Op ma 9 jan. 2023 om 11:44 schreef Henri Verbeet <hverbeet(a)gmail.com>: > Is anyone else already planning to attend this year? > I will definitely be attending. Kind regards, Gijs

Jan. 9, 2023

FOSDEM 2023

by Henri Verbeet

This year FOSDEM will once again take place in Brussels, on February 4 and 5. The Wine project won't have an official presence at the conference this year, but a (modest) number of us do intend to visit Brussels during that time. Is anyone else already planning to attend this year? Like previous conferences, you'll be able to find most of us in the #wineconf:matrix.org Matrix room. Henri

Jan. 9, 2023

Re: TestBot News: Missing dlls and VM updates

by Francois Gouget

On Fri, 6 Jan 2023, Bernhard Übelacker wrote: [...] > If I see it right, then there should be already 1:15.0.6-4+b1 > in testing in amd64 and i386, so it should be co-installable again? > Does the X server still crash? It does. I also upgraded to unstable and it still crashed :-( [...] 0454:fixme:d3d:wined3d_guess_card No card selector available for card vendor 0000 (using GL_RENDERER "llvmpipe (LLVM 15.0.6, 256 bits)"). 0454:err:winediag:MIDIMAP_drvOpen No software synthesizer midi port found, Midi sound output probably won't work. X connection to :0.0 broken (explicit kill or server shutdown). X connection to :0.0 broken (explicit kill or server shutdown). X connection to :0.0 broken (explicit kill or server shutdown). X connection to :0.0 broken (explicit kill or server shutdown). X connection to :0.0 broken (explicit kill or server shutdown). -- Francois Gouget <fgouget(a)codeweavers.com>

Jan. 9, 2023

Wine staging 8.0-rc3 release

by Alistair Leslie-Hughes

Binary packages for various distributions will be available from: https://www.winehq.org/download Summary since last release * Rebased to current wine 8.0-rc3 (474 patches are applied to wine vanilla) Upstreamed (Either directly from staging or fixed with a similar patch). * none Added: * None Updated: * ntdll-Junction_Points * winex11-_NET_ACTIVE_WINDOW * ntdll-NtDevicePath Where can you help * Run Steam/Battle.net/GOG/UPlay/Epic * Test your favorite game. * Test your favorite applications. * Improve staging patches and get them accepted upstream. * Suggest patches to be included in staging. As always, if you find a bug, please report it via https://bugs.winehq.org Best Regards Alistair.

Jan. 8, 2023

Re: TestBot News: Missing dlls and VM updates

by Bernhard Übelacker

Am 05.01.23 um 15:33 schrieb Francois Gouget: > On Thu, 22 Dec 2022, Rémi Bernon wrote: > >> On 12/22/22 01:57, Francois Gouget wrote: >>> >>> Another point is that updating the X11 / Mesa packages causes the X >>> server to crash during the Direct 3D tests. So for now that VM is >>> frozen in time. That's all worrying for the future Debian 12. >>> >> I don't know if it's related but I recently had to forcefully set >> GALLIUM_DRIVER=llvmpipe environment variable when running stuff on Xephyr or >> over ssh X11 forwarding. Otherwise Mesa was crashing trying to instantiate a >> d3d12 driver (!!). > > Unfortunately, this did not help with Debian Testing :-( > > ... > 0470:fixme:d3d:wined3d_guess_card No card selector available for card vendor 0000 (using GL_RENDERER "llvmpipe (LLVM 14.0.4, 256 bits)"). > 0470:err:winediag:MIDIMAP_drvOpen No software synthesizer midi port found, Midi sound output probably won't work. > X connection to :0.0 broken (explicit kill or server shutdown). > X connection to :0.0 broken (explicit kill or server shutdown). > X connection to :0.0 broken (explicit kill or server shutdown). > X connection to :0.0 broken (explicit kill or server shutdown). > X connection to :0.0 broken (explicit kill or server shutdown). > > That said Debian Testing broke the libllvm15 package because it requires > exactly the same version for the 32- and 64-bit packages (which is > reasonable), but they rebuilt just the 32-bit package resulting in a > version mismatch (15.0.6-3+b1 vs. 15.0.6-3). In turn that blocks a bunch > of packages from upgrading but I'm not sure it would be any better if > they did get upgraded. > > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1027026 If I see it right, then there should be already 1:15.0.6-4+b1 in testing in amd64 and i386, so it should be co-installable again? Does the X server still crash? https://packages.debian.org/bookworm/libllvm15 https://snapshot.debian.org/binary/libllvm15/

Jan. 6, 2023

Re: HiDPI / Scaling window content

by Jordan Johnston

Hey Stefan, > We're generally interested in fixing these kinds of regressions, and also > > performance regressions. Did you file bugs for them? (I see your comment > on > > 46056; sounds complicated indeed) > Generally, because I use heavily modified code / fork-of-wine I do not file bug reports, unless I can reproduce them on vanilla wine (or Staging). Occasionally, I will reach out to the author of a particular related patchset, or something like that -- but I don't want to be spamming/filing invalid bug reports. ( I know the rules ). Yup, using Wine to run heavily multithreaded proaudio software is a pain / complicated to do... People have tried to fix it all via Winelib apps / bridging - but fundamentally, that's not the (full/proper) solution. Wine itself needs to be patched / fixed, because even with bridges, you will eventually hit a wall due to limitations in Wine. I'm sure you remember the Muse Receptor folks? (Wine 1.x era) and the kinds of hacks they used to employ? (unix pipe synchronization per app, setting realtime from without wineserver, RT hacks in kernel32, specifically compiled libs/windows dlls, etc)... or the Wine-RT patch that lives in Staging? it seems every few years, new ideas/implementations/code rolls out that helps improve the situation... but much of it never makes it upstream (often for very valid reasons. eg: too platform-specific. too hackish. etc). Lots of handy patchwork floating around these days; stuff in Proton.. Zeb's Esync/Fsync code.. Lots of Remi Bernon's work (LFH, keyed_events+futexes, and so on).. Some of Torge Matthies' patchwork; especially that killer multithreaded wineserver patchwork (shmem per thread for requests/replies)... but I still needed further hacks on his code; dropping his spinning code (it stalls apps like NI Kontakt), AND I had to set up these threads' pthread attributes for RT (as his code sets them to NULL)... This further demonstrates why I can't really file report bugs, to a large extent... It's kind of a pain, but at least I can run my apps with great success. That said, maybe when I rebase during Wine-8.x development cycle, I can test against Wine-Staging and at least do some bug reports, where applicable. > > If they are highly use-case specific, like you depend on old versions of > Linux > > libraries or whatever, we might not be able to address them, still we'd > love > > to hear about them. > Highly use-case specific in that I only care about running Proaudio apps (for personal use). I will make use of any kernel or userland functionality/advantage to do so. I will employ hacks in Wine, when needed (even if a bit icky and tricky)... But no, I don't use any kind of proprietary Winelib apps, no odd-ball compilers or anything like that... I use Archlinux, a fairly vanilla system, and While I do use a custom kernel, nothing too exotic: Preempt-rt (6.0.x), some backports from 6.1/2, a few other bits (stuff that is, or will be upstream)... For me, the 3 biggest things that I would like to see upstream Wine implement / support are: #1 - better handling of Windows Synchronization primitives (this is tricky to not be platform-specific.) #2 - Proper mapping of Windows Scheduling to Linux/Unix Scheduling (both nicess AND RT scheduling) #3 - Multi-threaded Wineserver (requests, replies and APCs are a huge bottleneck for single-threaded wineserver) I have things in place to handle all of these things (to varying degrees), but it's all very hackish and certainly not suitable for upstream... I understand a lot of the challenges for upstream here, none of the above are easy to address - but are all showstopping issues with being able to use Vanilla Wine, or even Staging. Honestly I hope upstream reconsiders multi-threaded wineserver at some > point. I know it's single-threaded for stability/simplicity, but it's a > real bottleneck in some cases. > I hope so too, Gabriel... Personally, I think Torge's multithreaded wineserver code demonstrates that there could be some viable solution. ~ I've had ZERO instability using those patches (initial issue aside). ~ I'd like to see an approach like that, but one that also handles APCs too... Lots of things can be handled by a single thread, but the server requests/replies && APCs can't be, at least not when using some heavier applications. (Ableton Live 11 is a fantastic example, as are certain VSTs). Cheers, sorry for the lengthy rant guys ;-) Jordan

Jan. 6, 2023

Re: HiDPI / Scaling window content

by Gabriel Ivăncescu

On 06/01/2023 10:20, Stefan Dösinger wrote: > Am Freitag, 6. Jänner 2023, 07:34:10 EAT schrieb Jordan Johnston: > >> Sticking with an older version of wine due to better performance + >> avoiding some regressions for my particular usage. > > We're generally interested in fixing these kinds of regressions, and also > performance regressions. Did you file bugs for them? (I see your comment on > 46056; sounds complicated indeed) > > If they are highly use-case specific, like you depend on old versions of Linux > libraries or whatever, we might not be able to address them, still we'd love > to hear about them. > > > > Honestly I hope upstream reconsiders multi-threaded wineserver at some point. I know it's single-threaded for stability/simplicity, but it's a real bottleneck in some cases.

Jan. 6, 2023

Re: HiDPI / Scaling window content

by Stefan Dösinger

Am Freitag, 6. Jänner 2023, 07:34:10 EAT schrieb Jordan Johnston: > Sticking with an older version of wine due to better performance + > avoiding some regressions for my particular usage. We're generally interested in fixing these kinds of regressions, and also performance regressions. Did you file bugs for them? (I see your comment on 46056; sounds complicated indeed) If they are highly use-case specific, like you depend on old versions of Linux libraries or whatever, we might not be able to address them, still we'd love to hear about them.

Jan. 6, 2023

Re: HiDPI / Scaling window content

by Jordan Johnston

Hey Zhiyi, I'll give these a try. Thanks! ~ this patchset being a bit older, it probably will line up a bit better with wine-7.5. hopefully, it's mostly trivial stuff to fixup, as you mention with the NtUser* bits. We shall see ;-) (and actually your current iteration isn't that far off, either). With any luck, tomorrow I should be able to give this code a spin. I appreciate you getting back to me. Super helpful and very much appreciated. Jordan On Thu, Jan 5, 2023 at 11:23 PM Zhiyi Zhang <zzhang(a)codeweavers.com> wrote: > Hi Jordan, > > Sorry, I didn't keep an older branch. I did find a older version of the > patches around April 2022 > that should help you to backport these commits to 7.5. I didn't try if > these old patches apply cleanly > 7.5 or work at all. They should be use only as reference for backporting. > What you mostly need is > to replace NtUser* functions to original user32 functions. So the work > shouldn't be too difficult. > > Thanks, > Zhiyi > > On 1/6/23 11:24, Jordan Johnston wrote: > > Hey Zhiyi, > > > > You mention having originally done this work about a year ago ~ Do you > > happen to have an older iteration of the patchwork? - I ask because > > currently, I am using a somewhat heavily modified version of Wine-7.5 > (also > > it also predates the 32on64 work, and various functions being renamed. > eg: > > NtUser*, props stuff, etc)... An older iteration may actually apply more > > cleanly, not require as much to do. > > > > Sticking with an older version of wine due to better performance + > avoiding > > some regressions for my particular usage. > > > > The bugs sound fairly minor, and your patchwork does seem like what I"m > > probably after most likely. I'm super intrigued. -- Please let me know if > > you can dig up non-rebased (on upstream/8.0-rc2) patchwork.. I'd be > super > > eager to try that out, before trying to rebase/backport to Wine-7.5 > > > > Thanks a million! > > > > Jordan > > > > On Thu, Jan 5, 2023 at 9:19 PM Zhiyi Zhang <zzhang(a)codeweavers.com> > wrote: > > > >> Hi Jordan, > >> > >> I did work on GDI unaware scaling for HiDPI support about a year ago. > The > >> idea is that > >> winex11.drv scales windows for those applications that doesn't really > >> support HiDPI > >> but the monitor is using a DPI higher than 96. Basically, winex11.drv > >> hides unscaled > >> windows and use XDamage and XRender extension to scale the content to a > >> new X window > >> that will be actually shown. > >> > >> I have a branch at > >> https://github.com/zzhiyi/wine/commits/gdi-unaware-scaling and it > doesn't > >> work > >> right now because of the 32on64 work that moves some user32 function > into > >> win32u. > >> Specifically, I need to fix the compilation error in > >> is_dpi_unaware_scaling_required(). But maybe > >> you can just hack it to return TRUE to make it work. You also need to > set > >> DPI in winecfg to 192 for example. > >> Then things should generally work although there are some bugs need to > be > >> fixed. For example, > >> launching application after wine prefix creation somehow hides the > cursor. > >> And it breaks some d3d tests. > >> > >> Now that 32on64 work has quite down for winex11.drv, I think I am resume > >> this work. > >> I may revisit this and try to upstream this in the near future. > >> > >> You might want to try https://github.com/kaueraal/run_scaled as well. > >> > >> Thanks, > >> Zhiyi > >> > >> On 1/5/23 23:32, Jordan Johnston wrote: > >>> Hey all, > >>> > >>> I'm looking for some pointers on coming up with a hack to better > support > >>> HiDPI with wine on my hi-res display (not something that would be > >> submitted > >>> upstream. "hack" indeed)... As you are all probably aware; while you > can > >>> adjust DPI in Winecfg, that only affects Windows UI elements ~ but It > >> does > >>> not help with anything outside of that... I have some apps that are > >>> basically unusable with HiDPI and i've tried multiple solutions, to no > >>> avail. (and setting my resolution to 1440x900 isn't a viable solution > >>> either). > >>> > >>> I've been poking around dlls/winex11.drv and I'm wondering if anyone > >> might > >>> have pointers on how some of the scale related stuff works? -- I'm > >>> wondering if it may be possible to hack the x11 code to multiply the > >> scale > >>> of the window contents? (and perhaps, I can then wrap it in an env > >> variable > >>> for use)... > >>> > >>> If anyone has any pointers, or if they think something like this could > >> work > >>> -- I'd appreciate your insights (again, I'm just looking for kind of a > >>> one-off hack, not something upstream-able.. I'm sure HiDPI > >>> compatibility-mode will land upstream, at some point (Windows has > this)). > >>> While I am familiar with some of Wine's internals - the graphics stack, > >>> window management / x11 code is somewhat alien to me. > >>> > >>> Alternatively, i suppose if someone is working on related code and has > a > >>> git branch / patchwork available, I'd be open to try that out too. > >>> > >>> Thanks, and Happy New Year to you all! > >>> > >>> Jordan > >>> > >>> > >>> > >> >

Jan. 6, 2023

Re: HiDPI / Scaling window content

by Zhiyi Zhang

Hi Jordan, Sorry, I didn't keep an older branch. I did find a older version of the patches around April 2022 that should help you to backport these commits to 7.5. I didn't try if these old patches apply cleanly 7.5 or work at all. They should be use only as reference for backporting. What you mostly need is to replace NtUser* functions to original user32 functions. So the work shouldn't be too difficult. Thanks, Zhiyi On 1/6/23 11:24, Jordan Johnston wrote: > Hey Zhiyi, > > You mention having originally done this work about a year ago ~ Do you > happen to have an older iteration of the patchwork? - I ask because > currently, I am using a somewhat heavily modified version of Wine-7.5 (also > it also predates the 32on64 work, and various functions being renamed. eg: > NtUser*, props stuff, etc)... An older iteration may actually apply more > cleanly, not require as much to do. > > Sticking with an older version of wine due to better performance + avoiding > some regressions for my particular usage. > > The bugs sound fairly minor, and your patchwork does seem like what I"m > probably after most likely. I'm super intrigued. -- Please let me know if > you can dig up non-rebased (on upstream/8.0-rc2) patchwork.. I'd be super > eager to try that out, before trying to rebase/backport to Wine-7.5 > > Thanks a million! > > Jordan > > On Thu, Jan 5, 2023 at 9:19 PM Zhiyi Zhang <zzhang(a)codeweavers.com> wrote: > >> Hi Jordan, >> >> I did work on GDI unaware scaling for HiDPI support about a year ago. The >> idea is that >> winex11.drv scales windows for those applications that doesn't really >> support HiDPI >> but the monitor is using a DPI higher than 96. Basically, winex11.drv >> hides unscaled >> windows and use XDamage and XRender extension to scale the content to a >> new X window >> that will be actually shown. >> >> I have a branch at >> https://github.com/zzhiyi/wine/commits/gdi-unaware-scaling and it doesn't >> work >> right now because of the 32on64 work that moves some user32 function into >> win32u. >> Specifically, I need to fix the compilation error in >> is_dpi_unaware_scaling_required(). But maybe >> you can just hack it to return TRUE to make it work. You also need to set >> DPI in winecfg to 192 for example. >> Then things should generally work although there are some bugs need to be >> fixed. For example, >> launching application after wine prefix creation somehow hides the cursor. >> And it breaks some d3d tests. >> >> Now that 32on64 work has quite down for winex11.drv, I think I am resume >> this work. >> I may revisit this and try to upstream this in the near future. >> >> You might want to try https://github.com/kaueraal/run_scaled as well. >> >> Thanks, >> Zhiyi >> >> On 1/5/23 23:32, Jordan Johnston wrote: >>> Hey all, >>> >>> I'm looking for some pointers on coming up with a hack to better support >>> HiDPI with wine on my hi-res display (not something that would be >> submitted >>> upstream. "hack" indeed)... As you are all probably aware; while you can >>> adjust DPI in Winecfg, that only affects Windows UI elements ~ but It >> does >>> not help with anything outside of that... I have some apps that are >>> basically unusable with HiDPI and i've tried multiple solutions, to no >>> avail. (and setting my resolution to 1440x900 isn't a viable solution >>> either). >>> >>> I've been poking around dlls/winex11.drv and I'm wondering if anyone >> might >>> have pointers on how some of the scale related stuff works? -- I'm >>> wondering if it may be possible to hack the x11 code to multiply the >> scale >>> of the window contents? (and perhaps, I can then wrap it in an env >> variable >>> for use)... >>> >>> If anyone has any pointers, or if they think something like this could >> work >>> -- I'd appreciate your insights (again, I'm just looking for kind of a >>> one-off hack, not something upstream-able.. I'm sure HiDPI >>> compatibility-mode will land upstream, at some point (Windows has this)). >>> While I am familiar with some of Wine's internals - the graphics stack, >>> window management / x11 code is somewhat alien to me. >>> >>> Alternatively, i suppose if someone is working on related code and has a >>> git branch / patchwork available, I'd be open to try that out too. >>> >>> Thanks, and Happy New Year to you all! >>> >>> Jordan >>> >>> >>> >>

Jan. 6, 2023

Re: HiDPI / Scaling window content

by Jordan Johnston

Hey Zhiyi, You mention having originally done this work about a year ago ~ Do you happen to have an older iteration of the patchwork? - I ask because currently, I am using a somewhat heavily modified version of Wine-7.5 (also it also predates the 32on64 work, and various functions being renamed. eg: NtUser*, props stuff, etc)... An older iteration may actually apply more cleanly, not require as much to do. Sticking with an older version of wine due to better performance + avoiding some regressions for my particular usage. The bugs sound fairly minor, and your patchwork does seem like what I"m probably after most likely. I'm super intrigued. -- Please let me know if you can dig up non-rebased (on upstream/8.0-rc2) patchwork.. I'd be super eager to try that out, before trying to rebase/backport to Wine-7.5 Thanks a million! Jordan On Thu, Jan 5, 2023 at 9:19 PM Zhiyi Zhang <zzhang(a)codeweavers.com> wrote: > Hi Jordan, > > I did work on GDI unaware scaling for HiDPI support about a year ago. The > idea is that > winex11.drv scales windows for those applications that doesn't really > support HiDPI > but the monitor is using a DPI higher than 96. Basically, winex11.drv > hides unscaled > windows and use XDamage and XRender extension to scale the content to a > new X window > that will be actually shown. > > I have a branch at > https://github.com/zzhiyi/wine/commits/gdi-unaware-scaling and it doesn't > work > right now because of the 32on64 work that moves some user32 function into > win32u. > Specifically, I need to fix the compilation error in > is_dpi_unaware_scaling_required(). But maybe > you can just hack it to return TRUE to make it work. You also need to set > DPI in winecfg to 192 for example. > Then things should generally work although there are some bugs need to be > fixed. For example, > launching application after wine prefix creation somehow hides the cursor. > And it breaks some d3d tests. > > Now that 32on64 work has quite down for winex11.drv, I think I am resume > this work. > I may revisit this and try to upstream this in the near future. > > You might want to try https://github.com/kaueraal/run_scaled as well. > > Thanks, > Zhiyi > > On 1/5/23 23:32, Jordan Johnston wrote: > > Hey all, > > > > I'm looking for some pointers on coming up with a hack to better support > > HiDPI with wine on my hi-res display (not something that would be > submitted > > upstream. "hack" indeed)... As you are all probably aware; while you can > > adjust DPI in Winecfg, that only affects Windows UI elements ~ but It > does > > not help with anything outside of that... I have some apps that are > > basically unusable with HiDPI and i've tried multiple solutions, to no > > avail. (and setting my resolution to 1440x900 isn't a viable solution > > either). > > > > I've been poking around dlls/winex11.drv and I'm wondering if anyone > might > > have pointers on how some of the scale related stuff works? -- I'm > > wondering if it may be possible to hack the x11 code to multiply the > scale > > of the window contents? (and perhaps, I can then wrap it in an env > variable > > for use)... > > > > If anyone has any pointers, or if they think something like this could > work > > -- I'd appreciate your insights (again, I'm just looking for kind of a > > one-off hack, not something upstream-able.. I'm sure HiDPI > > compatibility-mode will land upstream, at some point (Windows has this)). > > While I am familiar with some of Wine's internals - the graphics stack, > > window management / x11 code is somewhat alien to me. > > > > Alternatively, i suppose if someone is working on related code and has a > > git branch / patchwork available, I'd be open to try that out too. > > > > Thanks, and Happy New Year to you all! > > > > Jordan > > > > > > > >

Jan. 6, 2023

Re: HiDPI / Scaling window content

by Zhiyi Zhang

Hi Jordan, I did work on GDI unaware scaling for HiDPI support about a year ago. The idea is that winex11.drv scales windows for those applications that doesn't really support HiDPI but the monitor is using a DPI higher than 96. Basically, winex11.drv hides unscaled windows and use XDamage and XRender extension to scale the content to a new X window that will be actually shown. I have a branch at https://github.com/zzhiyi/wine/commits/gdi-unaware-scaling and it doesn't work right now because of the 32on64 work that moves some user32 function into win32u. Specifically, I need to fix the compilation error in is_dpi_unaware_scaling_required(). But maybe you can just hack it to return TRUE to make it work. You also need to set DPI in winecfg to 192 for example. Then things should generally work although there are some bugs need to be fixed. For example, launching application after wine prefix creation somehow hides the cursor. And it breaks some d3d tests. Now that 32on64 work has quite down for winex11.drv, I think I am resume this work. I may revisit this and try to upstream this in the near future. You might want to try https://github.com/kaueraal/run_scaled as well. Thanks, Zhiyi On 1/5/23 23:32, Jordan Johnston wrote: > Hey all, > > I'm looking for some pointers on coming up with a hack to better support > HiDPI with wine on my hi-res display (not something that would be submitted > upstream. "hack" indeed)... As you are all probably aware; while you can > adjust DPI in Winecfg, that only affects Windows UI elements ~ but It does > not help with anything outside of that... I have some apps that are > basically unusable with HiDPI and i've tried multiple solutions, to no > avail. (and setting my resolution to 1440x900 isn't a viable solution > either). > > I've been poking around dlls/winex11.drv and I'm wondering if anyone might > have pointers on how some of the scale related stuff works? -- I'm > wondering if it may be possible to hack the x11 code to multiply the scale > of the window contents? (and perhaps, I can then wrap it in an env variable > for use)... > > If anyone has any pointers, or if they think something like this could work > -- I'd appreciate your insights (again, I'm just looking for kind of a > one-off hack, not something upstream-able.. I'm sure HiDPI > compatibility-mode will land upstream, at some point (Windows has this)). > While I am familiar with some of Wine's internals - the graphics stack, > window management / x11 code is somewhat alien to me. > > Alternatively, i suppose if someone is working on related code and has a > git branch / patchwork available, I'd be open to try that out too. > > Thanks, and Happy New Year to you all! > > Jordan > > >

Jan. 6, 2023

HiDPI / Scaling window content

by Jordan Johnston

Hey all, I'm looking for some pointers on coming up with a hack to better support HiDPI with wine on my hi-res display (not something that would be submitted upstream. "hack" indeed)... As you are all probably aware; while you can adjust DPI in Winecfg, that only affects Windows UI elements ~ but It does not help with anything outside of that... I have some apps that are basically unusable with HiDPI and i've tried multiple solutions, to no avail. (and setting my resolution to 1440x900 isn't a viable solution either). I've been poking around dlls/winex11.drv and I'm wondering if anyone might have pointers on how some of the scale related stuff works? -- I'm wondering if it may be possible to hack the x11 code to multiply the scale of the window contents? (and perhaps, I can then wrap it in an env variable for use)... If anyone has any pointers, or if they think something like this could work -- I'd appreciate your insights (again, I'm just looking for kind of a one-off hack, not something upstream-able.. I'm sure HiDPI compatibility-mode will land upstream, at some point (Windows has this)). While I am familiar with some of Wine's internals - the graphics stack, window management / x11 code is somewhat alien to me. Alternatively, i suppose if someone is working on related code and has a git branch / patchwork available, I'd be open to try that out too. Thanks, and Happy New Year to you all! Jordan

Jan. 5, 2023

Re: TestBot News: Missing dlls and VM updates

by Francois Gouget

On Thu, 22 Dec 2022, Rémi Bernon wrote: > On 12/22/22 01:57, Francois Gouget wrote: > > > > Another point is that updating the X11 / Mesa packages causes the X > > server to crash during the Direct 3D tests. So for now that VM is > > frozen in time. That's all worrying for the future Debian 12. > > > I don't know if it's related but I recently had to forcefully set > GALLIUM_DRIVER=llvmpipe environment variable when running stuff on Xephyr or > over ssh X11 forwarding. Otherwise Mesa was crashing trying to instantiate a > d3d12 driver (!!). Unfortunately, this did not help with Debian Testing :-( ... 0470:fixme:d3d:wined3d_guess_card No card selector available for card vendor 0000 (using GL_RENDERER "llvmpipe (LLVM 14.0.4, 256 bits)"). 0470:err:winediag:MIDIMAP_drvOpen No software synthesizer midi port found, Midi sound output probably won't work. X connection to :0.0 broken (explicit kill or server shutdown). X connection to :0.0 broken (explicit kill or server shutdown). X connection to :0.0 broken (explicit kill or server shutdown). X connection to :0.0 broken (explicit kill or server shutdown). X connection to :0.0 broken (explicit kill or server shutdown). That said Debian Testing broke the libllvm15 package because it requires exactly the same version for the 32- and 64-bit packages (which is reasonable), but they rebuilt just the 32-bit package resulting in a version mismatch (15.0.6-3+b1 vs. 15.0.6-3). In turn that blocks a bunch of packages from upgrading but I'm not sure it would be any better if they did get upgraded. https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1027026 -- Francois Gouget <fgouget(a)codeweavers.com>

Jan. 5, 2023