LoDPI applications are either tiny sized or upscaled (= blurriness), aren't they?
Yeah I get the display server part. What I meant was that 200% scaling gets you 1920x1080 logical resolution on HiDPI applications -- LoDPI applications continue to be blurry just as if you set your actual resolution to 1080p, but HiDPI applications will enjoy the enhanced visual acuity.
Even on smaller screens like the 14" ones, the quality of very high resolution (e.g. 4K) is still quite visible IMO, especially when it comes to text rendering. But it could very well just be my eyes.
It's not even Linux's fault. Plenty of apps support HiDPI on Linux.
It's the developers who still think that LoDPI-only is still acceptable when it's already 2024.
Isn't scaling to 200% the same as lowering the resolution to half? And you lose the high DPI for apps that support it too.
Agreed. HiDPI is the way to go and we should appreciate Framework for putting that in their laptops instead of continuing the use of shitty 1366x768 screens.
Xorg is the reason why OP is facing the scaling issues. OP, try to force the apps to run on native Wayland if they support it but don't default to it. The Wayland page on Arch wiki has instructions on that. Immensely improved my HiDPI experience.
...Why is there Dunkin Donuts inside a hospital?
Agencies that are still living in the 90s...
Entitled brat? What... Have you ever seen how GNOME developers respond to some bug reports and merge requests?
Since when has reporting bugs and contributing to the project become an entitlement?
Society in general encourages and rewards those who speak more, even if the things they speak have zero contribution or are absolute nonsense.
Not sure if it's still the case today, but back then cellular ISPs could tell you are tethering by looking at the TTL (time to live) value of your packets.
Basically, a packet starts with a TTL of 64 usually. After each hop (e.g. from your phone to the ISP's devices) the TTL is decremented, becoming 63, then 62, and so on. The main purpose of TTL is to prevent packets from lingering in the network forever, by dropping the packet if its TTL reaches zero. Most packets reach their destinations within 20 hops anyway, so a TTL of 64 is plenty enough.
Back to the topic. What happens when the ISP receives a packet with a TTL value less than expected, like 61 instead of 62? It realizes that your packet must have gone through an additional hop, for example when it hopped from your laptop onto your phone, hence the data must be tethered.
It's the fear of centralization, I believe (correct me if I'm wrong!).
Seeing that the whole point of federation is to decentralize the web, putting everything under the Cloudflare umbrella goes against this philosophy.
One of the issues at hand is that X11, the predecessor of Wayland, does not have a standardized way to tell applications what scale they should use. Applications on X11 get the scale from environment variables (completely bypassing X11), or from Xft.dpi, or by providing in-application settings, or they guess it using some unorthodox means, or simply don't scale at all. It's a huge mess overall.
It is one of the more-or-less fundamentally unfixable parts of the protocol, since it wants everything to be on the same coordinate space (i.e. 1 pixel is 1 pixel everywhere, which is... quite unsuitable for modern systems.)
Wayland does operate like how you say it and applications supporting Wayland will work properly in HiDPI environments.
However a lot of people and applications are still on X11 due to various reasons.