hidpi about arewewaylandyet HOT 5 OPEN

Hi Jonathan, thanks for your comment.

I personally did not encounter those issues, to be frank, hidpi is what made me move to Wayland since X does not support multi-monitors with different hidpi settings.
Can you elaborate a bit more on the issue you faced? What was the compositor? Is it still happening? Is it only a bug or a flaw somewhere in the protocol? Is it configuration related?

Thank you

from arewewaylandyet.

From what I understand, any wlroots-based compositor does not automatically scale the mouse cursor with the hidpi scale. In wayland, drawing the mouse cursor is left up to the application, so each application may change the size of the cursor.

So while hidpi works really nicely in general (especially with plugging in external monitors), I would want to temper people's expectations of the level of polish across all apps and compositors.

I have only tested sway, and have not set anything regarding my outputs (allowing sway to autodetect stuff). This is with my laptop, and the following outputs:

Output eDP-1 'Unknown 0x282B 0x00000000' (focused)
  Current mode: 3840x2160 @ 60.001999 Hz
  Position: 0,0
  Scale factor: 2.000000
  Scale filter: nearest
  Subpixel hinting: unknown
  Transform: normal
  Workspace: 
  Max render time: off
  Adaptive sync: disabled
  Available modes:
    3840x2160 @ 60.001999 Hz

See the thread swaywm/sway#3014

from arewewaylandyet.

I use Sway too with a 4k screen laptop, I have not really noticed this but it might be because I only use Wayland apps. My understanding is that something is missing in the protocol to handle this scenario (+ cursor theming):
swaywm/wlroots#1324

That's a good one to keep track of, thank you!

from arewewaylandyet.

Mouse cursor size in some apps is a minor thing in my opinion..

But a much bigger issue is that using the native HiDPI scaling makes Xwayland apps blurry, and the workaround for that is still unmerged: swaywm/wlroots#2064

because I only use Wayland apps

Seems like Xwayland does scale the cursor, it's slightly blurry but not small (currently using a Java app at 2x scale with the aforementioned patch).

Rather, native apps that don't use big mainstream toolkits, e.g. alacritty 0.5.0 (using winit for windowing), are known to have the small cursors issue.

from arewewaylandyet.

Here is how the scaling model doesnt work stolen from reddit https://www.reddit.com/r/linux/comments/wwsiaf/comment/ilosxsf/?utm_source=share&utm_medium=web2x&context=3:

scaling model

It took 14 years, but upstream is basically admitting this by working on the fractional scale proposal. Restricting the core protocol to only interger scaling is clear madness and in today's world of HIDPI, it's an embarrassing relic. Fractional scaling in compositors currently work by tricking clients to render above the display's resolution and the compositor downscales it after the fact. It's one of the dumbest possible things someone could have come up with. How this should have worked is that applications just mark themselves as "DPI aware" in some way to stop all compositor-side scaling. After that, the compositor just passes some value (could be DPI, a fixed number, whatever) that the application than uses to scale itself properly. Non dpi-aware applications can just be upscaled by the compositor when needed.

from arewewaylandyet.