KDE Plasma stopt in 2027 met ondersteuning voor displayserver X11

Desktopomgeving KDE Plasma biedt vanaf versie 6.8 niet langer X11-sessies aan. De displaydriver was al standaard vervangen door Wayland, maar wordt nu volledig geschrapt. Wayland is al langer de standaarddisplayserver in Linux-systemen.

KDE laat in een blogpost weten dat de toekomstige KDE Plasma-versie 6.8 de eerste wordt zonder X11-ondersteuning. De release van 6.8 wordt pas begin 2027 verwacht; eerst moeten versies 6.6 en 6.7 nog verschijnen. Volgens de ontwikkelaar heeft dit voor 'het overgrote merendeel' van de gebruikers geen impact, omdat zij al gebruikmaken van Wayland. Door te stoppen met X11-ondersteuning kan KDE naar eigen zeggen de ontwikkeling versnellen. Ook biedt dit 'mogelijkheden' voor nieuwe functies.

Vanaf KDE Plasma-versie 6.0, die begin 2024 werd uitgebracht, was Wayland al als standaard ingesteld, ten koste van X11, al werd dat laatste displayserverpakket nog wel ondersteund. Gebruikers kunnen vanaf versie 6.8 nog wel de Xwayland-software gebruiken voor backwards compatibility met X11-applicaties.

Een groeiend aantal Linux-distro's en andere gerelateerde software stapten de afgelopen jaren af van X11, tot voor kort de belangrijkste displaydriver. Dat geldt onder meer voor Fedora. Ook desktopomgeving Gnome wordt vanaf de eerstvolgende release niet langer met X11 geleverd.

Reacties (109)

[Prince]

Een belangrijk punt dat niet vergeten mag worden: applicaties die geschreven zijn met Qt5 werken niet goed meer op Wayland. Deze zouden eigenlijk over moeten naar Qt6. Dit is echter extreem moeilijk door de 'dependency hell' rondom Python, waardoor er tal van applicaties achterblijven die niet correct of performant op Wayland draaien.

Denk aan:

• QGIS
• FreeCAD
• Krita
• Scribus
• VirtualBox
• De linux client van Zoom
• KeePassXC
• VLC Media Player (pas vanaf 4.0 is deze qt6)

[laurxp]

Tsja, Qt 6 is inmiddels ook al 5 jaar oud, en Qt 5 is sinds begin dit jaar End of Support.

Zelfs als KDE en Gnome X11-ondersteuning bleven houden, zouden deze applicaties dus flink in de problemen komen. Distros zitten er nou eenmaal niet op te wachten om libraries te shippen die geen updates meer zullen krijgen!

Je applicatie bijwerken als je dependencies updaten is nou eenmaal onderdeel van software-ontwikkeling - dat zou niet als een verrassing moeten komen. En hoe langer je het uitstelt, hoe pijnlijker het is om te updaten...

[kozue]

5 jaar is helemaal niks. Niet iedereen gebruikt alleen een webbrowser en de tools van z'n desktop. Velen hebben software nodig die al langere tijd niet is bijgewerkt. Ik kom soms zelfs nog tooltjes tegen die nog python2 nodig hebben. Ik blijf het raar vinden dat er mensen zijn die vinden dat je alles wat ouder is dan 5 jaar gewoon maar weg moet gooien.

[SherlockHolmes]

Ergens begrijpelijk, aan de andere kant kan ik ook gewoon legacy Windows applicaties nog draaien die 20 jaar oud zijn zonder enig probleem. Games bijvoorbeeld.

[Frietsaus]

Het zit hem in het woordje "gewoon". Ik begrijp dat dit iets is wat Microsoft met Windows zo heeft gedaan, maar hierdoor draagt Windows ook een enorme bak legacy met zich mee waar Microsoft denk ik ook maar al te graag vanaf zou willen en in de 'normale' softwarewereld is het niet vreemd dat legacysupport gewoon een keer ophoudt.

[RoestVrijStaal]

Tsja, Qt 6 is inmiddels ook al 5 jaar oud,

Dat is een leugen.

De final release van Qt 6 is op één december tweeduizendtwintig. Het is vandaag zevenentwintig november tweeduizendvijfentwintig.

Dus om het moment van schrijven is Qt 6 vier jaar, elf maanden en zesentwintig dagen oud.

[TheVivaldi]

KeePassXC heeft een PR openstaan om Qt6-ondersteuning toe te voegen, maar ook de huidige versie werkt prima op Wayland. Krita werkt zelfs keihard aan Qt6-ondersteuning. VLC ook, zoals je al aangeeft. De rest geen idee.

[halla]

We werken inderdaad keihard... Maar het is niet leuk En al die man-maanden die we aan Wayland en Qt6 besteden, kunnen we niet besteden aan leuke dingen voor Krita, zoals GPU accelerated brush engines of integratie van 3d modellen in de viewport. En er is niets, helemaal niets in Wayland en Qt6 dat we kunnen gebruiken om Krita beter te maken voor mensen die gewoon willen tekenen en schilderen. Laat staan mensen die professioneel willen tekenen en schilderen en om color management geven.


Maar 't mot, dus doen we het.

[Prince]

Werk jij mee aan Krita? Zo ja, prachtige software! Goed gedaan!

Zonder bijbedoelingen en oprechte nieuwsgierigheid; wat is jouw mening als je opmerkingen leest als hierboven zoals "Als je als applicatiebouwer nu na 9 jaar nog steeds afhankelijk bent van Xorg dan heb je gewoon liggen slapen of ben je een struisvogel. Xorg zou gaan, dat was bekend."

Wat is de voornaamste reden dat software niet direct met de qt6-migratie begonnen is, wetende dat Wayland qt5 niet "goed" zou ondersteunen? Ik betwijfel dat jullie lagen te slapen, noch denk ik dat de devs hun hoofd in het zand staken. Waar liggen de issues met de overstap? Is het zo verschillend van elkaar?
Ik denk, los van het bovenstaande artikel, dat dit ook erg interessant kan zijn voor onze mede-lezers hier.

[Liegebeest]

“Wat is de voornaamste reden dat software niet direct met de qt6-migratie begonnen is,”

Ik ben geen Krita dev, maar begeleid bedrijven met honderden ontwikkelaars in dienst.

De meest voorkomende reden die ik bij mijn klanten zie voor het niet upgraden naar nieuwe courante frameworks en libraries strookt met wat OP net zei: g HD er levert niet direct aantoonbare functies of winst. Tenzij zij zelf plannen hebben die het nieuwe framework vereisen, wordt het gezien als moetje en niet als toekomstbestendiging.

We horen regelmatig het bericht dat de project manager het werk steeds niet goedkeurt omdat de prioriteit ligt op nieuwe features.

En zo bouw je steeds meer “technical debt” op.

[Bux666]

[...] levert niet direct aantoonbare functies of winst.

[...] omdat de prioriteit ligt op nieuwe features.

Begrijpelijk, want veel ontwikkelaars willen enkel iets nieuws maken. Maar het getuigd van enorme kortzichtig- én onervarenheid als je de techdept niet kent, snapt en ziet. Hoe meer je je kop in het zand steekt, hoe groter de problemen later gaan worden. Geldt voor compatibiliteit, snelheid, veiligheid en toepasbaarheid.

