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
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
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@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
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@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
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@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@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
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.
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.
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
-
Gabriel Ivăncescu -
Jordan Johnston -
Stefan Dösinger -
Zhiyi Zhang