xwayland: hidpi support

[Dirbaio]

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 setting 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 set Gdk/WindowScalingFactor correctly they'll get huge/tiny text. Update: the integrated xsettings is removed now, users must run their own xsettings daemon.

ToDo items:

• Get the xserver patches upstream
• The current code assumes the xserver extension is supported, it should fall back to forcing scale factor to 1 if it's not supported (eg user is running an old x server)
• the code in xwm_xsettings_set is very ugly and inflexible.

Working apps:

• VSCode (scroll wheel is 2x faster in 2x scale, but I think it's a vscode bug)
• Firefox
• Chromium
• GNOME calculator (forcing it to x11 mode by unsetting WAYLAND_DISPLAY)
• Nautilus (forcing it to x11 mode by unsetting WAYLAND_DISPLAY)

Not working apps:

• Spotify: always renders at 1x, so it looks tiny. It doesn't seem to be following xsettings for some reason.
• GIMP: same

[emersion]

Gdk/WindowScalingFactor

I don't think wlroots should become an xsettings deamon. Also this is a GTK-specific setting.

[progandy]

This looks like it implements x11 hidpi for the group of applications that need it the least to the detriment of alternative or legacy toolkits like Qt5 or GTK2 (e.g. GIMP)
GTK3 applications should mostly run fine natively. (Electron/Chromium is actively worked on by Igalia, Fireofx is on the way as well, GIMP is being ported to GTK3/4 as well.)

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 xownersize idea by keithp might help there.

[hypergig]

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!

[Dirbaio]

I don't think wlroots should become an xsettings deamon.

I 100% agree with you @emersion . How about structuring it this way?

• wlroots exposes the API for setting the x scale factor, and configures it to the x server
• sway exposes the xwayland scale command
• it is up to the user to run their own xsettings daemon, with the correct settings matching the x scale factor.

For static setups, the user can just set xwayland scale 2 in sway.conf and run xsettingsd with static settings. For dynamic setups it's up to the user to script something.

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.

This looks like it implements x11 hidpi for the group of applications that need it the least to the detriment of alternative or legacy toolkits like Qt5 or GTK2 (e.g. GIMP)

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.

We will be able to programmatically change the global x scale factor in an automatic fashion?

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 wlr-output-management protocol, and no sway/wlroots-specific IPC.

[emersion]

How about structuring it this way?

Yeah, I like this plan!

I can try to work with the x people to get the x patches merged, so we can move this forward.

Cool!

[hypergig]

@Dirbaio re:

This should probably go in an external tool.

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?

[emersion]

@Dirbaio: @ofourdan is planning on integrating the Xwayland MR with Mutter. Do you want to submit a cleaned-up Xwayland MR with your changes?

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?

An xsettings daemon, which could be re-configured on-the-fly with e.g. kanshi.

[MisterDA]

Hi! I’m curious, what’s the state on the PR and on the Xorg state? What can be done to help?

[emersion]

It would be nice to submit a cleaned-up Xwayland MR, then patch this PR to perform the changes described here: #2064 (comment)

[Dirbaio]

• Xwayland MR submitted here: https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/432
• wlroots branch rebased on latest master
• removed xsettings code.
• sway branch rebased on latest master
• all tested working

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 bool wlr_xwayland_is_scale_supported. Sway can then check that and present an error to the user if they try to use xwayland scale when not supported. Does that sound good @emersion ?

[Dirbaio]

Now that the built-in xsettings is gone, here are some configuration instructions to get it working!

Static config

Use 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 ~/.config/sway/config:

xwayland force scale 2
exec xsettingsd

Put this in ~/.config/xsettingsd/xsettingsd.conf

Gdk/WindowScalingFactor 2

Dynamic config with kanshi

Use this to get xwayland scale to change dynamically based on what monitors you have plugged in.

This example is from my setup: 4k laptop screen + 1080p external monitor. When using just the laptop screen, xwayland scale is set to 2 so I get best-looking text on the go. When using both, scale is set to 1 so my IDE looks best on the external monitor, because that's the one I use primarily. If your setup is different, adjust accordingly.

Put this in ~/.config/sway/config:

xwayland force scale 2
exec xsettingsd
exec kanshi

Ensure ~/.config/xsettingsd/xsettingsd.conf exists (just an empty file is ok)

Put this in ~/.config/kanshi/config

profile {
	output eDP-1 enable scale 2 position 0,0
	exec sh -c "swaymsg xwayland scale 2; echo Gdk/WindowScalingFactor 2 > ~/.config/xsettingsd/xsettingsd.conf; killall -HUP xsettingsd"
}

profile {
	output eDP-1 enable scale 2 position 0,0
	output HDMI-A-1  mode 1920x1080 position 1920,0
	exec sh -c "swaymsg xwayland scale 1; echo Gdk/WindowScalingFactor 1 > ~/.config/xsettingsd/xsettingsd.conf; killall -HUP xsettingsd"
}

If you have issues with xsettingsd not starting up properly, change exec xsettingsd for exec sh -c "sleep 3; exec xsettingsd" in sway config.

[MisterDA]

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.
EDIT: fixed by setting Xcursor.size: 16 in .Xresources, but the cursor is blurry.

My profile (both screens are 4K but the Acer is 28"):

profile <home> {
	output eDP-1 scale 2 position 2560,0
        output "Acer Technologies VG280K 0x0000972F" scale 1.5 mode [email protected] position 0,0
        exec sh -c "swaymsg xwayland scale 2; echo Gdk/WindowScalingFactor 2> ~/.config/xsettingsd/xsettingsd.conf; killall -HUP xsettingsd"
}

I’m assuming that I need to keep in .Xresources:

*.dpi: 192
Xft.dpi: 192

[emersion]

Thanks so much for the update @Dirbaio, nice work!

I was thinking about adding a function bool wlr_xwayland_is_scale_supported. Sway can then check that and present an error to the user if they try to use xwayland scale when not supported. Does that sound good @emersion ?

Either that, or we could make wlr_xwayland_set_scale return a bool.

[PSzczepanski1996]

OK, so I compiled @MisterDA repos, and got it working.

What I noticed:
Programs like discord, slack, firefox works fine, since they internally support 4K resolution to some extend.

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.
For me issue is - can we get some flag for programs like these, to run in other resolution, or without scaling, or just in FullHD mode at both monitors? Since they are not supporting them fine and fallbacking to non-biggest but to lowest res is best exprience to get?
Like with flag DRI_PRIME which was used on many laptops?

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.
Sorry, I sometimes mess things so hard that I hope you guys understand what I mean.

[JordanL2]

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.

Thanks very much for these AUR packages. I did some quick testing on Arch, and it seems to not behave well with Flatpaks:

1. Firefox (wayland native) opened but the GUI was all messed up and unusable
2. Minecraft (Xwayland) the launcher opened but when I tried to launch the game it never opened

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.

[sappel24]

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...

[andrewnicolalde]

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.
EDIT: fixed by setting Xcursor.size: 16 in .Xresources, but the cursor is blurry.

My profile (both screens are 4K but the Acer is 28"):

profile <home> {
	output eDP-1 scale 2 position 2560,0
        output "Acer Technologies VG280K 0x0000972F" scale 1.5 mode [email protected] position 0,0
        exec sh -c "swaymsg xwayland scale 2; echo Gdk/WindowScalingFactor 2> ~/.config/xsettingsd/xsettingsd.conf; killall -HUP xsettingsd"
}

I’m assuming that I need to keep in .Xresources:

*.dpi: 192
Xft.dpi: 192

Thank you so much for creating those AUR packages! Works great on my XPS 9570 4k.

[JordanL2]

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:
launcher_log.txt
The essential bit being:

[Info: 2020-05-04 11:06:26.803805495: GameCallbacks.cpp(158)] Game/dbn (Render thread) Info Setting user: ******
[Info: 2020-05-04 11:06:28.862672885: GameCallbacks.cpp(158)] Game/dbn (Render thread) Info Backend library: LWJGL version 3.2.2 build 10
[Info: 2020-05-04 11:06:29.057683173: GameCallbacks.cpp(158)] Game/net.minecraft.client.main.Main (Render thread) Warn Failed to create window: 
cxx$a: GLFW error 65545: GLX: Failed to find a suitable GLXFBConfig
	at cxx.b(SourceFile:215)
	at org.lwjgl.glfw.GLFWErrorCallbackI.callback(GLFWErrorCallbackI.java:36)
	at org.lwjgl.system.JNI.invokePPPP(Native Method)
	at org.lwjgl.glfw.GLFW.nglfwCreateWindow(GLFW.java:1714)
	at org.lwjgl.glfw.GLFW.glfwCreateWindow(GLFW.java:1897)
	at cxx.<init>(SourceFile:90)
	at drh.a(SourceFile:21)
	at dbn.<init>(SourceFile:417)
	at net.minecraft.client.main.Main.main(SourceFile:166)

Other applications (Firefox non-flatpak, Minecraft from AUR (xwayland), LibreOffice flatpak, Sublime flatpak, Steam Client flatpak (xwayland), Kerbal Space Program (xwayland)) are working fine.

[dimenus]

Is anyone else not getting a valid DISPLAY set with these patches? I'm not able to load any xwayland applications.

Edit:

XCB connect fails. I used the same build of xwayland with sway 1.4 release and it worked normally. Anything else I can do to troubleshoot here?

[emersion]

This sounds unrelated to this PR.

[dimenus]

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 i915 and that worked on the first try.

[andrewnicolalde]

* Spotify: always renders at 1x, so it looks tiny. It doesn't seem to be following xsettings for some reason.

From the Arch wiki

As the current Spotify build is not DPI aware, the amount to scale the interface by can be specified using the terminal command: spotify --force-device-scale-factor=X

[andrewnicolalde]

Does anyone know if this has been packaged for Fedora in any way?

[zsolt-donca]

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 xwayland scale 2 and one of my outputs has scale 1.5.

I am running xsettingsd as an x-settings daemon (as the initial post suggests), by including the following in my ~/.config/sway/config:

exec xsettingsd
exec xrdb -load ~/.Xresources

Some config files:

$ cat ~/.Xresources             
*.dpi: 192
Xft.dpi: 192
Xcursor.size: 48

$ cat ~/.xsettingsd           
Xft/Hinting 1
Xft/HintStyle "hintslight"
Xft/Antialias 1
Xft/RGBA "rgb"
Xcursor/size 48
Xft/dpi 192

I tried setting such a ridiculously large cursor size (48), but it doesn't seem to have any effect.

If I set xwayland scale 1, then the mouse cursor seems to be scaled correctly, though blurry (as do the xwayland apps).

My packages:

pacman -Q | grep hidpi           
sway-hidpi-git r6527.f1afef55-1
sway-hidpi-git-debug r6527.f1afef55-1
wlroots-hidpi-git 0.12.0.r44.g754179da-1
wlroots-hidpi-git-debug 0.12.0.r44.g754179da-1
xorg-server-common-hidpi-git 1.20.0.r768.g662b2bcb8-1
xorg-server-hidpi-git 1.20.0.r768.g662b2bcb8-1
xorg-server-xwayland-hidpi-git 1.20.0.r768.g662b2bcb8-1

Any ideas? Thanks in advance.

[kode54]

@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.

[zsolt-donca]

@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.

[zsolt-donca]

@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 XCURSOR_SIZE globally, because some wayland-native apps such as kitty and alacritty will interpret this env. variables as well and the cursor will appear double the normal size.

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?

[ngortheone]

I am just an outside observer, but I am really excited about this feature. JetBrains apps is what I really miss on sway.
JetBrains folks do plan to support wayland, but not soon (they are using java GUI toolkits, none of which are wayland aware)
https://youtrack.jetbrains.com/issue/IDEA-218458#focus=Comments-27-4551188.0-0

So I hope this feature will make those apps usable on HiDPI screens.

[zsolt-donca]

@ngortheone

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.

[fourstepper]

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.

This basically is precisely how its done in MacOS from what I heard?

[ngortheone]

@zsolt-donca

I can confirm that this patch, along with its counterparts in wlroots and in xwayland..

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./

[MisterDA]

I can confirm that this patch, along with its counterparts in wlroots and in xwayland..

I can't find the patches you mentioned. Can you point me into the right direction? I want to test them with CLion.

• wlroots:
  • PR: xwayland: hidpi support #2064
  • original: https://github.com/Dirbaio/wlroots/tree/xwayland_hidpi
  • rebased: https://github.com/MisterDA/wlroots/tree/xwayland_hidpi
• sway:
  • PR: xwayland: add hidpi support via xwayland scale command sway#5090
  • original: https://github.com/Dirbaio/sway/tree/xwayland_hidpi
  • rebased: https://github.com/MisterDA/sway/tree/xwayland_hidpi
• xorg:
  • MR: https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/432
  • original: https://gitlab.freedesktop.org/dirbaio/xserver/-/tree/xwlScaling
  • rebased: https://gitlab.freedesktop.org/MisterDA/xserver/-/tree/xwlScaling

[zsolt-donca]

@ngortheone

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 i3 (sometimes when switching workspaces only, or when losing focus), but I didn't experience it under sway, even though I've been using it for about a month. I am on the latest JetBrains tools, and using the development version of the above-mentioned patches though the AUR packages (in Arch Linux), mentioned above in @MisterDA 's comment: xorg-server-hidpi-git, wlroots-hidpi-git, sway-hidpi-git.

[zsolt-donca]

@ngortheone
The issue you mentioned seems like this: swaywm/sway#3007 Based on the latest comments, my take is:

1. it could be related to the swaywm/wlroots version (you could try with the latest master builds)
2. it could be mitigated by running the JetBrains IDEs on openjdk as opposed to JetBrains's own java distribution (note that this negatively affects font rendering, and some people have crashes with certain versions).

Sorry for the off-topic.

[caleb-allen]

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 hidpi branches onto master for wlroots and sway

[caleb-allen]

@ngortheone @zsolt-donca I've merged the latest master into this branch on my machine to test Jetbrains functionality, and so far Android Studio seems to be running correctly, along with HiDPI from this PR

[ngortheone]

@caleb-allen what is your estimate when this branch is going to be merged into master?

[JordanL2]

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

[ofourdan]

They don't seem terribly concerned about an issue that affects anything other than Gnome.

Gnome Shell DPI scaling: Does something different and therefore doesn't need this. The majority are likely to be running this, and therefore won't care. […]

This is simply and factually untrue.

[hedgepigdaniel]

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

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

[JordanL2]

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.

I certainly didn't mean to imply otherwise :) I would have contributed with effort of my own had I the experience to contribute meaningfully.

[ngortheone]

Does this patch still work on latest release?

[TamasBarta]

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 sway-hidpi-git, xorg-xwayland-hidpi-git, and wlroots-hidpi-git packages from the AUR.

I'd go with Wayland native with whatever has it, but JetBrains IDEs work well only with these HiDPI patches.

[MisterDA]

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.

So I'm not the only one! It started happening recently (last month or so?). I don't have a clue how to investigate…

[JordanL2]

I see someone has started a new MR as an attempt to get the ball rolling again:
https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/733

Best of luck to them.

[stevencorona]

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.

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 experience the same thing on VSCode - I think it's related to this issue: #3168

[zsolt-donca]

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.

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 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.

[WhyNotHugo]

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.

[emersion]

wlroots has migrated to gitlab.freedesktop.org. This pull request has been moved to:

https://gitlab.freedesktop.org/wlroots/wlroots/-/merge_requests/2064