Názory k článku
Fedora 29 vyjde příští týden v úterý 30. 10.
-
ja. (neregistrovaný)
Uz niekolko releasov je Wayland default pre Intel a AMD GPU. X11 session je mozne vybrat pri logine, napr. Gnome vs Gnome X.org. Vo Waylande je mozne pouzivat X11 aplikacie, pretoze je tam Xwayland (rootless X11 server). Je to nutne, pretoze ani Firefox ani Chrome/Chromium nepodporuju Wayland (Firefox ma experimentalnu podporu) a bez nich by bol nejaky desktop dost nanic.
Xwayland ma nejake limity - jeden co mne osobne dost vadi, je jeho nepouzitelnost s hidpi. Vsetky aplikacie spusta s 96dpi a na hidpi displeji ich upscaluje, takze sice maju spravny fyzicky rozmer, ale su rozmazane. A to aj aplikacie, ktore pod normalnou X11 session podporuju hidpi.
Druhy limit je, ze nedovoli aplikaciam zmenit rozlisenie framebuffera. Pokial nejaka aplikacia chce behat fullscreen s nejakym konkretnym rozlisenim, tak Wayland kompozitor jej bude klamat, necha povodne rozlisenie a fullscreen okno upscaluje pomocou GPU. Pre normalne aplikacie OK, pre hry nepouzitelne, Unigine Heaven takto isiel zo 120 fps na 12.
-
XWayland se chová na HiDPI jako Xka. Škálovat na něm jde, ale neumí různé škálování na různých monitorech, takže by default se ve Fedoře naškálují aplikace běžící na XWaylandu podle primárního monitoru a na rozdíl od aplikací běžících na Waylandu se neumí automaticky přeškálovat, když se přesunou na jiný monitor. To je omezení X11.
To, co popisujete, je chování Mutteru, když zapnete experimentální neceločíselné škálování. Obchází omezení X11, dává aplikacím standardní DPI a pak jejich framebuffery přeškálovává podle skutečného DPI daného monitoru. Výsledkem je správná velikost na jakémkoliv monitoru, ale neostrost. A to i u aplikací, které na X11 škálovat umí, byť fixně (Firefox, Chrome...). Proto teď Olivier Fourdan pracuje na řešení, kde by běžely dva servery v XWaylandu: jeden pro aplikace, které neumí škálovat vůbec, těm bude dávat standardní DPI, a jeden pro aplikace (identifikované pravděpodobně na základě nějakého whitelistu), které škálovat umí, a těm dá skutečné DPI a nebude jejich framebuffery škálovat nahoru. -
ja. (neregistrovaný)
Jeden monitor (desktop), aktualna Fedora 28, Gnome session/mutter:
- 200% scaling v X.org: x11 aplikacie OK
- 200% scaling vo Wayland: x11 aplikacie rozmazane
- 175% scaling vo Wayland: x11 aplikacie rozmazanePokial by boli pri 200% aplikacie OK, tak mozu byt aj pri 175%, skalovat smerom dole nie je az problem. Opacny smer ano.
-
Ano, takto se chová, jak jsem psal, ta experimentální podpora neceločíselného scalingu v Mutteru, kterou si musíte zapnout v dconfu. Pokud ji zapnutou nemáte, tak Xka v XWaylandu aplikacím hlásí skutečné DPI a Mutter jejich framebuffery neupscaluje a jsou tudíž ostré. Pokud vám to rozmazání vadí, tak si tu experimentální podporu vypněte. Mně vadí taky a mám ji na monitoru 3200x1800 vypnutou.
-
Tomi (neregistrovaný)
Mozem otazku? Bude Hidpi podpora vo Fedore aspon v roku 2020 uz normalna, idealne taka aku ma macOS uz od roku 2012 ? A je mi to uplne jedno ci to budu X alebo Wayland, chcem iba aby to nebolo rozmazane (hlavne ikonky v menu bare) a kazdy pripojeny displej mal svoje dpi aj lubovolny zoom.
-
To není ani tak otázka OS, jako spíš samotných aplikací. Pokud aplikace používá 10 let starý framework, který prostě škálovat neumí, nebo má největší rozlišení ikon 96x96, tak kompozitor z ní dokonale ostré okno se správnou velikostí nevyčaruje. Třeba takový GIMP na HiDPI saje úplně stejně v macOS jako na Linuxu.
-
ja. (neregistrovaný)
1) diky, fakt by mi nenapadlo, ze zapnutie fractional scaling ma vplyv na aj integer scaling. Po vypnuti fractional scaling 200% funguje korektne.
2) s podporou hidpi a fractional scalingu v linuxe maju maslo na hlave aj autori kompozitorov. MacOS to vyriesil uplne jednoducho a elegantne: Quartz podporuje iba integer scaling, fractional scaling sa robi na urovni crtc, ekvivalentom `xrandr --scale` (ano, rozlisenie framebuffera je ine ako rozlisenie displeja). Ziadny software vyssie vo stacku netusi, ze sa pouziva nejaky fractional scaling, tym padom sa nekomplikuje, neriesia non-integer pozicie kurzora a hranic medzi oknami, nemusia na scaling pouzivat GPU, takze ak je treba vykon, tak ho maju k dispozicii na 100%, ked ho nie je treba, crtc scaler je energeticky uspornejsi. Pokial by autori mutteru pouzili rovnaky pristup, spolu s existujucim xwayland to uz mohli mat davno hotove.
-
On to Mutter dělá v té experimentální podpoře neceločíselného škálování podobně. Aplikace také netuší, že se používá fractional scaling. Problém je v tom, že aplikace nemají jak Mutteru říct, že podporují škálování, takže to dělá tak, že skutečné DPI hlásí těm, které běží na Waylandu a používají tedy moderní framework, který škálovat umí, a u aplikací běžících na XWaylandu předpokládá, že škálovat neumí a dá jim DPI 96. Výsledkem je to, že aplikace na Waylandu škálují na 200 % a na XWaylandu na 100 %. Když si uživatel nastaví třeba 150 %, tak bitmapy oken aplikací na Waylandu se zmenší na 150 % a u XWaylandu se roztáhnou na 150 % (to je příčina rozmazaných oken).
Problém je u aplikací, které běží na XWaylandu, ale škálovat umí a Mutter jim nyní zbytečně dává DPI 96 a ony škálují na 100 % a jejich okna se potom roztahují a jsou rozmazané. To vyřeší až další X server v XWaylandu a nějaký whitelist, podle kterého se budou aplikace pouštět na serveru, který jim bude dávat skutečné DPI. Těch aplikací není mnoho. Jsou to prohlížeče (Chrome, Firefox) a pár dalších. Samozřejmě dlouhodobě to vyřeší přechod těch aplikací na moderní framework, který zvládá Wayland a škálování. Je jasné, že u některých aplikací už k tomu nikdy nedojde a tam se holt budeme muset smířit s neoptimálními výsledky na HiDPI monitorech, ale na Windows nebo macOS tomu u takových aplikací není jinak.