De "project manager" die zoiets tegenhoudt is 100% incapabel en zou per direct ontslagen moeten worden. Maar ja...hij staat met zijn MT-vriendjes op de golfbaan en welke marketeer snapt er iets van techniek?

[Liegebeest]

Ik kan me niet vinden in je meningen, ze komen sterk negatief over.

De project managers worden, bij de meeste bedrijven waar ik kom, aangedreven door prioriteiten uit het hoger management. En die eisen vooral het leveren van functionaliteit, plus aandacht voor de 10 Top priorities van ${Jaartal}... Maar dan heb je 12-14 prioriteiten en dus geen enkele prio. En één daarvan is mogelijk "vulnerability management", maar geen daarvan is "achterstallig onderhoud".

Dat ligt niet aan golf of kwade wil. Het ligt aan ons hele bedrijfsleven en manier van werken.

[HollowGamer]

Geen Krita developer, maar run wel KDE en lees veel over Linux.

Wat ik begrijp (kan het mis hebben), is Wayland nog altijd vrij lastig om mee te werken. Zo heeft Wayland bijvoorbeeld geen protocol om te zeggen dat vensters en schermen op een bepaalde manier moeten staan of openen. Dit komt er wel aan (session-protocol o.a.), maar nog altijd houden de Wayland developers heel veel tegen (toevallig zitten daar ook best veel Gnome-developers in, en die zijn altijd stug geweest in keuzes maken). Voor iets als Krita lijken me dat soort dingen nodig, en XWayland werkt nog altijd (gok ook dat het voorlopig niet weg gaat).

Qt6 is kennelijk ook een flinke stap voorruit, maar ook als developer een beast als je wilt upgraden. Er zijn nog super veel apps die Qt5 gebruiken, voor iets eenvoudigers kan het, maar Krita is echt veel meer dan dat.

[HollowGamer]

Maar moet Qt6 dit dan niet eenvoudiger maken? Het idee van een nieuwe versie, zou toch moeten zijn dat jullie als developer(s) minder werk hebben of juist dat het via een Wayland-protocol kan gaan?

Ben geen developer, lees van alles, maar vind het wel interessant om te weten wat bepaalde roadblocks kunnen zijn.

[Reactie gewijzigd door HollowGamer op 26 november 2025 23:32]

[halla]

Zou wel moeten, maar... De Qt developers zien veel gedocumenteerde features in Qt als in de eerste plaats bedoeld voor Qt. Dan gebruiken we dat omdat het gedocumenteerd is, en verdwijnt het in een volgende versie. We hebben dat gehad met de OpenGL QPainter implementatie op MacOS, maar ook met support voor Angle onder Windows. Het veranderen van een fundamentele class als QVector naar op-QList gebaseerd leidde tot heel wat bugs. Qt5 QWidgets op Android is min of meer okay, maar met Qt6 een ramp. We zijn van Qt2 naar Qt3 naar Qt4 naar Qt5 naar Qt6 gegaan, en iedere keer is het initiele porten weken werk, en daarna maanden to een jaar opruimen.

En zoals hier boven gezegd, het moet, want anders wordt het steeds moeilijker, maar ik wil bugs fixen, en ik wil features ontwikkelen, en Krita leuker maken.

Wat betreft Wayland: ook dat geeft bugs -- dialogs verschijnen nu op het verkeerde scherm, color management is dramatisch (en de discussies daarover vol met drama). Het kost gewoon heel veel tijd, en we zijn maar met een paar full-time developers.

Hier zijn de nu bekende openstaande wayland bugs: https://bugs.kde.org/buglist.cgi?bug_status=UNCONFIRMED&bug_status=CONFIRMED&bug_status=ASSIGNED&bug_status=REOPENED&list_id=3357215&product=krita&query_format=advanced&short_desc=wayland&short_desc_type=allwordssubstr

[Reactie gewijzigd door halla op 27 november 2025 13:33]

[Prince]

Ze zijn er druk aan bezig, maar het voelt een beetje als de grond die wegzakt onder je voeten als Wayland "verplicht" wordt.
QGIS werkt bvb ook, maar voelbaar minder performant, zeker als je veel (>100k) features hebt.

edit:
maar pas op, het ligt naar mijn mening niet aan de applicaties of de community errond hoor, eerder aan de dependency hell bij Python. Mijn god... probeer eens een lokaal AI TTS op te zetten. Daar gaat je avond met versies aanpassen en dingen forceren... :-)

[Reactie gewijzigd door Prince op 26 november 2025 19:25]

[asing]

Wayland werd geïntroduceerd door Fedora in versie 25. Dat was 2016. 9 jaar geleden. Xorg was zogezegd "a hot mess" en op dit moment is er nog maar één dev mee bezig. Het werd tijd voor wat nieuws, schoon schip. Hetzelfde geldt voor Pipewire en zo zijn er vast meer. Op een gegeven moment moet je 20 jaar oude code vaarwel zeggen omdat het niet meer gaat.

Voor de Xorg afhankelijke applicaties is er XWayland. Ik gebruik zowel VLC als KeepassXC en ik heb nooit iets van de problemen gemerkt. Ik heb 2 applicaties die meteen in paniek schieten. TeamViewer en Onmissa Horizon. Die laatste doet het overigens prima als je de error negeert.

Toegegeven, Wayland miste in het begin heel veel maar de protocollen worden stilaan gebouwd. Als je als applicatiebouwer nu na 9 jaar nog steeds afhankelijk bent van Xorg dan heb je gewoon liggen slapen of ben je een struisvogel. Xorg zou gaan, dat was bekend. Die ene dev maakte ook een hoop ruzie dus het werd wel tijd.

[Reactie gewijzigd door asing op 26 november 2025 22:46]

[TheVivaldi]

Het enige wat ik mis aan KeePassXC is overname van de tekstgrootte die ik in de systeeminstellingen heb ingesteld. Ik moet dat nu apart regelen met qt5ct. Kleine moeite, maar voor de stroomlijning zou het natuurlijk mooi zijn als de systeeminstellingen zouden worden gebruikt, wat met Qt6 wél kan (met Qt5 ook, maar mijn desktop is Qt6…). Verder werkt KeePassXC als een zonnetje.

[asing]

Weet je, als je kijkt naar Windows 11 en diens applicaties en dat vergelijkt met (in mijn geval) Gnome, dan kan je denken dat Microsoft miljarden heeft maar als het gaat om de look and feel wint Gnome. Drie niveaus diep in Windows zit je ineens tegen XP aan te kijken. Dat zal je bij Gnome niet gebeuren. Veel applicaties volgen ook het design document en hebben dezelfde look and feel. Er zijn wat uitzonderingen en die vallen dan meteen weer op.

[Killemov]

En wat heeft dit te maken met het droppen van X11 door KDE?

[asing]

Gnome heeft X11 ook al gedropt.

[jorisporis]

Nieuw schip is zelden schoon schip. Vaak moet het eerst dezelfde modder door. Oude code roest niet.

