-
Notifications
You must be signed in to change notification settings - Fork 343
xwayland: hidpi support #2064
base: master
Are you sure you want to change the base?
xwayland: hidpi support #2064
Conversation
I don't think wlroots should become an xsettings deamon. Also this is a GTK-specific setting. |
Edit: While this only implements correct scaling for GTK3 applications, all other xwayland windows will be unscaled and therefore look tiny on all screens. The |
We will be able to programmatically change the global x scale factor in an automatic fashion? So, when I unplug my scale 1 external display and move to my scale 2 hidpi laptop display, we will be able to automatically adjust the global x scale factor to 2 making all xwayland apps perfectly clear and not blocky (nearest neighborry)? Also, would it be too much trouble to add one of the jetbrains IDEs into the testing mix? They seem to have different sorts of issues than the electron apps. EDIT Also... thank you very much for taking a shot at this! |
I 100% agree with you @emersion . How about structuring it this way?
For static setups, the user can just set If you give me the OK to this (having the scale factor but not xsettings) I can try to work with the x people to get the x patches merged, so we can move this forward.
You can set xwayland scale to 1x even if your output is hidpi. If you set it to 1x, the behavior is identical as before: you get blurry windows in hidpi outputs but GIMP & co work great.
This should probably go in an external tool. There's already precedent of not adding such dynamic configuration features to wlroots/sway, for example for configuring output scales and positions there's kanshi. I guess it should be a new tool (not kanshi), since kanshi aims to depend just on the |
Yeah, I like this plan!
Cool! |
@Dirbaio re:
What would the workflow look like then if it wasn't automattic? Would it be an imperative action on the users part to "resync" the xwayland window's scale? Or are you thinking more of a daemon? Isn't xwayland sorta the external tool in this situation? |
@Dirbaio: @ofourdan is planning on integrating the Xwayland MR with Mutter. Do you want to submit a cleaned-up Xwayland MR with your changes?
An xsettings daemon, which could be re-configured on-the-fly with e.g. kanshi. |
Hi! I’m curious, what’s the state on the PR and on the Xorg state? What can be done to help? |
It would be nice to submit a cleaned-up Xwayland MR, then patch this PR to perform the changes described here: #2064 (comment) |
This does the necessary changes to support HiDPI in xwayland applications, with the following xwayland patch: https://gitlab.freedesktop.org/xorg/xserver/merge_requests/111
Since xsettings code is removed, users now need to run their own xsettings daemon, such as xsettingsd with a scale matching the xwayland scale, or text will look too small. One pending thing in the wlroots side is how to handle X servers that don't support scaling. This is currently broken. I was thinking about adding a function |
Now that the built-in xsettings is gone, here are some configuration instructions to get it working! Static configUse this if you just want to set a fixed scale (e.g. fixed setup with desktop computer and 4k monitor at scale 2) Put this in
Put this in
Dynamic config with
|
Wow. It’s working, and it’s amazing. Thank you so much. For testers: I’ve created three ugly AUR packages with the three pull requests. Try xorg-server-hidpi-git, wlroots-hidpi-git, sway-hidpi-git. I’ll remove them once everything’s merged. There’s only one thing weird in my setup: in emacs the mouse is huge. It could be 2 or 4 times its normal size. This is not happening with Chromium. My profile (both screens are 4K but the Acer is 28"):
I’m assuming that I need to keep in
|
Thanks so much for the update @Dirbaio, nice work!
Either that, or we could make |
OK, so I compiled @MisterDA repos, and got it working. What I noticed: Programs like rofi, or games running via Wine, are trying to run in 4K mode. I noticed when I move window to FullHD monitor, game/app still runs in 4K, just get downscaled, but this is not issue. That way we can have all what really everybody wants to have. I mean, rofi and game which I run in Wine gets everything really small on 4K. |
Thanks very much for these AUR packages. I did some quick testing on Arch, and it seems to not behave well with Flatpaks:
I'll reapply the patches and do some better testing including any error messages when I have more time. I didn't have "*.dpi: 192" in my .Xresources, and I also have my xsettingsd config in ~/.xsettingsd rather than in /.config/xsettingsd/xsettingsd.conf - I'm not sure if either of those could be an issue. |
Thanks a lot. This works like a charm in my mixed dpi setup. FInally I can use X apps without blurry fonts on the hidpi screen. This will be a huge step forward, a lot of people are waiting for this... |
Thank you so much for creating those AUR packages! Works great on my XPS 9570 4k. |
This comment has been minimized.
This comment has been minimized.
I've done some more testing, and the only two apps not working for me are the Firefox Flatpak and the Minecraft Flatpak. Firefox flatpak (wayland native) looks like this, all UI elements are just weird squiggly lines: For the Minecraft flatpak (Xwayland), the launcher opens, but when I run the game itself I get this in the launcher log and no game:
Other applications (Firefox non-flatpak, Minecraft from AUR (xwayland), LibreOffice flatpak, Sublime flatpak, Steam Client flatpak (xwayland), Kerbal Space Program (xwayland)) are working fine. |
This comment has been minimized.
This comment has been minimized.
This sounds unrelated to this PR. |
This comment has been minimized.
This comment has been minimized.
Pulling the latest master of sway/wlroots and applying the patches myself seems to have resolved the issue. Not sure what the underlying cause is at this point. I did try them on another machine as well with an |
From the Arch wiki
|
Does anyone know if this has been packaged for Fedora in any way? |
This draft indeed works really great! Thanks for the Arch AUR packages also, which I am using on Arch Linux. I just have one issue, though: the mouse cursor is really tiny for me in the XWayland clients. The cursor appears half the normal size, or maybe even less. I am using I am running
Some config files:
I tried setting such a ridiculously large cursor size (48), but it doesn't seem to have any effect. If I set My packages:
Any ideas? Thanks in advance. |
@zsolt-donca Unfortunately for Wayland and XWayland, the Xorg standard in use there has this annoying feature. The only way to broadcast the cursor sizes is either through environment variables, or through an X settings daemon. Neither way supports mixed scale factors. And if you're on the latest Sway or Wayfire, both set this environment variable assuming a scale factor of 1, so anything larger, and your cursors will be tiny. In fact, the higher the scale factor, the tinier the cursors. Especially bad considering that these attempts to support HiDPI involve Xwayland having a fixed scale factor across all displays. So I guess this means that cursors for Xwayland should be scaled up rather than assume HiDPI support? Can't have HiDPI cursors, the DE or compositor tell it to use a tiny cursor. |
@kode54 Thanks! That makes sense, and confirm the behavior I am experiencing. I also managed to confirm this by setting the env variable XCURSOR_SIZE=48 before launching some XWayland-clients, and it indeed set the correct cursor size. I'll be bringing this issue up sway's MR swaywm/sway#5090 - I hope we'll find an appropriate fix. |
@kode54 I've investigated the issue in swaywm, and found (see this comment) that the issue cannot simply be handled by swaywm setting a larger The solution that I can think of is that the (wlroots-based) compositor would automatically scale the mouse cursor for the XWayland clients, according to the display's scale factor. After all, this happens automatically for wayland-native apps. What do you think? |
I am just an outside observer, but I am really excited about this feature. JetBrains apps is what I really miss on sway. So I hope this feature will make those apps usable on HiDPI screens. |
I can confirm that this patch, along with its counterparts in wlroots and in xwayland, do indeed make the JetBrains tools usable! Quite so that these builds became my daily driver in my production machine, where I am a heavy IntellIJ IDEA user. The only issues that I have are quite minor: the cursor size issue that I mentioned above (there is the workaround setting XCURSOR_SIZE just for this process), and another issue with regards to the sizes of some dialog windows, but nothing critical. The performance of IntelliJ IDEA is also great, at least in my setup with a xwayland's scaling factor set to 2 and with an external 4K display with scaling set to 1.5. This effectively means that the external display has a 5K resolution (5120 × 2880), scaled down by sway to 4K. Even though I think I might sense some slowndown, the effect is very small and not very noticeable. In my opinion, this feature is what will finally bring the HiDPI support that Linux needs, making the platform on-par with alternatives such as Windows and MacOS. |
This basically is precisely how its done in MacOS from what I heard? |
I can't find the patches you mentioned. Can you point me into the right direction? I want to test them with CLion. A bit off-topic question: how do you solve the problem with JetBrains apps on sway where after an auto-completion a cursor disappears from the editor and you can't type anymore until you mouse-click in the editor? I tried various idea settings but nothing seems to work./ |
|
I don't have this issue at all. Just tested with CLion also, and the cursor does not disappear for me when using auto-completion, and, in fact, at all. The funny thing is that it used to do something like that under |
@ngortheone
Sorry for the off-topic. |
Re: Jetbrains issues: it looks like a PR was just merged into master which solves some issues with the way focusing is handled with Jetbrains IDEs. Further info here swaywm/sway#3007 (comment) You may be able to get hidpi support with proper jetbrains functionality by rebasing the respective |
@ngortheone @zsolt-donca I've merged the latest |
@caleb-allen what is your estimate when this branch is going to be merged into master? |
It's waiting for the XWayland changes to be merged first, which unfortunately don't seem to be going anywhere, read the conversation: https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/432 |
This comment has been minimized.
This comment has been minimized.
This is simply and factually untrue. |
I don't see anything unresolvable there. Everyone seems to be acting in good faith and with overlapping goals, so I'm sure if enough people keep putting effort into it it will get somewhere. Since then @ofourdan has jumped in with some constructive criticism that looks useful (thankyou for your efforts!), so the way is open to consider/discuss that and find a way forward: https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/432#note_787005 |
I certainly didn't mean to imply otherwise :) I would have contributed with effort of my own had I the experience to contribute meaningfully. |
Does this patch still work on latest release? |
I tried the latest from the AUR, and Ozone enabled (Wayland native) Chromium-based apps (Brave, and all Electron apps with the Ozone flags) crash with this patch. If I just run them with XWayland, then they work fine, or without the patch, both Ozone and XWayland work. I'm on a fully updated Arch, and I'm using the I'd go with Wayland native with whatever has it, but JetBrains IDEs work well only with these HiDPI patches. |
So I'm not the only one! It started happening recently (last month or so?). I don't have a clue how to investigate… |
I see someone has started a new MR as an attempt to get the ball rolling again: Best of luck to them. |
I experience the same thing on VSCode - I think it's related to this issue: #3168 |
I can confirm that it's the same issue. Reverting commit d290b13 over the current master and applying the codebase in this pull request works correctly for me, Chromium-based apps work just fine. |
I had a few segfaults that I could only reproduce when reverting that commit but not on master. It seemed to be related to running out of file descriptors.
Because it's not an issue with that patch applied (eg: on master) I haven't reported it, but be warned.
I've just moved to using chromium apps via xwayland in the meantime.
|
wlroots has migrated to gitlab.freedesktop.org. This pull request has been moved to: https://gitlab.freedesktop.org/wlroots/wlroots/-/merge_requests/2064 |
This PR adds hidpi support to xwayland, using the proposed X changes from https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/432 .
Sway PR: swaywm/sway#5090
A single, global scale factor is chosen. This scale factor is used for the entire X server, so all x11 apps
are rendered at that same scale. wlroots will then scale rendered windows on outputs with scale different to the globa scale factor.
For optimal text rendering, the global scale factor should match the output's, but text is the correct size in all cases (no tiny/huge text on mismatches).
The xserver patches allow the Wayland compositor to control the global scale factor and change it on the fly via a X protocol extension. This is the main difference with the original xserver PR: that one automatically sets the scale factor to the max of the outputs' scales.
IMO having the scale factor configurable is the best choice, because the user can choose on which monitor the text is rendered best. For example: a 4K laptop (scale 2x) attached to a big 1080p external monitor (scale 1x) where the external monitor is the "main" display used for eg coding. The user will want the text to look best on the external monitor, so they'll set the global scale factor to 1.
To communicate the global scale factor to the apps, the X WM registers itself as the xsettings owner, and publishes the settingUpdate: the integrated xsettings is removed now, users must run their own xsettings daemon.Gdk/WindowScalingFactor
. The setting is updated on scaling factor change, triggering apps to dynamically re-render themselves at the new scale. This leads to a very seamless UX, but will conflict with the user's xsettings daemon if they're running any. In that case, what will happen is the user's daemon will override wlroots's, and if the user doesn't setGdk/WindowScalingFactor
correctly they'll get huge/tiny text.ToDo items:
the code in xwm_xsettings_set is very ugly and inflexible.Working apps:
Not working apps: