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

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