[aldieaccounts]

Op zich heb je gelijk. Maar in het geval van X11 is het natuurlijk niet zozeer de code de verroest is, als wel het model van de wereld waar X11 op gebaseerd is.

X11 is ontwikkeld in een tijd van netwerk terminals als een netwerk-tekenprotocol. Er was (bijna) niemand meer die de oorspronkelijke functionaliteit van X11 nog gebruikte zoals hij bedoeld was. Alles ging via extensies op het X protocol, en iedereen was eigenlijk vooral bezig met om X heen werken.


Maar al die oude ongebruikte code moet wel onderhouden worden...

[rob12424]

Ja en nee, het gebruik werd niet gedaan vanwege de beveiliging als je x11 goed gebruikte zou je kunnen zeggen: ik heb mijn muis in Texas toetsenbord in Denver. Mijn beeldscherm in Duitsland en mijn harde schijf staat op Alaska. (Vanwege de grote was dat vroeger nodig)

Maar die verbindingen met x forwarding onderandere zijn ontwikkeld voor in 1 gebouw. In mijn voorbeeld moet je gaan tunnelllen, time server voor lag en delay compensatie en synchronisatie gaan uitvoeren enz.

Mooie voorbeelden hoe het wel echt handig is, is bijvoorbeeld scholen in Brazilië met 1 complete kast en een sterke gpu video kaart en cpu hebben en gewoon in lokalen elke pc een cliënt hadden waar beeld en andere zaken naar ge x forward werden.

Nu met containers, kvm en alles zijn we gemakzuchtig geworden. Maar als je niet de ruimte of stroom verbruik hebt. En je hebt de kennis kan x11 zeker wel voordelen hebben. Maar je moet dan wel dat weten en de kennis in huis hebben.

[aldieaccounts]

Zeker, X forwarding is heel erg handig. Ik gebruik het ook veel.

Maar het valt niet te ontkennen dat bijna alle apps tegenwoordig bitmaps pushen of opengl/vulkan via shared memory als het enigszins kan. En dat dat 99% van alle usecases is. in X11 zit een enorme hoop bagage.

Ik vind het wel jammer dat ze bij wayland niet vanaf het begin gelijk een network protocol hebben opgenomen in de standaard. Maar ik begrijp op zich wel dat de X11 developers met een schone lei wilden beginnen.

[Hydranet]

Het enige wat ik mis is een goed alternatief voor xrdp voor remote desktop sessies. Op mijn werk gebruik ik nu nog Xfce zodat ik vanuit huis via xrdp kan verbinden. Op mijn pc thuis gebruik ik al 4 jaar Wayland, afgelopen twee jaar zijn ook met de nieuwe Nvidia drivers de Steam client glitch opgelost.

[asing]

Remmina?

[Hydranet]

remmina is een client, ik heb het over een rdp server te draaien via xrdp op mijn pc zodat ik via remmina een remote desktop sessie kan overnemen. Daar heb ik nog geen goed Wayland alternatief gevonden.

[rob12424]

remmina is een client, ik heb het over een rdp server te draaien via xrdp op mijn pc zodat ik via remmina een remote desktop sessie kan overnemen. Daar heb ik nog geen goed Wayland alternatief gevonden.

Bedoel je dan zoiets als Waypipe? Je bedoelt het x forwarding gedeelte neem ik aan?

https://deepwiki.com/neonkore/waypipe/2-getting-started

[Hydranet]

Nee dat bedoel ik niet. Ik gebruik xrdp om mijn hele desktop sessie remote over te nemen.

[rob12424]

Aha meer zoiets als; no machine, rust desk, wayvnc of Gnome remote desktop? En je voorkeur voor rdp boven vnc is de standaard betere beveiliging neem ik aan?

[Hydranet]

VNC heb ik nooit gebruik vond dat altijd een slechte manier voor remote desktop, dus wayvnc lijkt mij net zo slecht. Rustdek nog niet naar gekeken maar lijkt mij dat je daar apart zelf een server voor moet draaien, om daarna met jou eigen systeem te verbinden lijkt mij te veel werk. Gnome desktop is gewoon bagger en traag als het niet lokaal op hetzelfde lan is. Ook moet je apart een account instellen ipv de lokale authenticatie te gebruiken van je gebruiker die al op het systeem bestaat. Daarom heb ik nog altijd de voorkeur aan xrdp en zit ik nog te wachten tot iets wat een vergelijkbare ervaring geeft.

[kozue]

Wat is er dan mis met VNC? Ik gebruik het ook om een Mac Mini te besturen en werkt prima voor wat ik er mee doe. RDP is een Microsoft protocol bedoeld voor Windows, dus dat zoiets implementeren in Linux geen prioriteit heeft kan ik me best voorstellen.

[Hydranet]

Het is al heel lang geleden dat ik vnc gebruikt hebt maar volgens mij gebruikt Gnome remote dat onderwater ook. Maar ik vind vnc te bewerkelijk, apart account en wachtwoord instellen en apart encryptie te moeten configureren. Met xrdp hoef ik alleen maar xrdp te installeren en dan kan ik gewoon mijn Linux account gebruiken om in te loggen in de default configuratie heeft al encryptie.

Daar naast moet ik ook nog een goede DE vinden die goed werk met Wayland. Via een remote verbinding over het internet via een via een vpn tunnel vind ik Gnome gewoon traag reageren. Thuis vind ik Gnome prima, gebruik nu Hyprland thuis. Zou dan moeten kijken of ik iets kan een goede tool kan vinden om met Wayland remote sessie te werken. Ik gebruik nu Xfce op Debian op het werk maar Debian heeft geen Hyprland in de repos en wil wel op een stabiele distributie blijven voor mijn werkstation op het werk. En KDE Plasma lijkt mij niet veel beter als Gnome voor remote sessies via een vpn tunnel over het internet.

Mischien Sway is proberen maar dan heb ik alsnog een goede manier nodig om er remote naar toe te verbinden.

[Reactie gewijzigd door Hydranet op 27 november 2025 18:06]

[TheVivaldi]

Waarom zakt de grond onder je voeten weg? De ondersteuning valt pas over een kleine anderhalf jaar weg. Als ze (in elk geval KeePassXC, Krita en VLC) er nu al druk mee bezig zijn, is dat tegen die tijd echt wel af. En anders is er nog XWayland. Goed, minder performant voor Krita, maar performant genoeg voor KeePassXC en VLC.

[Reactie gewijzigd door TheVivaldi op 26 november 2025 19:33]

[Prince]

Ik draai nu de laatste Ubuntu. Geen leuk knopje meer bij het inlogscherm om een X11 sessie te starten.
En de XWayland werkt "meestal", maar soms merk je wel performance issues. Ik ken de techische details van Xwayland niet, maar ik vermoed dat dit een emulatielag of iets dergelijks is. Het zou de performance issues verklaren.

De ene applicatie heeft er natuurlijk meer last van als de andere. Een QGIS zal complexer zijn dan een VLC om te emuleren. Eenmaal geladen is VLC op zich puur decoderen van een stream en weergeven en dat is C code meestal.

