Ne. A myslim, ze se tato funkce ani nezvazuje. Co se resilo byl castecne prusvitny horni panel - ale o prechodu se myslim neuvazovalo.
Ja pouzivam namiesto standardneho panelu 'Dash to panel'. Je to pre mna absolutne nepostradatelna vec. Pouzivam transparenciu ale da sa nastavit aj prechod farieb.
Tak ja mam pridane este aj skraslovatka:
- Burn my windows
- Compiz windows effect
- Desktop cube
- system-monitor-next
- Windows positioner
Ja bych to s tema pluginama neprehanel. Nekdo blbe zmigruje rozsireni a v tu chvili spadne cela wayland session.
Asi vyzkousim kvuli te vzdalene plose. Jak do hry vstupuje vice monitoru a nedej boze s jinym skalovanim nebo natocenim, tak to byva pro linux konecna.
Já mám 4k a fullhd monitor rok a půl a funguje to uplně v pohodě. Ale už nějakou dobu mi vpohodě funguje noťas s fullhd + externí 4k, nejsem si jistej jak dlouho přesně, ale pár let už to bude.
ja uz roky nedam dopustit na Remmina... pouzivam to v praci kazdy den a zatial som nenasiel nic lepsie.
Remmina dlhodobo nevie HiDPI a tak skoro asi ani nebude: https://remmina.gitlab.io/remminadoc.gitlab.io/md__builds__remmina_remmina-ci__remmina_8wiki__problems-and-tweaks__remmina-_r_d_p-and-_hi_d_p_i-scaling.html
hm, to som nevedel... zial/nastastie na erarnom firemnom monitore takyto problem nemusim riesit, tam sa mi o nejakom HiDPI moze akurat tak snivat :)
Tie budu zobrazene v spravnej velkosti na oboch monitoroch. Bohuzial na tom, co je hidpi byvaju tieto aplikacie rozmazane (nikdy som nepochopil, preco xwayland upscaluje s bilinear filtrom. Keby pouzil klasicky nearest neighbor, tak by to nevyzeralo tak rozmazane a bolo by to blizsie nie-hidpi monitoru).
Tusim od gnome co bolo vo fedore 43, xwayland uz vie povedat x11 aplikaciam, ze sa maju renderovat vo vyssom rozliseni, ktore potom vie v pripade potreby downscalovat na monitor s nizsim rozlisenim a to uz vyzera ovela lepsie.
A funguje to? Mě to totiž přijde šíleně rozmazané. Takže mám dvě možnosti buď mazanice nebo je to obří a nedá se s tím dělat. A to to mám na 125%. Po téhle zkušenosti jsem domů koupil před lety monitor s 2K abych to nemusel pořád řešit.
Ano, je to sialene rozmazane, to je to, co som spominal, ze pouzivaju bilinearny upscale, takze to vyzera tragicky.
Ono to moc jinak vyřešit nejde, když aplikace sama škálovat neumí. Buď se to vykreslí v původní velikosti a pak bude všechno malé nebo se prostě naškáluje bitmapa okna a bude to mít správnou velikost, ale bude to rozmazané. Na Windows je se starými aplikacemi stejný problém. Jedině, že by na to někdo implementoval DLSS, které by to zase vyostřovalo. :)
Jen to ne! https://jwz.org/blog/2026/03/official-video-full-hd-remastered/
1duchší bude naučit to líné programátory škálování správně na konkrétní rozlíšení monitoru.
No, to je celkovo problem filmoveho priemyslu.
Aj ked je film natoceny a nastrihany v 4k , tak akekolvek efekty budu 2k (z cenovych dovodov) a upscale. Filmy natocene v urcitom obdobi od nastupu digitalnej techniky po dostupnost lacneho 4k spracovatelskeho retazca boli tocene v 2k a tak aj navzdy ostanu (niektora TV produkcia zostane navzdy dostupna len ako "DVD"). Ak sa taketo filmy predavaju ako 4k, tak je to upscale, niekedy spackany (znamy priklad je Lord of the Rings).
Jednou z vynimiek je Nolan. Ten toci dodnes na film, striha fyzicky film a ak treba efekty, ktore nevie urobit prakticky, tak sa vyrenderovane vytlacia na film. Finalny vystup je film a ten sa v naskenuje pre digitalne kina. Tych 5 kin na svete, co vedia premietat film, dostane film.
Dlouhodobá zkušenost napříč systémy a monitory
mne naučila, že jediné použitelné řešení je: nechat to tak, jak to někdo naprogramoval, nezvětšovat, nezmenšovat, a volit vhodné rozlišení k úhlopříčce obrazovky.
Takže to mám všude nastavené na 100 %, a i když je to někde moc malé, jinde moc velké, stále je to to nejlepší z možných špatných řešení.
Ako spominam vyssie, nejde len o to, ze sa to naskaluje, ale o to, AKO sa to naskaluje.
Za rozmazanost moze bilinearny filter. Na prirodzene obrazky by bol ok, na synteticku grafiku je to zle. Keby sa pouzil nearest neighbor, tak by to nebolo rozmazane, bolo by to rozkockovane a svojim vzhladom by to pripominalo low-dpi monitory. Tie tiez nerobia bilinear, jednoducho maju vacsi pixel. Pre syntenticku grafiku daleko, daleko lepsie.
(Svojho casu som si rebuildoval remminu presne z tohto dovodu a s vysledkom som bol spokojny).
Tak tohle je podle mě dost o osobních preferencích. Trochu mi to připomíná, jak jsme ladili nastavení FreeType ve Fedoře: udělali jsme změnu a půlka uživatelů psala, že se na to dá konečně dívat, a druhá psala, proč jsme to rozbili, že se na to nemůžou dívat. :)
Len by som sa chcel opýtať na skúsenosti s AnyDesk pod Waylandom v 2026. Keď sa mám raz za čas ku niekomu na diaľku pripojiť kvôli pomoci a nechce sa mi riešiť vlastný server s RustDesk-om....
Na Ubuntu 22.04 som musel prejsť na X11, lebo to proste nefungovalo.
Neviete, majú to už zvládnuté (Myslím firmu AnyDesk. Zdalo sa mi, že na to kašlú), alebo ten XWayland voľajako funguje?
Pokud můžu přidat svoji zkušenost, tak AnyDesk mi pod Waylandem nefungoval vůbec (před několika měsíci), na dálkové ovládání používám DWService, ten nemá problém.
Nikdy to fungovat nebude. Protokol je specificky navržen tak, aby zabránil fungování podobných aplikací a žádná společnost nebude ztrácet čas implementací pro každý hack v každém možném compositoru.
Az na to, ze uz nejaky ten piatok existuje standardizovane API na screen capture.
Ale ano, uz nie je mozne na drzovku bez vedomia pouzivatela grabovat obsah ostatnych okien. Treba dostat od pouzivatela povolenie, co a ci vobec mozno grabovat. Ked to zvladne pouzivat Firefox alebo OBS, urcite to daju aj ini.
Neexistuje. Existuje portál který používá Gnome, vlastní wayland protokol používaný wlroots a jeho deriváty, jiný protokol používaný Hyprlandem, pro který dokonce existuje ekvivalent x11vnc, ale ten funguje jenom občas. Weston a swc stále nemá žádný, myslím a co má KDE nevím. Ale Gamescope také používá svůj vlastní protokol.
A to je jen pro screen caputre. Dále potřebuješ simulaci vstupu, což je ve Waylandu také verboten, enumeraci oken a displejů a nic z toho ti nebude fungovat ani trochu podobně mezi například Hyprlandem a QTile.
Ale to, co popisujete, je stav implementace napříč kompozitory a DE. Ne, že neexistuje API.
https://flatpak.github.io/xdg-desktop-portal/docs/doc-org.freedesktop.portal.RemoteDesktop.html
Jinými slovy, jak to zjednodušeně chápu já.
Přes D-Bus si aplikace řekne o remote session. Pokud je pak požadavek autorizovaný (evidentně se tam počítá i s permanentním povolením persist_mode: "Permissions persist until explicitly revoked"), pak dostane pole s IDčky PipeWire nodů, kde jsou streamy se zachycenými snímky z obrazovky a fd na posílání emulovaných vstupů přes libei (viz https://libinput.pages.freedesktop.org/libei/ ).
Plus samozřejmě další věci okolo clipboardu, výchozí pozici kurzoru, nějaké další záležitosti ohledně opětovného navázání session.
Podle všeho to minimálně poslední verze GNOME a Plasmy s jejich portály podporují. Pokud tohle zatím zmíněné menší projekty ještě nemají, tak je to za mě spíš otázka do jejich issue trackeru, než že by nebylo API.
xdg-desktop-portal není součástí Waylandu. Je to úplně jiný projekt, který je určen hlavně jako kontrolovaný únik ze sandboxů. Tento konkrétní protokol není podporován ničím, o čem vím, ale předpokládám, že ho podporují KDE nebo Gnome, dle toho který ho navrhl.
Každopádně, to je niní čtvrtý systém, který by musel AnyDesk nebo jiný teoretický remote desktop podporovat.
xdg-desktop-portal není součástí Waylandu.
Bingo, je to komplementární technologie, co se také používá v současných linuxových desktopech. Víceméně všechny standardní desktopová prostředí a kompozitory (mimo těch mikro, co se spouští z jiného) jí dnes v nějaké formě implementují a mají pro ni svůj backend. Od GNOME přes KDE, wlroots, Cosmic, LXQt až po Hyprland.
Je to úplně jiný projekt, který je určen hlavně jako kontrolovaný únik ze sandboxů.
Obecně řečeno, je to standardizované rozhraní nad D-Busem, kde aplikace mohou získat přístup k prostředkům, souborům atp. Jedno jestli běží v sandboxu (typu Flatpak), s nějakou proxy nebo ne.
Na jedné straně je aplikace/toolkit, mezitím D-Bus jako broker a na druhé straně pak backend konkrétního prostředí. Pokud obě strany korektně implementují konkrétní rozhraní (třeba lockdown, screencast, camera, game, trash... file chooser, request a i remote-desktop), je to interoperabilní.
Tento konkrétní protokol není podporován ničím, o čem vím, ale předpokládám, že ho podporují KDE nebo Gnome, dle toho který ho navrhl.
No desktop portal obecně, jak jsem zmínil, podporují víceméně všichni. Konkrétní rozhraní na remote-desktop funguje minimálně v těch dvou zmíněných, nejrozšířenějších tzn. pravděpodobně se shodli ;).
A vzhledem k tomu, že např. jak wlroots, tak Hyprland už teď podporují třeba to screencast rozhraní, které k tomu má velmi blízko a ten výstup obrazu z kompozitoru do PipeWire nodu už musí mít implementovaný, troufám si odhadnout, že jakmile se popasují se vstupy, nakonec to budou umět také a v kompatibilní formě.
Každopádně, to je niní čtvrtý systém, který by musel AnyDesk nebo jiný teoretický remote desktop podporovat.
Nevím, co myslíte tím čtvrtým systémem.. ale evidentně (TeamViewer, RustDesk..) to jde i na desktopu, kde neběží X11 server.
To má poměrně daleko k tomu, jak jste tu kategoricky tvrdil, že to "Nikdy fungovat nebude" a protokol (zobrazovací) byl specificky navržen, aby en-bloc zabránil fungování aplikací pro vzdálené ovládání.
Ano autor aplikace jako AnyDesk nemůže k desktopu přistupovat stejným způsobem jako u X11, což jsem tu už zmiňoval. A ano bude muset implementovat jiné API a pracovat s jinými rozhraními.
A v zásadě v tomhle případě nepracuje s Waylandem (což je asi to, čemu říkáte protokol), ten je úplně odstíněný a slouží k něčemu jinému.
Tady si celé sezení inicializuje a bude řídit přes portál a D-Bus, obrázek a zvuk bude mít přes PipeWire a ovládání přes libei.
A mimochodem ani na jiných operačních systémech nemáte "jedno" rozhraní, co vám dá všechno pro tenhle typ aplikace.
No desktop portal obecně, jak jsem zmínil, podporují víceméně všichni.
Víceméně všechny standardní desktopová prostředí a kompozitory (mimo těch mikro, co se spouští z jiného) jí dnes v nějaké formě implementují
Nesmysl. Implementují jej dva a standardizovaný není vůbec.
Nevím, co myslíte tím čtvrtým systémem.. ale evidentně (TeamViewer, RustDesk..) to jde i na desktopu, kde neběží X11 server.
Jistě, pokud ten desktop je Windows :)
U waylandu záleží na tom, jestli desktop a aplikace náhodou podporují stejnou sadu protokolů, což je vzácné.
To má poměrně daleko k tomu, jak jste tu kategoricky tvrdil, že to "Nikdy fungovat nebude" a protokol (zobrazovací) byl specificky navržen, aby en-bloc zabránil fungování aplikací pro vzdálené ovládání.
To je ale vysloveně mission-statement waylandu.
Tady si celé sezení inicializuje a bude řídit přes portál a D-Bus, obrázek a zvuk bude mít přes PipeWire a ovládání přes libei.
To je jen jedna z pěti metod, které jsme dosud identifikovali (počítaje i x11) a je to metoda, která funguje pouze s jednou "sadou" desktopů. To prostě není přijatelné.
A mimochodem ani na jiných operačních systémech nemáte "jedno" rozhraní, co vám dá všechno pro tenhle typ aplikace.
Jistěže mám.
A v zásadě v tomhle případě nepracuje s Waylandem (což je asi to, čemu říkáte protokol)
Wayland je protokol. To jste nevěděl?
Pletete se.
Přesně, jak píše "ja.", tak je tam desktop-portal, který povolí screen capture a pak daná aplikace získává snímky obrazovky jako stream přes PipeWire. Úplně stejně jako třeba v případě sdílení obrazovky s Teamsy, Zoomem atp.
U ovládání z aplikace je to trochu komplikovanější, protože se minimálně historicky docela lišila podpora remote desktop portálu napříč kompozitory, mohly tam být různé způsoby emulace vstupních periferií (např. přes libei). Každopádně je tam tendence tohle srovnat a minimálně na dvou hlavních DE (GNOME a KDE) s Waylandem běží RustDesk a TeamViewer.. byť tedy oba mají Wayland podporu deklarovanou jako experimentální, tak jsem oboje v pohodě rozchodil. Nezkoušel jsem wlroots, Sway atp.
Takže tenhle způsob vzdáleného přístupu (do existujícího přihlášeného sezení - typ. vzdálená podpora, otevřený uživatelský desktop) běží a není to tak, že by tomu apriori bránil ten protokol.
Důvod, proč to nemá Anydesk, spíš leží v jejich vývojových prioritách, než že by to principiálně nešlo.
Co je ovšem problém, a to se vám s tím možná trochu spojilo, je obecný přístup na jakoukoliv plochu (včetně přihlášení z login greeteru) třeba z nějaké další služby tak, jako to bylo v Xorg a X11. Kde jste si spustil např. scraping VNC server nebo nějakou službu s odpovídajícími právy a autorizací přes MIT cookie a v podstatě jste mohl vidět a ovládat libovolné sezení. Takhle obecně to tam záměrně opravdu není a musí to každý kompozitor implementovat po svém, pokud chce poskytovat obecné unattended sdílení, jako právě GNOME Remote Desktop.
Jediné, co se tomuhle staršímu systému blíží, tak je NoMachine, pokud na své konfiguraci rozjedete grabování přes EGL/DRM (tzn. je to úplně nezávislé na kompozitoru/aplikaci která tam vykresluje).
To je opravdu dobré, ale proprietární, ve firmě za to musíte platit a vzhledem k tomu jak to funguje, včetně toho jak se to zaháčkuje na různé specifické knihovny, tak je to opravdu docela citlivé na konkrétní konfiguraci (verze knihoven, ovladače). Rozhodně si nemyslím, že je to dobrá volba na nějaké rychleji se měnící distribuce. Např. Fedora 43 je k dispozici od října a teprve teď tam začalo NoMachine po aktualizaci chodit. Naproti tomu pokud máte nějakou LTS distribuci, nebo třeba Debian Stable, tak si myslím, že je to možné dobře provozovat.
31. 3. 2026, 22:27 editováno autorem komentáře
Díky za pěkný přehled. Už se těším, až to probublá do distribucí.
Fajn, že se průběžně vylepšuje ten GNOME Remote Desktop. HW akcelerace byla docela potřeba hlavně pro vyšší rozlišení.
To ověřování přes Kerberos je přesně v tom duchu, co tu myslím naposled zmiňoval "ja.", když mluvil o podpoře SSO a moderního ověřování atp. Já jsem zas tehdy říkal, že bych byl klidně radši za nějakou lokální náhradu za zpropadený GNOME keyring :) Byť ten pořád zůstává jedinou stávající možností pro jednoduché ověřování, pokud to není v nějaké firmě s infrastrukturou (KDC, FreeIPA nebo něco podobného, nakonfigurované všechny stanice RDP klienti i servery).
Takže doufejme, že se podaří úspěšně dodělat localkdc, co na něm pracuje Andreas Schneider. To by mohlo být právě zajímavé s ověřování s Kerberem v GRD, mimo asi hlavního použití se Sambou a CIFS mounty (IAKerb rozšíření), když v obou případech jde o postupné odstranění používání NTLM2.