this post was submitted on 19 Aug 2024
323 points (82.0% liked)

linuxmemes

21172 readers
942 users here now

Hint: :q!


Sister communities:


Community rules (click to expand)

1. Follow the site-wide rules

2. Be civil
  • Understand the difference between a joke and an insult.
  • Do not harrass or attack members of the community for any reason.
  • Leave remarks of "peasantry" to the PCMR community. If you dislike an OS/service/application, attack the thing you dislike, not the individuals who use it. Some people may not have a choice.
  • Bigotry will not be tolerated.
  • These rules are somewhat loosened when the subject is a public figure. Still, do not attack their person or incite harrassment.
  • 3. Post Linux-related content
  • Including Unix and BSD.
  • Non-Linux content is acceptable as long as it makes a reference to Linux. For example, the poorly made mockery of sudo in Windows.
  • No porn. Even if you watch it on a Linux machine.
  • 4. No recent reposts
  • Everybody uses Arch btw, can't quit Vim, and wants to interject for a moment. You can stop now.

  • Please report posts and comments that break these rules!

    founded 1 year ago
    MODERATORS
     

    Wuuttup. I'm here complaining again about Framework's Linux unfriendly display. The new one this time.

    https://frame.work/products/display-kit?v=FRANJF0001

    Old display, 2256 x 1504 (3:2)

    GNOME

    100% scale

    • Nothing looks blurry
    • Everything is tiny
    • Unusable

    100% scale + large text accessibility

    • Nothing looks blurry
    • Most apps scale appropriately
    • Some apps don’t respect GNOME’s large text setting (Alacritty)

    125% scale

    • Most apps look blurry (Picard, Firefox, Spotify, Alacritty)

    200% scale

    • Everything is way too big
    • Unusable

    Plasma

    100% scale

    • Nothing looks blurry
    • Everything is tiny
    • Unusable

    125% scale + Apply scaling themselves

    • Nothing looks blurry
    • Most apps scale appropriate
    • Some apps can’t scale themselves and look tiny (Picard)

    125% scale + Scaled by system

    • Most apps look blurry (Picard, Firefox, Spotify, Alacritty)

    200% scale

    • Everything is way too big
    • Unusable

    New display, 2880 x 1920 (3:2)

    GNOME

    100% scale

    • Nothing looks blurry
    • Everything is tiny
    • Unusable

    100% scale + large text accessibility

    • Nothing looks blurry
    • Most apps scale appropriately
    • Some apps don’t respect GNOME’s large text setting (Alacritty)
    • Everything is tiny

    150% scale

    • Most apps look blurry (Picard, Firefox, Spotify, Alacritty)

    200% scale

    • Everything is way too big
    • Unusable

    Plasma

    100% scale

    • Nothing looks blurry
    • Everything is tiny
    • Unusable

    150% scale + Apply scaling themselves

    • Nothing looks blurry
    • Some apps can’t scale themselves, but look a little better here? (Picard)

    150% scale + Scaled by system

    • Most apps look blurry (Picard, Firefox, Spotify, Alacritty)

    200% scale

    • Everything is way too big
    • Unusable

    tl;dr

    In the old display, GNOME at 100% + large text was the best compromise. In the new display, Plasma at 150% + Apply scaling themselves is the best compromise.

    Interestingly, Picard scaling itself looks super tiny in the old display, but in the new display it looks... better. It's still not correctly scaled like native Wayland apps, but it's better.

    Warning

    If you can't stomach moving from GNOME to Plasma, then 🚨 DO NOT BUY THE NEW DISPLAY 🚨. The new display is worse for GNOME.

    Once again

    I am once again begging Framework to just give us a damn regular DPI display that works! Without workarounds. Without forcing users on specific DEs. Without forcing users to stop using their favorite apps. This new display has basically all of the flaws as the previous one.

    you are viewing a single comment's thread
    view the rest of the comments
    [–] gazter@aussie.zone 5 points 2 months ago (2 children)

    My exposure to Linux is pretty minimal, especially Linux with a GUI, so forgive my ignorance. Even reading over this thread I'm confused as to the issue here.

    I don't need an ELI5, but maybe someone can explain it like I don't know what Wayland is?

    My understanding is that an app should ask the system to display an object at X size, let's say text at size 14. The system then works out that at the currently selected display resolution, size 14 will be Y pixels big. If needed, the system can scale that based on user preferences- a small, high DPI screen could render size 14 at only a couple of millimetres, for example.

    Is the problem that devs are building things in a way that bypasses scaling? For example, hardcoding size 14 text to be Z pixels high?

    [–] orangeboats@lemmy.world 6 points 2 months ago* (last edited 2 months ago)

    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.

    [–] kintrix@linux.community 2 points 2 months ago

    That is basically the problem. Also that fractional scaling on Linhx generally still gives blurry results. Fractional scaling without explicit support from the apps side is very difficult to implement.

    And yes, there are a ton of of apps that don't correctly respect OS hints for size. Even more common among apps that aren't Linux first, or are proprietary.