[Sando]

In Linux hebben dergelijk grote projecten vaak decennia nodig om te rijpen. De laatste 10 jaar is desktop Linux eindelijk echt fijn en alles werkt gewoon™. En dan nu met de overstap naar Wayland werkt alles weer kut.

Ja er zijn mensen met anekdotische ervaringen die precies de juiste hardware hebben en precies de niet goed werkende software niet gebruiken die zullen zeggen dat alles perfect werkt, maar er zijn ook mensen met de verkeerde hardware, afhankelijk van de verkeerde software en de verkeerde workflow.

Denk bijvoorbeeld aan ssh of screen. Sommige mensen gebruiken het al 30 jaar. Toch vervelend als het opeens niet meer werkt. Het is maar een fictief voorbeeld, maar zo voelt het als je al decennia ssh -x of xpra gebruikt. En dan komt "men" met nieuwe software zonder voordelen met allerlei nadelen, welke al 10 jaar wordt gepusht en nog steeds niet lekker werkt.

Ja dan denk je echt meine liebe, ben ik weer terug bij de eeuwwisseling ofzo. Straks moet ik weer mijn eigen videodriver compileren.

Uiteraard zijn er voordelen voor bepaalde devs maar het is vervelend als de hele Linuxcommunity weer verplicht in wordt gezet als betatesters.

[TheVivaldi]

Wayland is niet perfect, nee — ik heb er ook wel eens problemen mee. Het ging mij er dan ook niet om om Wayland te verdedigen, maar om aan te geven dat er nog tijd zat is voor Qt-software om Wayland te ondersteunen, daar KDE niet overmorgen al X11-ondersteuning laat vallen.

[trick2011]

Het verbaast mij inderdaad dat KeepassXC ertussen staat, ik ondervind geen problemen met de fundamentele basisfunctionaliteit.

[jeroenvj]

In mijn ervaring werkt KeePassXC inderdaad prima op Wayland (Ubuntu 25.10), behalve de autotype functionaliteit. Voorheen (Ubuntu 25.04) werkte dit nog als je KeePassXC opstartte met 'QT_QPA_PLATFROM=xcb keepassxc' zodat het XWayland gebruikte, maar dat lijkt niet meer te werken.

[MatiasG]

Zie ook: KiCad and Wayland Support. Wayland schiet helaas gewoon tekort in sommige gevallen.

[- peter -]

Poeh, dat is ook wel een instelling. Ik snap de devs wel, maar door helemaal geen rekening te houden met dat t straks verdwijnt schilder je jezelf wel vast in een hoek op een gegeven moment.

[MatiasG]

Tja, als basale functionaliteiten missen in het Wayland protocol is er ook niet heel veel wat je kunt doen als applicatieontwikkelaar. Hoewel Wayland continue verbeterd schieten sommige dingen ook echt niet op.

Zo is er bijvoorbeeld al 2 jaar gesteggel over het onthouden van de positie van vensters op het scherm. Een vrij simpele functie, die essentieel is voor professionele software met veel vensters welke er dus nog steeds niet is. Dit terwijl X11 en andere besturingssystemen dit soort functionaliteit al decennia lang hebben.

[bzzzt]

Een influencer lekker dramaqueen laten spelen is dan ook niet bepaald de normale manier om een bug op te laten lossen. Een voorstel met duidelijke omschrijving en eventueel een patch voorstellen werkt een stuk duidelijker dan 'supporten jullie dat nou na al die jaren nog niet' gepush waarbij mensen dan ook net doen alsof het hun recht is de tijd van anderen daarvoor te claimen.

Ondertussen implementeren andere professionele pakketten gewoon een single venster container zodat het lang niet zo'n issue is en beter cross-platform werkt.

[MatiasG]

Wat heeft een influencer hier mee te maken. weet je überhaupt wel waar het over gaat? Dit gaat niet over een bug maar een stukje missende functionaliteit.

Een ontwikkelaar die heel graag deze functionaliteit in Wayland wil probeert gewoon al twee jaar deze functionaliteit te mergen (dus een duidelijke omschrijving met patch) maar de Wayland developers weigeren steeds omdat een globaal coördinaten systeem teveel zou lijken op X11. Dat iemand anders daar dan een filmpje over maakt staat daar los van.

Ondertussen implementeren andere professionele pakketten gewoon een single venster container zodat het lang niet zo'n issue is en beter cross-platform werkt.

De schuld leggen bij de applicatie is wel heel makkelijk. Sommige professionele applicaties werken al decennia lang met meerdere vensters en dit is gewoon een hele workflow.

Dit soort opmerkingen zijn juist onderdeel van het probleem. Als er constant geruzied blijft worden over of iets wel of niet nodig is schiet het nooit op. Gebruikers hebben deze functionaliteit nodig, dat is evident.

Het is overigens niet beperkt tot professionele software, met een Wayland sessie kan KDE niet onthouden op welke virtual desktop ik mijn Firefox vensters open had staan en openen ze steeds weer op de eerste. Met een X11 sessie werkt dit wel.


EDIT: Volgens @TheVivaldi is het wel mogelijk op KDE met een extra script, dank voor deze aanvulling. Dat is handig maar het zou natuurlijk veel beter zijn als dit opgenomen was in Wayland zodat niet ieder Wayland compositor zijn eigen workarounds hoeft te implementeren voor dit soort basale functionaliteiten.

[Reactie gewijzigd door MatiasG op 26 november 2025 22:24]

[bzzzt]

de Wayland developers weigeren steeds omdat een globaal coördinaten systeem teveel zou lijken op X11.

Ik kan me niet voorstellen dat 'lijkt op X11' het bezwaar is. Hooguit dat de voorgestelde oplossing niet heel lekker past in het Wayland model en daarmee niet toekomstvast te onderhouden is. Een standaard die na een paar jaar helemaal op de schop moet is ook niet wat je wil.

[TheVivaldi]

Onthouden van de vensterpositie zou natuurlijk mooi zijn op Wayland-niveau, maar op zich kan dat al wel op KDE met behulp van het script ‘Remember window positions’, op te halen via Systeeminstellingen → Vensterbeheer → KWin-scripts → Nieuwe ophalen…
Er zit zelfs (optioneel) een uitgebreid instellingenpaneel bij om alles volledig naar eigen hand te zetten.

[4tro]

Dit is een beetje wat Wayland probeert te bereiken, bepaalde features van X11 horen architectuur technisch niet thuis in de display sever laag, en die zullen ze dan ook niet gaan supporten. Dit zal moeten worden opgepakt door de hogere lagen.

Dus exact wat kwin doet, op Window manager niveau dit afhandelen.

[Sine]

Begrijp ik dat je je os vrijwillig in het NL gebruikt?

Brrr

[TheVivaldi]

