hidpi: Exclude applications from scaling

[kaueraal]

Some applications, especially X11 applications, support hidpi, but currently do not support waylands internal scaling protocol for signaling this to sway. It would be nice to be able to disable sways scaling for certain windows (e.g. via an environment variable or prepended command) to get sharp scaled rendering nevertheless.
This would allow a smoother transition to sway/wayland for hidpi-users, especially as this affects both chromium and firefox.

I'm not sure whether the capabilities in wlm exist for that, maybe a similar feature request should be opened there as well.

[Drakulix]

Scale is set per output in wlc. To be able set application/window specific scaling parameters this feature would need to be provided by wlc at first.

[xeechou]

wayland protocol itself is per-output scale, so how do you expect wlc to change it?

[kaueraal]

I don't have too much knowledge about the inner workings of wayland or wlm or sway and I'm not too sure how much is handled in wlm or the layers below it, so treat the following with caution.

As far I understand the wayland protocol you have actually two scaling variables and nothing actually forces per-output scaling. Wayland simply allows per-output scaling, something X11 doesn't.
According to the protocol there is wl_output::scale and wl_surface::set_buffer_scale.
The first one allows a client to get the global scaling which should be applied. As far I can tell nothing in the spec forces this to be consistent between different clients (although Xwayland may be an issue). The second one allows a client to signal that it renders its content already in some way scaled. This is more or less the problem, as X11 applications won't do it.
When the client has something rendered the compositor should scale the window content by wl_output::scale/buffer_scale so the globally wanted scale is achieved. Nothing stops the compositor to do different things. This e.g. allows scaling by a non-integral factor by simply using a different scale value later as advertised to the client (which seems something wlc already does: Cloudef/wlc#57 (comment)).

Wlc/sway could tackle the issue in several ways, although I don't know which of these things are actually in the scope the respective libraries and don't need some stuff from some layers below.
The easiest one would be tracking which window should be scaled differently than advertised. Sway could track all windows with a certain environment variable and simply don't scale them, independent of what wl_output::scale/buffer_scale says.
If this isn't possible we could maybe send messages for the client and forcefully set buffer_scale to a value we want. We are the compositor after all, even if the scaling happens a few layers below we might be able to fake the sending of such a message.
Alternatively we maybe can funnel a different wl_output::scale somehow into the place we need it, so the place which calculates the scaling calculates the scaling we want.

This leaves Xwayland as an issue. According to SirCmpwn we can't scale different X11 applications differently. Maybe this can be sidestepped via starting multiple Xwayland instances, one for each scaling factor. I think I read somewhere that this should be possible, altough the place I read it wanted it for security reasons. This posibility of this is completely out of my knowledge though.

[kaueraal]

Damn, it seems the Xwayland issues can't be sidestepped that easily: https://bugs.freedesktop.org/show_bug.cgi?id=93315#c9 and the following comments.

[jm355]

Would it be possible to disable scaling for xwayland apps entirely? I think some of them have some way to scale themself, like chromium. Personally, I'd prefer a few tiny apps over some blurry apps

[main--]

Can this issue be revisited with wlroots? It's a perfect solution for applications like firefox where you can configure the application to upscale itself and the only missing link is xwayland. Configuring an override for the surface scale value on a per-application basis neatly works around this.

I would write a patch myself but after skimming through the code for 2 hours and asking on IRC (no response) I still have no idea where to start. Any guidance would be much appreciated - firefox is the only application that's stopping me from enabling sway's scaling right now.

[ddevault]

This is not really feasible, no.

[emersion]

Unfortunately it's not that simple. If you change how xwayland apps are scaled, you need to change how input events are processed and how outputs are exposed.

[main--]

@emersion Thanks a lot for your response. Since I'm not familiar with this codebase it's super hard for me to come up with an idea that's easy to implement. All I want is for my firefox to not be blurry on a highdpi display. That's it. And if the only way is some dirty hack that breaks upscaling entirely, so be it. (I remembered some idea about running all of xwayland at highdpi and then downscaling as necessary but I guess that's basically the same as telling firefox to do its own scaling)

Any ideas at all how I could approach this?

[RyanDwyer]

You could try running the Firefox Wayland port. Or just wait for them to support it in the main build.

[main--]

@RyanDwyer Sadly, the state of Firefox Wayland can only be described as "hot garbage" right now - it's completely unusable with sway (I tried both the gnome flatpak nightly and building it myself from the repo). It honestly looks like it's going to take 1-2 years at least for this to be ready.

For example, any attempt to use the address bar instantly crashes the entire browser.

[ddevault]

I'm not interested in upstreaming Xwayland hidpi hacks. If you're itching to write some this code for this problem, contribute to Firefox on Wayland.

[martinetd]

firefox wayland is perfectly usable for me; the main issue is that they create seats all the time and we don't handle that well (There's a workaround here: swaywm/wlroots#1041 (comment) ), but past this on a daily basis the wayland-specific bugs are minor enough.. There just isn't anyone fixing them on their side, so, yeah; if you have time to help I'm sure they'd take patches.
(EDIT: fixed link)

[main--]

@martinetd Very interesting. What exactly are you using? Again, both the nightly and my own build crash as soon as I use the address bar and hidpi scaling doesn't really work either, I basically get a non-scaled UI layout with scaled contents that keep clipping over edges everywhere. Looks funny but not usable. (also your link is wrong I think?)

@SirCmpwn Of course I wouldn't try to upstream some awful hack but is it really too much to ask for some advice on creating a quick fix just for myself? All I'm looking for is any way at all to get a usable hidpi wayland desktop without committing entire months of my life to it and I'm almost there - but a blurry web browser (the application many use >50% of the time) in 2018 is a complete non-starter, I hope we can at least agree on that.

I would greatly appreciate some technical background on why it's basically impossible to run xwayland at scale=2 and downscale as necessary when it's currently running at scale=1 and upscaling as necessary. It seems so simple on the surface I just want to understand why this is so hard.

[ddevault]

a blurry web browser (the application many use >50% of the time) in 2018 is a complete non-starter, I hope we can at least agree on that.

I'm sure we can agree on that. But we don't seem to agree that doing the correct fix is better than doing a bad hack. Contribute to Firefox and everyone wins.