Ja uz pouzivam wayland + KDE asi rok. Mam GeForce kartu + dva pripojene monitory: jeden 4k 144Hz a druhy 2k 60Hz. Musel som prejst na wayland, pretoze X server nedokaze nastavit rozdielne skalovanie a rozdielne frekvencie pre kazdy monitor. Asi do februara 2025 to bolo hrozne, casto to padalo, artefakty atd. Potom NVIDIA vydala nove ovladace a odvtedy uz je to OK.
. Musel som prejst na wayland, pretoze X server nedokaze nastavit rozdielne skalovanie a rozdielne frekvencie pre kazdy monitor.
$ xrandr --help
usage: xrandr [options]
where options are:
--display <display> or -d <display>
--help
--output <output>
--auto
--mode
--pos <x>x<y>
--rotate normal,inverted,left,right
--scale <x>[x<y>]
Skrátené na relevantné nastavenia.
Samozrejme existuje i GUI a je to tá istá konfigurácia, ktorá sa robí cez xfce-settings-manager a jeho ekvivalenty.
Funguje to vskutku skvěle (: https://lobste.rs/s/oxtwre/hard_numbers_wayland_vs_x11_input_latency#c_cydt92
Funguje to dostatočne dobre.
To, že obraz trochu trhne pri presune okna myšou medzi monitormi je trochu nešťastné, nie je to ale druh problému, kvôli ktorému človek normálne všetko zahodí a začne odznova.
Ostatne, ja na presun okien medzi monitormi a plochami používam program a jeho klávesové skratky, čo je jedna z vecí, čo pod waylandom chýba "by design." Nemyslím, že by v tomto ohľade mal možnosť štandardnému X11 niekedy konkurovať.
Jako, api které umožní aplikaci říct si kde se má kreslit skutečně ještě chybí, ale popravdě mě štve míň než náhodné glitche desktopu a nefunkční HDR. A podstatně míň než fakt že je XOrg security nightmare, kde každé okno vidí každé jiné okno, a screen locking je polofunkční. https://blog.martin-graesslin.com/blog/2015/01/why-screen-lockers-on-x11-cannot-be-secure/
A zatímco chybějící vlastnosti se do Waylandu dají doplnit, některé z problémů XOrg se nedají vyřešit opravou XOrg, plynou totiž z jeho architektury.
A podstatně míň než fakt že je XOrg security nightmare, kde každé okno vidí každé jiné okno, a screen locking je polofunkční.
Skutočne? Akým spôsobom to pre teba predstavuje problém na systéme, kde aplikácia s prístupom na X server má typicky prístup i do ~ a na odchytenie tvojich údajov vôbec nepotrebuje robiť screenshot?
A ako je to relevanté pre človeka potencionálne prechádzajúceho z Windows, kde toto je normálnou súčasťou OS už niekoľko dekád a nikto ani len nenaznačil, že by sa to malo rozbíjať?
Myslím, že toto je naopak nádherná ukážka ne-problémov, ktoré sa k waylandu museli vymyslieť, aby ich mohol "vyriešiť."
A zatímco chybějící vlastnosti se do Waylandu dají doplnit, některé z problémů XOrg se nedají vyřešit opravou XOrg, plynou totiž z jeho architektury.
Pokial si pamätám, XLibre to rieši pomocou Xnamespace extension, takže s architektúrou určite problém nebol.
27. 11. 2025, 10:29 editováno autorem komentáře
> aplikácia s prístupom na X server má typicky prístup i do ~ a na odchytenie tvojich údajov vôbec nepotrebuje robiť screenshot?
Flatpak / firejail / whatever. Aplikace dostane přístup jen tam kam potřebuje. Ale s X je tohle zabezpečení děravé.
Na Windows se pokud vím dá přinejmenším globálně vypnout screen capture přes GPO. Ale argumentovat "Systém XY je děravý, tak se nemusíme snažit být lepší" mi přijde hloupé.
A problém s děravým screen lockingem nevadí?
> Pokial si pamätám, XLibre to rieši pomocou Xnamespace extension, takže s architektúrou určite problém nebol.
Píšu některé z problémů, Xnamespace extensions nezmění základní funkcionalitu.
> na systéme, kde aplikácia s prístupom na X server má typicky prístup i do ~
Tento predpoklad nemusi byt celkom pravda. Flatpakove aplikacie mozu, nemusia mat pristup do home; by default bez otvoreneho sandboxu maju pristup do svojich privatnych xdg adresarov. Perspektivne by na pouzivatelske subory mali pristupovat cez portal.
> XLibre to rieši pomocou Xnamespace extension
Ak by to aj riesil pomocou extension, tak stale je to opt-in. Pre aplikacie ktore neoptuju tutu extension, treba udrziavat staru cestu. A sme tam kde sme boli, wordperfect z roku 1996 nebude tuto extension pouzivat.
Ak by to aj riesil pomocou extension, tak stale je to opt-in. Pre aplikacie ktore neoptuju tutu extension, treba udrziavat staru cestu.
Netreba. Aplikácie v inej namespace snímajú čierne obrazovky a prázdne zoznamy okien. Podobne, akoby bežali vo vlastnom XNest-e alebo Xerphyr-e.
Toto naozaj nikdy nebol reálny problém.
By design tam chybí jen to, aby to dělala aplikace sama. Nedejbože i s cizím oknem. To opravdu správci nechtějí.
Čo chcú správci je irelevantné, klávesové skratky sú neoddiskutovatelnou súčasťou práce s počítačom. Rovnako tak keď užívateľ pustí diktafón alebo gamepad mapper a ten jednoducho nefunguje, celý systém ide preč a vracia sa na Windows.
Naopak, co jednorazove aplikacie chcu je irelevantne. Su na jedno pouzitie; naopak spravca bude musiet udrziavat kompatibilitu "na vecnost". A konkretne pri X11 a Xinerama sa vyvojari poucili, ako to nerobit, preto uzivatelske aplikacie nedostanu nic, co by uzavrelo moznost vyvoja do buducnosti (t.j. ziadne absolutne pozicie -> obrazovka nemusi byt obdlznik, dokonca ani konvexny utvar alebo jednoducha geometria. Kompozitor si toto osetri, 99,99% aplikacii nie).
Takze su dve moznosti: 1) tam, kde sa racionalne diskutuje o skutocnych potrebach a nie o tom, ako sa to "zvycajne" robi, tam je mozne najst riesenie tejto potreby -- ako napr. save a restore pozicii okien 2) tam, kde sa arogantne tlaci, nastupuje rovnako arogantna ignorancia opacnym smerom.
To, ze niekto odide prec naspat na windows? No a co, je to "lacnejsie" ako zaprasit system nedomyslenymi napadmi a musiet ich udrziavat nasledovne dekady.
Alespoň nějaké pozicování je potřeba pro víceoknové aplikace a docky. Ze známých třeba Gimp, KiCAD a pár dalších víceméně profesionálních nástrojů. A tam mi "uteče zpět na Windows" vadí, protože já bych raději, kdyby autoři umožnili použití těch aplikací na linuxu.
Přepisovat ty mnoho let fungující aplikace nikdo nebude. Všichni uživatelé na všech platformách by se museli učit nový styl práce, což je nesmysl a nechce to ani autor ani uživatelé.
Pre taketo aplikacie sa to riesi so save/restore layoutu - ako si to rozlozil pouzivatel. Pokial existujuci layout neexistuje (prve spustenie), tak logickym popisanim layoutu (napr. toolbox napravo hore od hlavneho okna).
Pointa je, ze aplikacia nedostane presny layout displejov. Ten dokonca ani nemusi existovat (napr. uz spominany RemoteApp na nie-wayland display serveri co prenasa len okna, nie desktop, alebo kompozitor typu maze: https://github.com/capisce/mazecompositor).
Tym, ze by aplikacie mohli pocitat s pevnym konceptom layoutu (displaj je vzdy obdlznik), tak sa mnoho moznosti vyvoja uzavrie. Ako som spominal, stalo sa to aj s X11 a Xinerama, kde X11 zaviedol do protokolu predpoklad, ze vsetky Xscreen su rovnako velke a potom Xinerama zaviedla rozsirenie, ze pozor, tieto oblasti su offscreen, sem nic neposuvat. Dnes tu mame displeje s vyrezmi pre kamery, s ktorymi pocita presne 0% aplikacii a presne 0% by ich bolo kvoli tomu updatnutych v najblizsej dekade. Kompozitor si na to dohliadne a updatnuty bude.
Relativní pozicování nestačí, ale virtuální obdélník ano. Ostatně tak je napsaný ten poslední návrh https://gitlab.freedesktop.org/wayland/wayland-protocols/-/merge_requests/264 (důvody proč relativní pozice nebyla dost jsou ve faq).
Save/restore nestačí, ty nástroje umí občas přehazovat okna/rozložení dle zrovna prováděné činnosti.
Gamepad mapper se přece řeší na úplně jiné úrovni (/dev/uinput) s tím nemá wayland nic společného. Protože na úrovni X11 protokolu to neumí změnit ty klávesy, jen poslat další jako reakci (alespoň co si pamatuju).
A klávesové zkratky poskytuje ten kompozitor ve funkci window manageru přímo. Ne nějaká náhodná aplikace.
Na NVIDIA ovladacoch + KDE mi to proste na X nefungovalo. Furt bol nejaky problem so skalovanim. Niektore aplikacie boli rozmazane, napr. IntelliJ IDEA mala rozhadzane ponuky, nedalo sa v tom pracovat. Teraz na waylande to ide out-of-box a ako bonus mam funkcne HDR. Dokonca aj hry na Steame krasne slapu. A posledna vec, ktoru som na X pouzival a na waylande dlho chybali, boli gesta mysou. Toto uz je tiez funkcne vdaka projektu Input Actions.