Ja, ach ja, het maakt het nog wel eens makkelijk om mensen te helpen. Daarbij ben ik vertaler van beroep, dus Nederlands heeft wel mijn voorkeur als die optie er is (in programma's/besturingssystemen dan). Maar de vertaling van KDE is helaas zeer matig te noemen, in elk geval dezer dagen dan (vroeger was die beter).

[Sine]

Dat bedoel ik, vertalingen van dat soort spul zijn meestal tenenkrommend ...

En als je op een foutmelding moet zoeken krijg je in het Engels net wat meer hits.

[TheVivaldi]

Als ik het KDE-project zou mogen overnemen, zou ik gelijk de vertaling stroomlijnen en professioneel aanpakken. Maar ja, helaas…

[N8w8]

Het ziet er idd naar uit dat Xorg als primaire "server" al aan het verdwijnen is, maar het einde van Xwayland is nog niet in zicht.
Als het nu prima zou kunnen draaien onder Wayland dan is het zaak daar werk van te maken.
Maar zolang dat niet het geval is, en het nog wel ok draait onder Xwayland, hoef je niet te haasten lijkt mij.
(Behalve dan met het zorgen dat Wayland ooit geschikt wordt natuurlijk).
Jammer voor de (straks voornamelijk Wayland) users dat het dan niet native draait, maar mss hebben ze dat toch liever dan dat het onhandiger werkt ivm missende features in Wayland.
Zodra Wayland geschikt is (of Xwayland deprecated zal worden) kunnen ze het alsnog porten.

[Reactie gewijzigd door N8w8 op 27 november 2025 12:52]

[laurxp]

Als KiCad-gebruiker kan ik me hier totáál niet in herkennen. Window placement is een compleet nonissue (KiCad is qua windows zelfs eenvoudiger dan de gemiddelde IDE), en cursor warping met zoomen is altijd raar en afwijkend gedrag geweest. En "render issues"? Die waren er in KiCad ook zát op X11.

Het klinkt meer als een developer met een persoonlijke hekel aan Wayland dan een daadwerkelijk probleem. Je kan dan wel je kop in 't zand steken en de werkelijkheid negeren, maar daar krijg je geen betere software van. En bugreports over Wayland weigeren? Leuk voor de gebruikers - je zegt expliciet dat je dus geen zin hebt om d'r ook maar iets aan te doen...

[Sine]

Nou ... het gaat gruwelijk mis als je een 'vreemde' config hebt. bijvoorbeeld drie monitoren waarvan eentje geschaald naar 125%
Ook al staat er niets van KiCad op die 3e monitor. Dat heeft me wat zoekwerk opgeleverd.

[avlt]

Ik begrijp de grafisch georienteerde applicaties, maar KeePassXC?

[Frenziefrenz]

Om velden in te kunnen vullen e.d. is natuurlijk "onveilig".

[bzzzt]

Applicaties die random input kunnen lezen en schrijven van andere applicaties zijn inderdaad minder veilig dan dat ze netjes van elkaar geïsoleerd zijn.

[GertMenkel]

Niet native wellicht, maar XWayland gaat nergens heen. Niet alles werkt met XWayland (schermopnames, keylogger-stijl shortcut managers, en dat soort specifieke dingen) maar het is niet alsof niks werkt als het met Qt5 gecompileerd is.

[mars]

Ik heb zelf een applicatie ontwikkeld op py-qt5 en deze probleemloos naar py-qt6 geport. Ik herken me totaal niet in de dependency hell van python waar jij het over hebt (al mijn dependencies staan in mijn pyproject.toml file en dat werkt prima

[aaahaaap]

Wat heeft (moeten) upgraden naar een nieuwe major versie van de grafische toolkit die je gebruikt te maken met dependency hell?

[Reactie gewijzigd door aaahaaap op 27 november 2025 08:55]

[Prince]

Alles is aan elkaar gekoppeld. Jouw applicatie heeft meestal bibliotheken of bindings. Deze kunnen afhankelijk zijn bepaalde qt5 versies. (bvb de qt 5 headers of ABI). Jij kan dan jouw applicatie pas updaten als al deze afhankelijkheden een qt6 versie hebben - dezelfde dan nog.

qt6 heeft ook andere vereisten. Gebruik je qbuild? pech, ga maar naar cbuild nu. Gebruik je een niet C++17 compatibele compiler? pech, upgrade je toolchain maar.

En dan hebben we natuurlijk nog de modues die gewoon niet meer bestaan in qt6. Er zijn redelijk wat "qt5compat" modules, maar niet alles wat vroeger in qt5 beschikbaar was, is nu ook beschikbaar. Dat is dus zoeken naar een vervanger en hopen dat het puzzelstukje mooi past. Anders is het veel aanpassen. (sowieso eigenlijk).

Het is misschien niet de exacte dependency hell van python, maar het voelt hetzelfde. En dan spreek ik over kleinere applicaties. Ik wil niet weten wat het is voor een qgis of krita.

[jerisson]

Wat is de reden dat Qt5 applicaties slechter werken in Wayland dan Qt6 applicaties?

Qt gebruikt toch een platform plugin als abstractie die ingesteld kan worden op x11 of wayland? Wordt die voor Qt5 dan niet bijgewerkt naar nieuwe wayland features? En is het dan geen mogelijkheid voor de community om deze te onderhouden? Dat vergt uiteraard wel effort voor iets dat reeds een opvolger heeft (Qt6).

[Prince]

Er is een qt5 wayland plugin, maar gezien qt5 end of life gaat, wordt die inderdaad bijna niet meer bijgewerkt. Tel daar dus bij dat Wayland niet alle calls ondersteunt die X11 ondersteunt, en dan kom je met een probleem te zitten.
Maakt Wayland een vooruitgang, dan moet iemand dat nog in qt5 implementeren (welke dus sowieso gaat wegvallen), om dan nog niet te spreken of het ook gewoon gaat werken met jouw applicatie.
De meeste devs met de juiste expertise zitten nu op qt6, niet qt5.

qt5 is ook grotendeels gemaakt op basis van openGL, waar wayland (en qt6) op API's zoals vulcan, Direct3D,...

[jerisson]

Dat is een duidelijke uitleg. Bedankt voor de informatie.

[Niemand_Anders]

Ik heb persoonlijk het probleem dat mijn computer niet goed uit een sleep komt op Wayland (Nvidia gpu). Ben vervolgens overgestapt op X11 en alle problemen waren als sneeuw voor de zon verdwenen.

Hopelijk heeft Nvidia tegen 2027 dan wel fatsoenlijke Wayland comptabiliteit, want anders zal ik KDE moeten pinnen op 6.7 in apt.

[Prince]

Ik heb een computer met een 1660 Super die exact heeft wat jij beschijft. X11 was een oplossing, een oudere driver ook. Ik ben uiteindelijk voor de X11 verder gegaan omdat dit ook andere issues deed verdwijnen. Ik weet niet meer welke versie van de nvidia drivers (closed source versie) uiteindelijk werkte.

op mijn 4060 Ti is er echter geen issue met Wayland op de gewone drivers. Wel mijn mijn VR bril, waarvoor ik ook op een iets oudere closed source ben terug moeten gaan...

[GtrCraft]

Ik hoop dat tegen die tijd programma's zoals rustdesk, vnc etc. Wayland ook ondersteunen. Ik ben nu overgestapt op plasma omdat ik anders geen beeld krijg.

[pOZOR jED]

Gewoon SSH gebruiken dus Waarom zou je een remote desktop willen?

[Soldaatje]

Voor ondersteuning op afstand bij iemand anders, omdat dat meestal via een desktop gaat. Overigens werkt dit prima met Wayland, Gnome en RDP bij mij via Tailscale.

[Reactie gewijzigd door Soldaatje op 26 november 2025 19:20]

[GtrCraft]

Omdat ik soms graag een UI wil ipv alleen de terminal

[Overheid]

Is er al zoiets als de -X flag maar dan voor Wayland?

[deadinspace]

Je kunt met waypipe Wayland applicaties remote draaien, vergelijkbaar met ssh -X. In mijn ervaring is waypipe qua snelheid een heel stuk bruikbaarder dan X forwarding zelfs.

[Klojum]

RDP is geen optie?

[GtrCraft]

Is zeker een optie, ga ik een keer voor zitten

[yoaz]

Wat ik begrijp is dat xrdp niet lekker werkt met Wayland.

Als iemand weet hoe rdp wel met Wayland kan, hoor ik dat graag

[Niemand_Anders]

FreeRDP werkt redelijk, maar heeft soms wat kleine issues als je target meerdere schermen heeft of de bestaande sessie een andere resolutie.

[thomas_n]

Als dat nog wat langer duurt, is dat niet direct een probleem voor de meeste gebruikers. Als je geen rolling distributie gebruikt dan zit je normaal gesproken niet op de laatste versie van KDE, dus je kan nog best tot in de jaren dertig voort met een mainstream distibutie met X11-ondersteuning in Plasma.

Niet dat ik hoop dat dat ook de insteek van ontwikkelaars gaat zijn, die mogen wel vaart maken, maar voor gebruikers is er geen reden tot paniek.

[TheVivaldi]

En dan nog hoeft het niet het einde te zijn, want het hangt er allemaal vanaf wat er precies onder de motorkap verandert. Het kan heel goed dat Plasma - ondanks het wegvallen van de officiële ondersteuning - nog jarenlang blijft werken op X11. En dan is er ook nog een nieuw project dat Plasma voor X11 doorontwikkelt, dus als dat tegen die tijd nog bestaat en de officiële Plasma begint door de verschoven focus buggy te worden op Wayland, kun je sowieso door blijven werken met die fork (vergelijkbaar met TDE).

[Katsunami]

In 2030 is Wayland effectief 22 jaar oud. Toen X11 20 jaar oud was, begon men aan de vervanging Wayland te werken. Ik mag toch hopen dat tegen 2030 alles en iedereen _ein-de-lijk_ over is.

[i-chat]

• op https://rustdesk.com/docs/en/client/linux/ staat:

X11 Required

RustDesk does not support Wayland yet; you need switch to X11 manually.

RustDesk now has experimental Wayland support since version 1.2.0.

[GtrCraft]

Dat werkt niet zonder input. En dat gaat niet gaat niet op mijn headless linux bak.

[MachIII]

Ik hoop dan wel dat je de oude distro's kunt blijven downloaden.
Want voor mij geen Wayland.

[Katsunami]

Veel succes dan na 2026. Veel distributies gaan vanaf 2027 gewoon X11 helemaal uit de distro slopen. Wat ga je dan doen; tot 2067 op Debian 13 blijven zitten of wat?

[MachIII]

Voor wat ik er mee doe zijn de huidige en de voorlopers goed genoeg.
Ik zit met mijn spul toch niet op internet.
Maar ik heb een NAS, dat wordt dan nu van alles downloaden en opslaan.

[Liegebeest]

Hoezo? Staat je data niet apart van je OS?

Eén verandering van Linux distro betekent niet dat je al je data kwijtraakt.

[Prince]

Ik begrijp wat je bedoelt. Ik ervaar ook geen positieve punten die me doen zeggen "oh, ja, kom hier met die Wayland en we laten die oude X11 achterwege".

[Overheid]

Dat altijd. Van bijna alle grote distro's is een torrent te downloaden. (peer to peer)

[ffha]

De bugs en het niet af zijn terzijde, de keuze om alles compleet dicht te timmeren voor veiligheidsredenen, vind ik eigenlijk gewoon raar.

De gemiddelde gebruiker wint er niks mee. Die worden gehacked door een user-mode programma te draaien wat al hun wachtwoorden steelt, of hun wordt iets afhandig gemaakt via social engineering. Puntje bij paaltje, zal er ook wel weer iets à la Teamviewer op hun PC verschijnen.

Bedrijven winnen er niks mee, want het is niet bepaald een standaard configuratie om je displayserver open te gooien. En voor de mensen die dergelijke toegang nodig hebben, zijn er al een miljoen betere oplossingen.

Puntje bij paaltje, mist Wayland ontzettend veel dingen, en wordt er weer ontzettend veel man-uren verspilt aan het het overzetten en testen van duizenden individuele programma's. Hoe kan dat ooit efficiënter zijn dan het updaten van Xorg / het schrijven van nieuwe extensies?

[Reactie gewijzigd door ffha op 26 november 2025 23:22]

[bzzzt]

Heb je ooit voor X11 geprogrammeerd? Dat is een gigantische legacy bende waarbij low-level display drivers, high level drivers als OpenGL gecombineerd zijn met een netwerk server. Functionaliteit voor nieuwere systemen is er bovenop gemikt met extensions die vaak efficiëntie in de weg zitten. Hoeveel spaghetticode is verantwoord?

Vrijwel geen enkele desktop gebruiker heeft een 'by default' netwerk capabel window systeem nodig en bovendien is het X11 remloting systeem door alle extensies voor client-side rendering helemaal niet meer 'puur' te gebruiken; een oplossing als RDP of VNC is zo goed als noodzakelijk om enige performance te halen.

Het laten zitten van lekken omdat andere gaten erger zouden zijn is compleet contraproductief. Vandaag wordt misschien amper iemand gehacked, maar als er genoeg kwetsbare systemen in omloop zijn kan dat zo omslaan (check het npm artikel van vandaag maar). Een OS wat z'n kerntaak van het isoleren van applicaties niet goed kan uitvoeren is niet serieus te nemen.

[henk717]

Het concept "Laten we X11 vervangen" is op zich ook geen slecht idee. Maar dan moet je X12 maken die als doel heeft om alles wat X goed kan goed te kunnen. Wayland wil helemaal geen vervanger zijn voor X. Software compatibiliteit boeit ze niet dus sloop je heel veel in userspace. En als je dan al een niche platform bent moet je niet raar opkijken als je dan vervolgens met die bugs blijft zitten en een bericht terug krijgt "Op X werkt het prima".

[ffha]

Heb niet aan Xorg zelf gewerkt, maar heb wel dingen geschreven die gebruik maakten van o.a. Xlib, XShm, XTst, Xinput etc. Af en toe een beetje OpenGL in de pap, toentertijd vaak via GLEW.

Was niks spaghetti aan hoor. Stokoude documentatie, maar 9/10 keer deed het gewoon wat je ervan vroeg. Atlhans, wat ik ervan vroeg.

Wayland is ondertussen nog als het wilde westen, en het voelt ontzettend brak dat ik anno 2025 meer bezig ben met workarounds schrijven, dan ik ooit deed met Xorg.

[laurxp]

De gemiddelde gebruiker wint er niks mee. Die worden gehacked door een user-mode programma te draaien wat al hun wachtwoorden steelt,

Dat is dus precies waarvoor Wayland nodig is!

Linux heeft inmiddels met Flatpak best goede sandboxing van applicaties. In plaats van alles op één hoop te gooien, krijgt een applicatie alléén toegang tot het strikt noodzakelijke. Een "game" die de bestanden van je wachtwoordmanager leest? Nope, dat is onmogelijk.

Maar X11 is een gapend gat hierin. Die iets-minder-vertrouwde applicatie in de sandbox kan via X11 wél gewoon meeluisteren met al je toetsenbord-invoer. Wachtwoord ingetypt? Gaat gelijk terug naar het moederschip. TOTP code? Met X11 kan iedere app zien wat alle andere applicaties op het scherm zetten, dus die is ook gelijk gelekt.

Met X11 is het gegarandeerd game over als je een onvertrouwde applicatie draait. Met goede isolatie door middel van Flatpak en Wayland kan je het terugbrengen naar een risicomodel dat meer lijkt op het openen van een onvertrouwde website in je browser: je moet blijven opletten dat je het geen vertrouwelijke data geeft, maar het draaien op zichzelf hoeft geen probleem te zijn.

[ffha]

Dank je wel voor de uitgebreide uitleg. Dat maakt Wayland wel meteen een stuk aantrekkelijker. Al moet ik stiekem toegeven, dat ik nog steeds denk dat dit opgelost had kunnen worden zonder x11 compleet weg te gooien.

Flatpak sandboxing is trouwens erg sterk, maar voor eindgebruikers ook niet super relevant. Even rondklikken op Flathub, en je ziet er dat vrijwel alles als "Potentially unsafe" aangeduid wordt. Als het overal bijstaat, gaan gebruikers het negeren, dus iets met bijv. home folder access zal niet opvallen. Ik ben zelf groot fan van Flatpak, maar het wordt echt meer gebruikt ( / misbruikt) voor de runtime stabiliteit, dan het sandboxing aspect.

[The Zep Man]

Het laatste Linux desktopsysteem bij mij is met KDE Plasma eindelijk over op Wayland. Wat mij vertraagde was de brakke ondersteuning voor Nvidia Optimus. Inmiddels is door een combinatie van betere Nvidia drivers en wat eigen configuratie/scripts het prima bruikbaar. Power saving werkt (dGPU gebruikt 0 watt als die niet wordt gebruikt), externe monitoren functioneren zoals verwacht, en ik kan per applicatie bepalen wat op de dGPU draait. Het fijnste is dat een "Optimus Manager"-achtige applicatie niet meer nodig is. Met X11 was het een stuk complexer, ook met gemixte HiDPI- en LoDPI-schermen.

[Reactie gewijzigd door The Zep Man op 26 november 2025 18:28]

[MatiasG]

Wat voor generatie Nvidia chip? Ik heb helaas vrij regelmatig zware memory leaks in plasmashell met een GTX 1050 mobile (welke helaas ook 1 generatie te oud is om volledig uit te schakelen in idle) waardoor ik het proces moet killen. En als ik KWin niet direct op de dGPU draai zijn externe monitoren onbruikbaar traag. Wanneer ik dat wel doe zijn externe monitoren enigzins bruikbaar maar krijg ik al snel last van slowdowns en graphical glitchtes.

Het memory leak probleem lijkt zich ook voor de toen in X11 sessions overigens, ik vermoed dat dit iets met Nvidia Optimus is. Ik maak nog regelmatig gebruik van een X11 session omdat oude proprietiary software zoals Adobe Flash Player niet werken in XWayland. Ik vind het dan ook jammer dat KDE deze optie op termijn volledig gaat uifaseren.

[Reactie gewijzigd door MatiasG op 26 november 2025 19:14]

[The Zep Man]

Wat voor generatie Nvidia chip?

Turing (GTX 1650), met de gesloten driver omdat anders D3cold niet werkt (tekortkoming van Nvidia's GSP firmware, die dus vermeden moet worden met Turing).

Ik heb helaas vrij regelmatig zware memory leaks in plasmashell met een GTX 1050 mobile (welke helaas ook 1 generatie te oud is om volledig uit te schakelen in idle) waardoor ik het proces moet killen. En als ik KWin niet direct op de dGPU draai zijn externe monitoren onbruikbaar traag. Wanneer ik dat wel doe zijn externe monitoren enigzins bruikbaar maar krijg ik al snel last van slowdowns en graphical glitchtes.

Stel je wel KWIN_DRM_DEVICES correct in? Die moet naar beide GPU's refereren. Als je de eerste GPU de integrated maakt en de tweede de Nvidia GPU, dan wordt ook KWin geladen op de Nvidia GPU zodra je een externe monitor aansluit. Dat maakt mogelijk het verschil.

[Reactie gewijzigd door The Zep Man op 26 november 2025 20:34]

[ocf81]

Elke ca. 6 maanden test ik Wayland op KDE en telkens is er gewoon te veel stuk om het te blijven gebruiken. En dat terwijl ze er al 15 jaar mee bezig zijn. Als ik de mensen die er over bloggen/vloggen goed begrijp is dit voor een groot deel te wijten aan de disfunctionele manier waarop de protocollen tot stand komen. Mijn conclusie is vooralsnog dat het eindeloze geruzie bij de mensen die Wayland ontwikkelen het ontstaan van iets werkbaars in de weg staat. Wayland kan eigenlijk alleen slagen als iedereen die er nu aan wekt de deur wordt gewezen en men van wat er nu aan verschillende varianten en extensies bestaat destilleert naar iets wat wel werkt. Het is niet voor niks dat Wayland op SteamOS maar heel sporadisch gebruikt wordt. Valve ziet het vooralsnog niet zitten om de sprong te wagen. Dat zegt wel wat, denk ik.

[Reactie gewijzigd door ocf81 op 26 november 2025 21:27]

[Katsunami]

De mensen die Wayland ontwikkelen zijn dezelfde die ook (hoofd)ontwikkelaar van Gnome zijn. Ze kunnen daar JAREN bakkeleien over hoe een functie in elkaar moet zitten. Daarna komt de functie nog 3 jaar als 'experimental' beschikbaar die je met allerlei omwegen moet aanzetten, en als andere desktops een functie al 8 jaar hebben wordt die door Gnome met veel fanfare geïntroduceerd.

Gelukkig voor hen hebben ze wel de mooiste desktop qua uiterlijk en opgeruimdheid. Laat me denken aan mijn Mac, eerlijk gezegd. Met een beetje prutsen hier en daar werken ze nagenoeg hetzelfde; als ik er een Mac-achtig theme overheen zou gooien zou je je zelfs op het eerste gezicht kunnen vergissen, zelfs als je achter de computer zit.

KDE is een prima desktop (superlang gebruikt ook, vanwege de aanpasbaarheid), maar sinds ik een Mac heb als laptop (desktop is nog steeds Linux, maar ik heb een "mainstream" laptop nodig voor een aankomende studie) begint de rommeligheid in KDE me eigenlijk meer en meer te irriteren. Er zijn een miljoen instellingen. Sommige instellingen hebben extra instellingen. Elk paneel wat betreft het uiterlijk heeft een "Get more ..." knop -ergens- (maar niet consistent) in dat paneel, maar de helft van de tijd werkt die niet omdat de Pling-service waarop de KDE-store draait zo brak is. Dat staat nog los van het feit dat RDP gewoon kapot is in versie 6.3.6 die in Debian zit, en ik weiger van distro te veranderen.

Ik merk dat, naarmate dat ik ouder word, ik van mijn computer thuis eigenlijk steeds minder nodig heb qua aanpasbaarheid; als het er maar fatsoenlijk en opgeruimd uitziet dan kan ik met (bijna) alles werken, dus ik ben recentelijk overgestapt op Gnome... maar toch met een paar tweaks en extensies hier en daar. Maar ja, dat heb ik zelfs op de Mac en vroeger op Windows ook gedaan.

[Reactie gewijzigd door Katsunami op 27 november 2025 20:12]

[ocf81]

Het is niet zo dat ik elke dag wat aanpas, maar er zijn een aantal zaken die ik in GNOME niet voor elkaar krijg die in KDE wel goed gaan. GNOME voelt voor mij dus als een soort dwangbuis, dus vooralsnog blijf ik bij KDE.

[Mastakilla]

VMware workstation display driver werkt de laatste tijd hier ook niet meer goed met wayland. Ik log terug in met X11 op mijn Ubuntu 24.04

[HollowGamer]

Of je stapt naar iets beters over, zoals QEMU/virt-manager.

Zelf was ik al snel weg naar Docker/Podman, zeker toen Broadcom VMWare overnam.

[Mastakilla]

Ik ben aan het proberen over te stappen van VMware Workstation op mijn Win11 desktop naar VMs op TrueNAS Scale 25.04 dmv virt-manager client op mijn Win11...

Maar Ubuntu 24.04 werkt voor geen meter met virt-manager. Fedora 43 gaat al wel wat beter, maar heeft toch ook nog steeds zijn issues hoor. (auto resize van het venster stopt meestal met werken na vaak van size wisselen, usb passthrough is een heel gedoe... Terwijl dat met VMware allemaal flawless werkt, al vele jaren lang...).

Ik doe mijn best maw om over te stappen, maar het zomaar "beter" noemen dan VMware gaat me toch nog wat ver...

[HollowGamer]

Ik herken wel wat van je struggles. Zelf draai ik virt-manager in een Flatpak, en dat is nog een graat erger. Gelukkig alleen als ik het echt nodig hebt, ik probeer niet meer iets met VMs te doen.

Gelukkig heb ik geen enkele Windows client meer nodig, maar begrijp dat iedereen anders is.

[henk717]

Gewoon zoals altijd weer enorm jammer dat Linux niets geeft om compatibiliteit. Waarom moest er nou weer verplicht een protocol worden doorgedrukt welke bewust niet compatibel wil zijn met al het anderen. Games die bepalen op welke monitor zij starten? Jammer joh. Onze eigen app gebruikt customtkinter voor de launcher en dat werkt op elk besturingsysteem. Maar wayland doet de scaling fout en daar hebben we vrijwel geen controle over. Op windows werkt het prima, op X werkt het prima, op mac werkt het prima en op wayland ziet het er onjuist uit. Vandaag ook een leuke bugreport, wayland user wil die launcher gebruiken maar krijgt de file dialogs niet open. Werkt op sommige window managers wel, bij andere niet want wayland is een specificatie geen product. In dat geval is waarschijnlijk zenity die bokt dus hij moet maar onze fallback gebruiken tenzij we er achter kunnen komen waar in zijn wayland het probleem zit.

Mijn thinclient project dan maar als een ander voorbeeld. Daar kies ik wel voor de X server en dat werkt top. Soms test ik het script op wsl en dat maakt gebruik van wayland. In het script staat duidelijk aangegeven open het scherm in het midden, maar positionering bepaald wayland niet het programma. Dus waar die keer het login scherm staat? Geen idee, pure willekeur en enorm lelijk. Audio is nog zo iets, met pulsaudio werkt alles top. Pipewire? Ineens werken microfoon codecs van xfreerdp niet meer. En zonder pipewire is wayland weer niet te doen want pipewire is een pleister die zaken als screensharing laat werken voor velen.

Op de desktop ben ik ook de klos, ik had een doel om in 2026 fulltime linux te gaan 10 jaar geleden. Ik ben nu verder dan ooit van dat doel af. Alle moeite die ik daar in had gestopt compleet weg. Mijn pulseaudio configuratie bestand voor zaken als volume normalisation dat me uren heeft gekost om uit te zoeken? Dat werkt niet, ik moet nu de configuratie van pipewire leren en daar zijn veel minder voorbeelden van. SSH x11 forwarding als een soort remote desktop? Kan niet, gebruik maar een andere tool.

Dan heeft het toch geen nut om moeite te gaan steken om een platform dat niet doet wat ik wil te laten doen wat ik wil op mijn desktop? Want alles wat ik voor Linux maak gaat uiteindelijk stuk omdat het wordt vervangen door iets andere dat doelbewust geen compatibiliteit bied. Dan kan ik het beter gewoon op windows doen want als ik een windows workaround bedenk is de kans wel groot dat die heel lang blijft werken.

Ik wilde komende maand weer een poging wagen omdat ik enigsinds vertrouwen had dat KDE x11 wel bleef ondersteunen maar nu is de motivatie om toch maar pipewire te leren compleet weg.

[MartinMeijerink]

Ben blij dat ik Slackware gebruik, aangezien stabiliteit, eenvoud en compabiliteit bij Patrick Volkerding hoog in het vaandel staat, dus het zal m.i. nog lang duren (20 jaar misschien) voor Wayland hier de standaard wordt. Wayland kan dan wel moderner zijn, maar is minder universeel en mist voor sommige workflows nog altijd volwassen alternatieven. Op X11 kan een heleboel wat op Wayland (nog) niet kan, zelf gebruik ik al 22 jaar Window Maker als windowmanager (deze werkt zonder compositor), en nogal vaak tools als xdotool, wmctrl, scrot, maim enz., en X-forwarding over SSH, dit kent Wayland allemal niet, dus er zal nog heel veel aan Wayland moeten worden gesleuteld om het niveau van X11 te halen.

[MokaNi]

Ik mag hopen dat ondersteuning voor Wayland beter gaat worden in Ubuntu 24.04 (met KDE dus) en Steam/Proton. Ik heb hier alleen maar ellende mee gehad (games freezen bij renderen van eerste frame en recoveren niet), terwijl alles in Xorg draait als een zonnetje.

Hebben drivers invloed op Xorg vs Wayland? Ik heb Nvidia hardware (5070ti) dus mogelijk heeft dat er mee te maken, maar ik ben geen expert op dit gebied.